कोड की "कॉपी और पेस्ट" खतरनाक क्यों है? [बन्द है]

Question

कभी-कभी, मेरे बॉस हमसे शिकायत करेंगे:

एक सुविधा को लागू करने के लिए हमें इतने लंबे समय की आवश्यकता क्यों है?

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

यह वास्तव में एक कठिन सवाल है, क्योंकि मेरे नज़रिए में कॉपी और पेस्ट कोड इतनी सरल बात नहीं है।

क्या आपके पास अपने गैर-तकनीकी बॉस को यह समझाने के लिए कोई अच्छा कारण है?

Comments

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

— कार्सन मायर्स

क्योंकि हर बार जब आप कोड को कॉपी और पेस्ट करते हैं, तो एक बेबी सील मारा जाता है।

— घातक क्लेम्बर्स

@CarsonMyers केवल अगर घटक पुन: प्रयोज्य है। और यह वर्तमान संदर्भ में फिट होने के लिए है।

— श्रीकांत करुमनघाट

Answer 1

यदि आप अपने कॉपी-पेस्ट कोड में बग ढूंढते हैं, तो आपको इसे हर उस जगह को ठीक करना होगा जो आपने किया था और आशा है कि आप उन सभी को याद कर सकते हैं (यह भी परिवर्तित आवश्यकताओं के लिए है)।

यदि आप तर्क को एक स्थान पर रखते हैं, तो जरूरत पड़ने पर बदलना आसान होता है (इसलिए यदि आप तय करते हैं कि एप्लिकेशन को अद्यतन करने की आवश्यकता है, तो आप इसे केवल एक ही स्थान पर करते हैं)।

क्या आपके बॉस ने DRY सिद्धांत (अपने आप को दोहराएं नहीं) के बारे में पढ़ा है ।

आप पुस्तकालयों के लिए सही उपयोग जैसी ध्वनियों का वर्णन कर रहे हैं , जहां आप कोड साझा करते हैं और केवल एक ही स्थान पर रखते हैं।

मैं केवल कभी भी कॉपी-पेस्ट कोड का उपयोग करूंगा, अगर मेरा इरादा इसे जल्द ही रिफलेक्टर करने का है - तो मुझे यकीन है कि मैंने बाद में कॉमन कोड निकाला ताकि मैं ज्यादा से ज्यादा तर्क का पुन: उपयोग कर सकूं। और इसके तुरंत बाद, मेरा मतलब है मिनट और घंटे बाद, दिन और सप्ताह नहीं।

Comments

+1। मुद्दा यह है कि तत्काल समस्या को हल करने के लिए कॉपी और पेस्ट सस्ता है। असली मुद्दा यह है कि मध्यम / दीर्घावधि में डुप्लिकेट कोड को बनाए रखने की लागत अच्छी तरह से फैक्टर कोड की तुलना में अधिक है

— पाओलो

यह सिर्फ एक बग मुद्दा नहीं है; कार्यक्रम की आवश्यकताएं बदल सकती हैं। मैंने पाँच में से चार स्थानों को बदल दिया है जहाँ पहले कुछ बदलने की आवश्यकता थी।

— डेविड थॉर्नले

यदि आप मांग पर कॉपी-एन-पेस्ट कर सकते हैं, और ट्रैक कर सकते हैं जहां डुप्लिकेट आसानी से बाद में उन्हें अमूर्त कर रहे हैं या उन्हें अपडेट करते हैं, तो कॉपी और पेस्ट करना कोई बुरी बात नहीं है। Www.semanticdesigns.com/Products/Clone पर क्लोन पता लगाने के बारे में अधिक जानकारी के लिए चर्चा करें और ऐसा करने के लिए टूल के लिए।

— इरा बैक्सटर

बहुत सारे ifs, और अधिकांश टूलिंग इस बिंदु पर क्लोन का पता लगाने का समर्थन नहीं करते हैं।

— ओड

एक बार एक प्रोग्रामर था जो ईएसए के लिए काम करता था । वह एरियन -5 रॉकेट के लिए सॉफ्टवेयर पर काम कर रहा था और उसने कॉपी-पेस्ट विधि का इस्तेमाल किया। फिर एस ... होता है

— हौलेथ

Answer 2

आप कॉपी और पेस्ट का उपयोग करके कोड को कॉपी करने के बजाय लाइब्रेरी बनाकर कोड साझा करना बेहतर होगा ।

आप अभी भी फिर से लिखने (DRY देखो) पर एक गति लाभ प्राप्त करेंगे, लेकिन कोड को बनाए रखने के लिए केवल एक ही स्थान होगा।

Comments

मैं बस उत्सुक हूं, अगर आपको इसे डुप्लिकेट करने की आवश्यकता है तो आप कोड को "कट" क्यों करेंगे?

— dpp

अच्छा बिंदु डी.पी. संपादित!

— CResults

Answer 3

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

लेकिन अधिक महत्वपूर्ण कारण यह है कि "यह जैसा है वैसा ही है" यह धारणा अधिक बार सूक्ष्म रूप से गलत नहीं है। जब भी आपका कोड सही होने के लिए अनिर्धारित मान्यताओं पर निर्भर करता है, तो इसे किसी अन्य स्थान पर कॉपी करना त्रुटियों में परिणाम करता है जब तक कि ये धारणाएं नई जगह पर भी नहीं रहती हैं। इसलिए, पेस्ट किया गया कोड अक्सर शुरुआत से गलत होता है, न कि अगले बदलाव के बाद।

Answer 4

डिज़ाइन-वार, कॉपी-पेस्ट कोड निश्चित रूप से एक आपदा है, जिससे भविष्य में बहुत सारी समस्याएं पैदा हो सकती हैं। लेकिन आप पूछ रहे हैं कि अभी आपको बहुत काम क्यों करना है , इसका जवाब है: क्योंकि यह सिर्फ नकल और चिपकाने वाला नहीं है।

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

• "ज़रूर, मुझे पहले से ही कोड मिल गया है जो बिल्कुल ऐसा करता है!"
• "रुको, कोड के इन पांच संस्करणों में से कौन सा वह है जिसे मैं अपने स्रोत के रूप में उपयोग करना चाहता हूं?"
• "हम्म्म, ये सभी 'यूज़_फ्यून्क_023' क्या कार्य करते हैं? क्या मैंने उन्हें दस्तावेज नहीं दिया? उनमें से मुझे अब क्या चाहिए?"
• "ओह, हाँ, यह कोड कोड बेस Y. का उपयोग करता है। मुझे लगता है कि मुझे एक चुनने की आवश्यकता है: कोड बेस वाई के सभी को मेरी नई परियोजना में कॉपी करें / एक दिन खर्च करें जो मैं एक फ़ंक्शन को आधार बेस से प्राप्त करना चाहता हूं / एक सप्ताह का खर्च निकाल रहा हूं। एक फ़ंक्शन जो मैं कोड बेस वाई से चाहता हूं]। "
• "मैंने सब कुछ कॉपी किया, याय!"
• "यह काम क्यों नहीं कर रहा है?"
• यह वह बिंदु है जहाँ आप घंटों / दिन / सप्ताह मौजूदा कोड को डिबगिंग करते हैं, जो कि आप जो चाहते हैं उसके समान है, उस कोड को लिखने के बजाय जिसे आप वास्तव में शुरू करना चाहते हैं।

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

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

Answer 5

कॉपी और पेस्ट करना एक आपदा है। आपके बॉस को बहुत जल्द एंड-यूज़र को भेजे गए टूटे हुए कोड की कीमत के संबंध में शिपिंग की कीमत का मूल्यांकन करना चाहिए।

Answer 6

यदि आपने पहले ही सुविधाओं को लागू कर दिया है और आपको उन्हें पुन: उपयोग करने के लिए कॉपी और पेस्ट करने की आवश्यकता है, तो ऐसा लगता है कि आपने कुछ गलत किया है। क्या आप इन विशेषताओं को लाइब्रेरी में नहीं रख सकते हैं ताकि आप उन्हें कॉपी / पेस्ट के बिना पुन: उपयोग कर सकें?

Answer 7

DRY सिद्धांत (खुद को दोहराएं नहीं): DRY on wikipedia ।

"ज्ञान के हर टुकड़े में एक प्रणाली के भीतर एक एकल, अस्पष्ट, आधिकारिक प्रतिनिधित्व होना चाहिए।"

अन्य लिंक ।

Comments

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

— MicroservicesOnDDD

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

— माइक्रोसेरोऑनडीडी

Answer 8

यह मुझे लगता है कि आपके गैर-तकनीकी बॉस की सबसे खराब गलत धारणा है, यह है कि आपकी नौकरी मुख्य रूप से टाइपिंग है। उन्हें लगता है कि आप टाइपिंग को खत्म करके बहुत समय बचा सकते हैं।

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

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

Answer 9

क्या आप सुनिश्चित हैं कि आपका बॉस DRY सिद्धांत, बग और अन्य तकनीकी सामान के बारे में सुनना चाहता है?

इस तरह की टिप्पणियाँ आप आमतौर पर सुनते हैं जब आपके बॉस या कंपनी को किसी परियोजना को पूरा करने के लिए कम समय की आवश्यकता होती है। और गलत अनुमान के आधार पर एक अनुबंध पर हस्ताक्षर किए गए थे, आदि ज्यादातर मामलों में प्रोग्रामर अनुमानों में शामिल नहीं थे।

ऐसा क्यूँ होता है? कभी-कभी प्रोजेक्ट प्रायोजक के पास बहुत कम बजट होता है। हो सकता है कि एक व्यावसायिक प्रक्रिया जिसे आप सॉफ्टवेयर का उपयोग करके स्वचालित कर रहे हैं वह आपके टीम प्रयास के लायक नहीं है। ऐसे मामलों में बुरी खबर के लिए प्रबंधक आम तौर पर बहुत बंद हो जाते हैं। परियोजना की शुरुआत में इच्छाधारी सोच है। तब प्रबंधक प्रोग्रामर को दोष देने की कोशिश करते हैं। आपके मामले में अप्रत्यक्ष रूप से कॉपी-एंड-पेस्ट के माध्यम से। चरम मामलों में यह कहा जाता है डेथ मार्च है ।

Answer 10

कोडिंग और पेस्टिंग कोड आमतौर पर संयोग से प्रोग्रामिंग की ओर जाता है

Comments

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

— मप्तो

Answer 11

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

एक ही एप्लिकेशन के भीतर , "कॉपी और पेस्ट" खराब है, लेकिन कोड बेस के बीच जो अलग-अलग टीमों द्वारा विकसित किए गए हैं या अलग-अलग रिलीज साइकिल "कॉपी और पेस्ट" के साथ सबसे अच्छा विकल्प हो सकता है।

Comments

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

— सैमबी

Answer 12

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

Answer 13

यहां तक ​​कि अगर अन्य एप्लिकेशन में पहले से ही आपकी जरूरत की सुविधा है, तो उस सुविधा के लिए कोड एक प्रमुख पुनर्लेखन के बिना आपके वर्तमान एप्लिकेशन में बस फिट नहीं हो सकता है। यह एक फोर्ड की मोटर लेने और इसे टोयोटा में फिट करने की कोशिश करने जैसा है। आम तौर पर, अंगूठे का एक नियम है कि यदि आपको अपने द्वारा प्रतिलिपि किए गए कोड का 25% से अधिक संशोधित करना है, तो इसे खरोंच से फिर से लिखना बेहतर (सस्ता) है।

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

Answer 14

अपने बॉस को बताएं कि प्रत्येक और हर चर नाम के हिस्से में पुरानी परियोजना का नाम शामिल है और अब आपको उन सभी को मैन्युअल रूप से बदलना होगा। यदि आपके बॉस को पता नहीं है (या जानना चाहते हैं) कॉपी / पेस्ट खराब क्यों है, तो वह यह मान सकता है कि वह :)

Answer 15

हाँ, सबसे बड़ी समस्या यह है कि यह सिर्फ कॉपी और पेस्ट नहीं है - इसकी कॉपी फिर पेस्ट और फिर थोड़ा संशोधित करें।

फिर बाद में जब किसी चिपके हुए वेरिएंट में कोई समस्या आती है, तो वह बदल जाता है। फिर बाद में, एक और संस्करण बदल जाता है।

फिर, आपको पता चलता है कि सभी वेरिएंट्स को बदलना होगा क्योंकि मूल प्रति में बग थे। अब आप अच्छी तरह से और वास्तव में खराब हो गए हैं क्योंकि सभी चिपके हुए क्षेत्र अब समान नहीं हैं।

और क्या आप इसे नहीं जानते हैं, इस तरह का भद्दा कोडिंग आमतौर पर लगभग पूरी तरह से टिप्पणियों से रहित होता है।

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

एक प्रणाली के व्यवहार को एकल बिंदु संशोधनों के साथ आसानी से बदला जा सकता है - कोड के एक गुच्छा के व्यवहार को बदलने के लिए कोड के एक गुच्छा की आवश्यकता होती है।

मुझे सिस्टम पसंद हैं, कोड का एक गुच्छा नहीं।

Answer 16

आपके सामने तात्कालिक कार्यक्षमता के विकास की गति के बीच व्यापार-अप हैं (विशेषकर जब आवेदन छोटा है), और आवेदन बढ़ने पर रखरखाव की लागत लंबी अवधि।

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

यही तर्क है कि व्यापार मालिकों को सुनने की जरूरत है। यह वाहनों के बेड़े को बनाए रखने की स्वीकृत लागतों के समान है, हालांकि, सॉफ्टवेयर के साथ, सॉफ्टवेयर आर्किटेक्चर के टूटे हुए पहलू आम तौर पर व्यापारिक पक्ष के लिए छिपे हुए हैं, और केवल डेवलपर्स द्वारा देखा जा सकता है।

Answer 17

वह सही है कि यदि टीम ने पहले भी इसी तरह की कार्यक्षमता को लागू किया है, तो इसे दोहराना 2 बार बहुत आसान होगा ।

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

Answer 18

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