क्या बंदर पकड़ने को अच्छा प्रोग्रामिंग अभ्यास माना जाता है?

Question

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

हालांकि, मैंने इस तकनीक को मुख्यधारा के प्रोजेक्ट्स में "सामान्य तरीके" के रूप में इस्तेमाल किया है, उदाहरण के लिए जीवेंट के gevent.monkeyमॉड्यूल में ।

क्या मंकीपैकिंग मुख्यधारा, सामान्य, स्वीकार्य प्रोग्रामिंग अभ्यास बन गई है?

इसे भी देखें: जेफ एटवुड द्वारा "मंकीपैचिंग फॉर ह्यूमन"

Comments

मैं कहूँगा कि कुछ नामित बंदर पैचिंग है नहीं अच्छा प्रोग्रामिंग अभ्यास माना जाता है। बिना यह जाने भी कि यह क्या है, बस इसके नाम से।

— littleadv

क्या होगा अगर 3 पार्टी आपको जो फिक्स चाहिए, वह नहीं करना चाहती है?

@ Thorbjørn: अच्छा सवाल, एक तरफ मुझे मंकीपैकिंग पसंद नहीं है, दूसरी तरफ मुझे प्रोजेक्ट क्लोनिंग का आइडिया पसंद नहीं है और लोकल पैचेज रखना अगर यह सिर्फ एक छोटी सी बात है।

— vartec

@littleadv: ... तो इसे "हॉट फ़िक्स" / "ऑन-द-फ़्लाई फ़िक्स" या "रनटाइम फ़िक्स" कहें और यह सही लगता है? ;) सभ एक ही है।

— डेगनलीज़

जावास्क्रिप्ट बहुत अवधारणा के आसपास बनाया गया है

— ZJR

Answer 1

नहीं, लेकिन कभी-कभी मंकीपैक एक कम बुराई है (टूटे हुए कोड :) होने की तुलना में)। माणिक में बंदरों के लिए मेरे सामान्य नियम हैं:

• बंदर-पैच के लिए वास्तव में अच्छा कारण है (अस्थायी महत्वपूर्ण हॉटफ़िक्स एक अच्छा कारण है। अच्छा स्वरूपण of_s विधि नहीं है, जब तक कि आप ActiveSupport पर काम नहीं कर रहे हैं)

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

• हटाने में आसान - प्रलेखन में हटाने के बारे में जानकारी और देखने के लिए क्या शामिल होना चाहिए। बंदरों के बहुत सारे अस्थायी हैं, इसलिए उन्हें निकालना आसान होना चाहिए।

Answer 2

हाँ, मंकीपैकिंग बहुत उपयोगी है!

किसी तरह, लोगों की धारणा पर नाम अत्यधिक प्रभावशाली लगते हैं। इसे "मंकीपैक" कहें और यह बुरा लगता है, इसे "हॉट फ़िक्स" या "ऑन-द-फ़्लाई फ़िक्स" कहते हैं और यह अच्छा लगता है।

स्वतंत्र रूप से, मुझे लगता है कि रनटाइम के दौरान तरीकों / विशेषताओं / कार्यों को बदलने की क्षमता बहुत उपयोगी चीज है। यहां तक ​​कि जावास्क्रिप्ट लोग इसे दिन भर का उपयोग करते हैं शायद इसे जाने बिना।

उदाहरण के लिए:

button.onclick = function(e) { ...}

यह सरल रेखा इस तथ्य को दर्शाती है कि आप बटन के व्यवहार को बदल देते हैं। इसे इस तरह से डिजाइन किया गया था। इसी तरह, आप हर दूसरे फ़ंक्शन को बदल सकते हैं लेकिन ऐसा करना मूर्खतापूर्ण होगा।

अब, इस तरह से पैच देने के सवाल के लिए ... अच्छी तरह से ... क्यों नहीं। आपको बस एक बड़ी रिलीज के बजाय एक छोटा पैच डाउनलोड करना होगा। बिल्ली, तुम भी इसे रोकने के बिना एक सर्वर पैच सकता है, बढ़िया! और फिर, एक दिन, आप एक बड़े अपडेट के लिए नवीनतम रिलीज़ भी प्राप्त कर सकते हैं। काफी उचित। तो हाँ, मैं एक अच्छी बात के रूप में "रनटाइम पैच" के लिए वोट करता हूं।

दिलचस्प रूप से पर्याप्त है, एरलंग जैसी कुछ भाषाएं भी इस अवधारणा के आसपास निर्मित हुई थीं। मक्खी पर एक सर्वर को अद्यतन करने की क्षमता।

बेशक, अंत में, और बाकी सब कुछ की तरह, यह एक बात है कि आप इसका उपयोग कैसे करते हैं। आप अद्भुत OO सामान बना सकते हैं और एक समान हो सकते हैं।

संपादित करें:

मुझे कुछ मामले भेद जोड़ने दें, चाहे आप अपनी खुद की लाइब्रेरी या तीसरे पक्ष को पैच कर रहे हों ।

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

अब, निश्चित रूप से, यदि आप एक पेच के व्यवहार को बदलने के लिए एक पैच का उपयोग करते हैं और इसके उद्देश्य / काम करने के तरीके को अलग करते हैं, तो जाहिर है कि यह आपदा का एक नुस्खा है। यहां तक ​​कि एक बंदर भी देखता है कि ... ठीक है, मुझे उम्मीद है। ;)

Comments

कोई नहीं कहता कि यह उपयोगी नहीं है। हालाँकि, यह सामान्य रूप से एक अच्छा अभ्यास नहीं है। और "हॉटफ़िक्स" और "ऑन-द-फ़्लाई फ़िक्स" मेरे लिए कोई बेहतर नहीं है।

— लुकास स्टेस्कल

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

— dagnelies

मैं मानता हूं कि यह एक शक्तिशाली और उपयोगी विशेषता है। लेकिन यह भी बहुत खतरनाक है (रूबी में) क्या आपने कभी कई मंकीपेड 3 पार्टी लाइब्रेरी के आधार पर एप्लिकेशन को बनाए रखने की कोशिश की है? जब भी आप कुछ लाइब्रेरी को अपडेट करने का प्रयास करते हैं तो आपदा के लिए एक नुस्खा।

— लुकास स्टैस्कल

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

— dagnelies

... मैंने बाद के मामले पर कुछ टिप्पणियां जोड़ीं।

— dagnelies

Answer 3

मेरा मानना ​​है कि सभी पैच अपने रन-टाइम प्रकृति के कारण स्वाभाविक रूप से जोखिम भरे हैं, और डिजाइन-समय पर पकड़े जाने में असमर्थता है।

वे रनटाइम अपवादों का स्वागत करते हैं, और बस का पालन करने के लिए जटिल डिबगर्स और घड़ियों की आवश्यकता होती है।

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

मेरे दो सेंट

Answer 4

सामान्य रूप से पैचिंग एक अंतिम उपाय होना चाहिए, बंदर पैचिंग और भी अधिक। मुद्दा मुख्य रूप से स्थिरता का है।

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

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

Answer 5

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

यदि आप जानते हैं कि आप क्या कर रहे हैं और एक SOLID को लागू करने का समय नहीं है, तो बेशक बंदर का पेटिंग उपयोगी है समाधान । लेकिन आपको कभी भी इस मानक तकनीक पर विचार नहीं करना चाहिए और बंदर पैच पर बंदर पैच का निर्माण करना चाहिए ।

BTW, क्या तुमने कभी एक बंदर पैच के लिए एक इकाई परीक्षण लिखा था?

Comments

मुझे नहीं लगता कि आप यहां एलएसपी लागू कर सकते हैं। इसमें उपप्रकारों से संबंधित एक बहुत विशिष्ट परिभाषा है।

— कोनराड रूडोल्फ

@KonradRudolph बंदर किसी वस्तु को उसके प्रकार में बदल देता है। डायनेमिक रूप से टाइप की गई भाषाओं में टाइप यू के समान टाइप के साथ हर इंटरफेस टी होता है। अगर यह एक बतख की तरह चलता है ...

— स्कारफ्रिज

"... इसका प्रकार बदलता है" - पर्याप्त रूप से उचित। समझ में आता है।

— कोनराड रुडोल्फ

आरई "यह सॉफ्टवेयर विकास के लिए एक मानक तकनीक नहीं है।", यह परीक्षण के लिए पायथन में * हर समय और प्रमुख पुस्तकालयों में किया जाता है।

— टॉमी