(बंदर) पैच या नहीं (बंदर) पैच, यह प्रश्न

Question

मैं किसी सहयोगी से बात कर रहा था कि हम किसी पैकेज के उपयोग के बजाय एक अप्रत्याशित/अवांछित व्यवहार के बारे में बात कर रहे थे। यद्यपि हमारे अंत में किसी भी स्पष्ट दुष्प्रभाव के बिना एक आसान फिक्स (या कम से कम कामकाज) है, लेकिन उसने दृढ़ता से प्रासंगिक कोड को विस्तारित करने और पैच अपस्ट्रीम पोस्ट करने का सुझाव दिया, उम्मीद है कि भविष्य में किसी बिंदु पर स्वीकार किया जाएगा। असल में हम कई पैकेजों के विशिष्ट संस्करणों के खिलाफ पैच बनाए रखते हैं जो प्रत्येक नए निर्माण पर स्वचालित रूप से लागू होते हैं। मुख्य तर्क यह है कि यह "बदसूरत" वर्कअराउंड या नाजुक बंदर पैच के विपरीत करने के लिए सही काम है। दूसरी तरफ, मैं शुद्धता पर व्यावहारिकता का पक्ष लेता हूं और अंगूठे का मेरा सामान्य नियम यह है कि कम से कम (महत्वपूर्ण) बग फिक्स के अलावा कम से कम किसी भी चीज़ के लिए "कोई पैच"> "बंदर पैच"> "हार्ड पैच" है।

तो मैं सोच रहा हूं कि जब यह (हार्ड) पैच, बंदर पैच के लिए बेहतर है या सिर्फ एक तीसरे पक्ष के पैकेज के आसपास काम करने की कोशिश है, जो वास्तव में ऐसा नहीं करता है जो वास्तव में नहीं करता है। क्या यह मुख्य रूप से पैच के कारण के साथ करना है (उदाहरण के लिए एक बग फिक्स करना, व्यवहार को संशोधित करना, गायब सुविधा जोड़ना), दिया गया पैकेज (आकार, जटिलता, परिपक्वता, डेवलपर प्रतिक्रिया), कुछ और या कोई सामान्य नियम नहीं है और एक केस-दर-मामले आधार पर निर्णय लेना चाहिए?

Answer 1

मेरी राय में

:

यदि 'अप्रत्याशित/अवांछित व्यवहार' = बग, तो monkeypatching (या duckpunching) ने संकेत किया जाएगा।

यदि आप मानते हैं कि यह lib में एक बग है, तो हार्ड पैचिंग और पैच अपस्ट्रीम को धक्का देना समझ में आता है।

यदि मैं आपको lib के व्यवहार की क्षतिपूर्ति के लिए अपने ऐप में जटिलता जोड़ने के लिए 'आसपास काम करने' की परिभाषा समझता हूं, तो मुझे यह कहना होगा कि बंदरगाह निश्चित रूप से एक बेहतर विचार है।

मेरा .2 पेसो।

Answer 2

अच्छा, यह काफी शास्त्रीय जोखिम बनाम लाभ है।

पैच जोखिम मुक्त है? और लाभ में भारी? इसे बंदरगाह यदि कुछ जोखिम है, और केवल थोड़ा सा लाभ है, तो मैं इसे बंदरगाह नहीं करूँगा, और बस अपनी सामान्य रिलीज प्रक्रिया में फिक्स को प्लग करें।

Answer 3

पैचिंग एक कारण के लिए "सही चीज़" है: ओपन सोर्स सॉफ़्टवेयर के साथ, यदि आपने एक वास्तविक बग की खोज की है, या किसी ऐसी सुविधा की आवश्यकता है जिसे आपको संदेह है कि दूसरों को भी आवश्यकता हो सकती है, पैच अपस्ट्रीम को पैचिंग और सबमिट करना समुदाय को वापस देने का एक तरीका है, और पूरी तरह से सॉफ्टवेयर को बेहतर बनाने में योगदान देता है। यदि पैच स्वीकार किया जाता है, तो यह आपके या आपकी कंपनी की प्रतिष्ठा के लिए एक निःशुल्क +1 है। कोई भी दुखी नहीं था क्योंकि उनके पास उपयोगी, ओपन सोर्स कोड के बहुत सारे उदाहरण थे, उन्होंने समुदाय में उनके रेज़्यूमे पर योगदान दिया है ...

नहीं, हम उस समय, सही समय पर, सही काम करते हैं। लेकिन अगर हम सर्वोत्तम प्रथाओं के बारे में एक अमूर्त चर्चा करने जा रहे हैं, तो ऐसा लगता है कि प्राथमिकता का सही क्रम "पैच और सबमिट"> चालाक कामकाज> एक पैकेज ढूंढना बेहतर काम करता है> बदसूरत बंदरपैच ;-)

Answer 4

हम जो जानकारी खो रहे हैं उसका एक टुकड़ा यह है कि क्या आपके द्वारा वर्णित अप्रत्याशित व्यवहार एक बग, शुद्ध और सरल है, या यदि यह व्यवहार है तो पैकेज के कुछ उपभोक्ता चाहते हैं।

जैसा कि यहां दूसरों द्वारा बताया गया है, यह जोखिम और प्रयास का व्यापार बंद है। मैं आपकी विशिष्ट परिस्थितियों को जानने के बिना कोई निश्चित दावा नहीं कर सकता।

हालांकि मेरी आंत महसूस यह है कि पैचिंग और पुश अपस्ट्रीम के परिणामस्वरूप लंबे समय तक कम जोखिम और प्रयास होगा, आपको लगता है कि आपका पैच स्वीकार कर लिया जाएगा।भले ही आप हार्ड पैच या बंदरपैच के बावजूद, आपको इसकी लागत होगी - हर बार जब आप अपने द्वारा उपयोग किए जाने वाले पैकेज के संस्करण को अपडेट करते हैं, तो आपको अपने पैच का परीक्षण करने की आवश्यकता होगी, और संभवतः इसे अपडेट करें पैकेज में बदलाव पर। एक हार्ड पैच के साथ, आपको पैच को फिर से लागू करना होगा, लेकिन यह परीक्षण/अपडेटिंग से कम काम होगा, आपको किसी भी विकल्प के साथ करने की आवश्यकता होगी, सबसे अधिक संभावना है।

इस परिदृश्य में पैचिंग के लिए दो जीत रहे हैं, के रूप में मैं इसे देख सकते हैं।

आप पैच जब आप एक कठिन पैच के साथ उन्नयन, के बारे में भूल गए हैं, अपने पैच पूरी तरह से गायब, एक भयावह और दृश्य की विफलता, सबसे अधिक संभावना के कारण होगा। जबकि एक बंदर पैच के साथ, आपका पैच अभी भी वहां रहेगा, लेकिन आपने परीक्षण नहीं किया होगा, यह अभी भी वही प्रभाव है, जो मेरे दिमाग में हार्ड-पैच पूरी तरह गायब होने की तुलना में मामलों की एक और अधिक खतरनाक स्थिति है।

कठिन पैचिंग के लिए अन्य जीत है कि, एक कठिन पैच के साथ, अंत में यह पैकेज में एकीकृत किया जाना चाहिए है, और लागत गायब हो जाता है। जबकि एक बंदर पैच अनिश्चित काल तक लटका होगा, जब तक कि इस मुद्दे को स्वतंत्र रूप से हल नहीं किया जाता है।

अनपेक्षित व्यवहार कुछ अन्य पैकेज उपभोक्ताओं चाहते हैं, और नहीं बस एक बग है, तो इस तस्वीर मैं पेंट पेचीदा हो। इस मामले में बंदर पैच समाधान को केवल व्यवहार को हटाना होगा। हार्ड पैच, हालांकि, उन लोगों के लिए व्यवहार बनाए रखना होगा जो इसे चाहते हैं।

इस विश्लेषण पैकेज देखरेख और अन्य उपभोक्ताओं के लिए किसी भी नैतिक दायित्वों आप हो सकता है पर ध्यान नहीं देता।

इसके अलावा, मैं दार्शनिक बंदर पैचिंग की पूरी अवधारणा का विरोध किया हूँ, लेकिन है कि इस चर्चा :-)