DRY क्यों महत्वपूर्ण है?

Question

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

मुझे जल्द ही किसी भी समय इसे फिर से संपादित करने की आवश्यकता नहीं है।

यह बहुत कम काम की तरह लग रहा है बस जाने के लिए ...

function doStuff1(){/*.a.*/}
function doStuff2(){/*.b.*/}
function doStuff3(){/*.c.*/}

और अगर मुझे कभी कुछ जोड़ना है ...

function doStuff4(){/*.d.*/}

और अगर मुझे इसे हटाने की आवश्यकता है, तो मैं इसे हटा देता हूं।

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

डीआरवाई क्यों करें जब ऐसा लगता है कि त्वरित कट + पेस्ट इतना कम काम हो सकता है?

Comments

क्योंकि जब आप इसे सही करते हैं, तो सूखा अभी भी तेज है, अगर आपने गलती की है। अन्य सभी प्रभाव

— डैनियल लिटिल

"मुझे जल्द ही किसी भी समय इसे फिर से संपादित करने की आवश्यकता नहीं है" - आप उम्मीद कर सकते हैं, लेकिन शायद आप यहां गलती कर रहे हैं। और यदि आप उस कोड पर फिर से काम करने जा रहे हैं, लेकिन इतनी जल्दी नहीं, तो यह केवल चीजों को बदतर बना देगा; आप भूल जाएंगे कि डुप्लिकेट कहां हैं, और डुप्लिकेट सूक्ष्म लेकिन विश्वासघाती विसंगतियों को बढ़ाएंगे। "इस तरह लिखें कि जो व्यक्ति आपके कोड को बनाए रखेगा वह एक खतरनाक पागल है जो जानता है कि आप कहां रहते हैं", क्लासिक्स को उद्धृत करने के लिए।

— 9000

मुझे लगता है कि आप इसके साथ बहुत योग कर सकते हैं: परिवर्तन का एक एकल बिंदु बनाए रखना आसान है।

— फाल्कन

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

— डेविड हेफर्नन

@Wayne मुझे स्रोत में एक बड़ी गड़बड़ी महसूस हुई, जैसे कि लाखों प्रोग्रामर अचानक आतंक में रोए।

— गुप्त

Answer 1

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

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

मैं हमेशा DRY के पक्ष में गलती करता हूं, अपने आप को दोहराते हुए, जब मुझे लगता है कि पठनीयता में लाभ किसी के जोखिमों के लायक हैं, तो कई जगहों पर बग को ठीक करना भूल जाते हैं।

उस सलाह को ध्यान में रखते हुए, यह आपके मामले में लगता है

कुछ मामूली ट्वीक के साथ एक ही प्रक्रिया को कई बार दोहराएं

मैं निश्चित रूप से आपके मामले में खुद को नहीं दोहराने के लिए कड़ी मेहनत करूंगा। न्यूनतम "ट्विक्स" मानते हुए - उन्हें विभिन्न मापदंडों के साथ नियंत्रित किया जा सकता है जो व्यवहार या शायद निर्भरता-इंजेक्शन को प्रभावित करने के लिए विभिन्न उप-कार्य करते हैं।

डीआरवाई क्यों करें जब ऐसा लगता है कि त्वरित कट + पेस्ट इतना कम काम हो सकता है?

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

Comments

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

— गुप्त

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

— गुप्त

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

— मथिउ एम।

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

— सुपरकट

@ MATthieuM यह एक अनुचित उदाहरण का एक सा है। एलएलवीएम एक अनुकूलन के रूप में संरचनात्मक टाइपिंग लागू कर रहा है ; यही है, LLVM के लोगों ने प्रदर्शन लाभ के लिए मुश्किल-से-समझने वाले IR की कीमत का भुगतान करने का निर्णय लिया। DRY आमतौर पर एक रख-रखाव का मुद्दा है लेकिन इस मामले में यह स्पष्ट रूप से स्थिरता को कम करने का एक जानबूझकर निर्णय था।

— बेंजामिन हॉजसन

Answer 2

क्योंकि DRY बाद में कम काम होगा।

---

DRY: (खुद को दोहराएं नहीं)

एक समारोह एक तर्क ले रहा है।

def log(arg):
    print(arg)

C & P: (कॉपी और पेस्ट करें)

26 गज़िलियन फ़ंक्शंस अनिवार्य रूप से एक ही काम करते हैं, लेकिन 2 चर अंतर के साथ।

def logA():
    print('a')

def logB():
    print('b')

...ad infinitum...

---

कैसे हम अपने मुद्रण को अपडेट करने के बारे में बताएं कि वास्तव में मुद्रण क्या है?

सूखी:

def log(arg):
    print(arg + "Printed from process foo")

किया हुआ।

सी एंड पी:

आपको वापस जाना होगा और हर एक फंक्शन को बदलना होगा ।

---

जो आपको लगता है कि डिबग करना आसान होगा?

Comments

इसके अलावा, आपको कई समान परीक्षण सूट लिखने की आवश्यकता है क्योंकि आपके पास डुप्लिकेट फ़ंक्शन हैं।

— 9000

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

— रॉबर्ट हार्वे

@ मुझे उम्मीद है कि नहीं होगा! मैंने अवधारणा को बेहतर ढंग से समझाने की कोशिश करने के लिए एक बहुत ही सरल काम उठाया और यह एक अच्छी बात क्यों हो सकती है।

— जॉन

@Robert - क्या आपने thedailywtf.com पर कोई भी लेख पढ़ा है ;) - कुछ ऐसे भी हैं, जो ऐसा करेंगे

— HorusKol

@ 9000 नहीं यदि आपके पास कोई परीक्षण सूट नहीं है: पी (जो वास्तव में अक्सर कुछ परियोजनाओं में मामला हो सकता है ... दुर्भाग्य से ...)

— श्वेत

Answer 3

क्योंकि , आपके उदाहरण पर लागू होता है:

• + पठनीयता

  कम कोड अक्सर कम शोर में तब्दील हो जाता है । _{(हर बार नहीं...)}

• + लचीलापन

  यदि आपको कभी भी व्यवहार को बदलना पड़ा doStuffX, तो आप खुद को मारना चाहते हैं या जिसने भी इसे लिखा है,

• + एक्स्टेंसिबिलिटी

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

• + लागत दक्षता

  यहां कम कोड का मतलब है:

  • => कम विकास => कम लागत
  • => बग के लिए कम संभावना => कम समर्थन समय => कम लागत

• + (संभव) प्रबंधित अनुकूलन

  भाषा के आधार पर, कंपाइलर / दुभाषिया के पास यह निर्धारित करने का एक बड़ा मौका हो सकता है कि जेनेरिक doStuffहमेशा लगभग समान चीजें अक्सर एक के बाद एक कॉल करता है, और इसे इनलाइन कर सकता है या इसे अनुकूलित करने का प्रयास कर सकता है। शायद एक्स विविधताओं के लिए नहीं होगा doStuffX।

• + परीक्षण और गुणवत्ता

  परीक्षण आसान है: doStuffपरीक्षण की आवश्यकता है, और यह बात है। ठीक है, बिल्कुल नहीं, लेकिन यह पहले से ही अधिक शामिल है । केवल इसकी IO अपेक्षाएँ बदलती हैं और अलग-अलग परिस्थितियों में परीक्षण करने की आवश्यकता होती है, लेकिन यह अभी भी परीक्षण करना आसान है और सभी विविधताओं की तुलना में अधिक बनाए रखने योग्य है doStuffX।

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

Answer 4

चूंकि सभी ने डुप्लिकेट कोड के साथ स्थिरता के मुद्दों की व्याख्या करने में एक महान काम किया है, मैं सिर्फ यह कहूंगा:

अधिकांश प्रोग्रामिंग के लिए आपको भविष्य के बारे में सोचने की आवश्यकता होती है, न कि केवल वर्तमान में। आप सही कह रहे हैं कि कॉपी और पेस्ट अब आसान है, लेकिन बयान, मुझे जल्द ही इसे फिर से संपादित करने की आवश्यकता नहीं है " शो सही ढंग से नहीं सोच रहा है। हां, आप अपने आप को थोड़ा समय के साथ खरीद सकते हैं। त्वरित और गंदी कॉपी / पेस्ट, लेकिन ऐसा करने में आप दिखा रहे हैं कि आप अपनी तत्काल समस्या से आगे नहीं बढ़ सकते हैं और कल के बारे में सोच सकते हैं। क्या आप सकारात्मक हैं आपको इस कोड को फिर से लिखने की आवश्यकता नहीं होगी? क्या आप कुछ के लिए जानते हैं? इसमें कोई बग नहीं है? क्या आप 100% गारंटी दे सकते हैं जब आपके द्वारा सुविधाओं के अगले सेट को लागू करने की आवश्यकता होती है, तो आपको इसे फिर से चालू करने की आवश्यकता नहीं होगी? वे कल के लिए समस्याएँ हैं, और जब आप आज डिजाइन कर रहे हैं, तो विचार करने की आवश्यकता है।

बेशक, ऐसे समय होते हैं जब कॉपी / पेस्ट आवश्यक होगा। UI डेवलपर के रूप में, मैंने पाया है कि कई बार मुझे DRY सिद्धांत का उल्लंघन करना पड़ता है। यह बेकार है, मैं हर बार ऐसा होता है, और शुक्र है, यह दुर्लभ है। लेकिन ऐसा होता है।

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

इसे गलत तरीके से न लें: मैं आपको कास्ट करने या पीछा करने की कोशिश नहीं कर रहा हूं, बल्कि कोशिश करें और देखें कि आपकी मानसिकता गलत है या नहीं। प्रोग्रामर भविष्य के आलस्य में निवेश करते हैं; DRY उसे प्राप्त करने का एक तरीका है। आज आप एक कठिन डिजाइन समस्या को हल करने का काम कल भुगतान करेंगे।

Comments

मुझे यकीन नहीं है कि मैं एक बॉस से सहमत हूं जो आपको बता रहा है कि "यह किया जाए या आपको निकाल दिया जाए" DRY का उल्लंघन करने का एक बड़ा कारण है। तकनीकी ऋण, आपके पास इसे सही करने का समय कब है, क्या यह वास्तव में समय की बचत है, आदि?

— गुप्त

@ इनकॉग्निटो, मैं थोड़ा विडंबनापूर्ण बनने की कोशिश कर रहा था :)

— शयनकक्ष

Answer 5

मुझे जल्द ही किसी भी समय इसे फिर से संपादित करने की आवश्यकता नहीं है।

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

यदि आप सामान्य कर सकते हैं कि आप किस समस्या को हल करने का प्रयास कर रहे हैं, तो बग्स पॉप अप होने पर आपके कोड को बढ़ाने और ठीक करने में आसान बना सकते हैं।

Comments

ठंडा जवाब, लेकिन अगर मैं इसके साथ दूर हो सकता हूं, तो उस गरीब के बारे में क्या जो मेरे बाद इसे बनाए रखने के लिए मिलता है? ;)।

— गुप्त

देखें: "अधिक बार आप उस कोड पर काम नहीं करने जा रहे हैं जिसे बनाए रखने की आवश्यकता है" :)

— एलेक्स

फिर भी यह केवल मामला है यदि आप जो कॉपी और पेस्ट कर रहे हैं वह 100% बग-मुक्त पूर्णता है। और यह नहीं है, और यह सोचना बंद करो कि यह हो सकता है।

— डैन रे

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

— एलेक्स

Answer 6

जैसा कि मैंने एक अन्य प्रश्न के उत्तर में कहा था, मेरा दृष्टिकोण निम्नलिखित है:

1. पहली बार जब मैं एक निश्चित समस्या को हल करता हूं, तो मैं इसे पूरा कर लेता हूं।
2. दूसरी बार (यानी जब मैं इसी तरह की समस्या को हल करता हूं) मुझे लगता है: एचएम, शायद मैं खुद को दोहरा रहा हूं, लेकिन मैं अभी के लिए एक त्वरित कॉपी-एंड-पेस्ट के लिए जाऊंगा।
3. तीसरी बार मुझे लगता है: हम्म, मैं खुद को दोहरा रहा हूं -> इसे सामान्य करूं!

2 अप करने के लिए, एक और सिद्धांत (YAGNI) DRY पर जीतता है। लेकिन 3 से शुरू (या 4 अगर मैं वास्तव में आलसी हूं!) ऐसा लगता है कि मुझे इसकी आवश्यकता है और इसलिए मैं DRY का पालन करता हूं।

अपडेट करें

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

इसलिए मैंने इन दोनों घटकों (जिनमें से प्रत्येक में लगभग 8 C ++ वर्ग होते हैं) को फिर से बनाना शुरू कर दिया: मैं ए और बी दोनों के लिए एक सामान्य वास्तुकला रखना चाहता था, और फिर उपवर्गों को परिभाषित करके हमारे द्वारा आवश्यक सुविधाओं को जोड़ना। इस तरह, हमारे दो नए घटक ए 'और बी' मौजूदा लोगों से प्राप्त हुए होंगे।

दो हफ्तों के बाद मौजूदा कोड से एक आम और अच्छी तरह से परिभाषित संरचना प्राप्त करने की कोशिश करने और हमारी दैनिक बैठकों के दौरान यह समझाने के लिए कि मैं बहुत कम प्रगति कर रहा था क्योंकि मूल कोड बहुत गड़बड़ था, मैंने अपने बॉस से बात की। हमने देखा कि हमें इन दो नए घटकों A 'और B' से अधिक कुछ भी नहीं चाहिए (उनमें से चार या छः नहीं थे, सिर्फ उन दो)।

ठीक है, इसलिए ऐसा हो: मैंने ए और बी से कक्षाओं की बड़े पैमाने पर प्रतिलिपि बनाई और नाम बदल दिया और कोड की प्रतिलिपि को अनुकूलित करना शुरू कर दिया। मुझे यह दो और हफ्तों में काम करने के लिए मिला (अभी भी कुछ बग फिक्सिंग कर रहा हूं)।

लाभ: हमारे पास कार्यक्षमता अब लगभग समाप्त हो चुकी है और जब हमने सभी कीड़े समाप्त कर लिए हैं। हमने ए और बी के सभी रीफैक्टरिंग और परीक्षण को बचा लिया है।

नुकसान: दो हफ्ते पहले दूसरी टीम ने एक और घटक सी को बदल दिया, जिसका उपयोग ए और बी द्वारा किया जाता है। उन्होंने ए और बी को अनुकूलित किया लेकिन ए 'और बी' भी टूट गया और हमें उन्हें स्वयं बदलना पड़ा। इसने एक नया बग पेश किया जिसे हमें ठीक करना था। यह अतिरिक्त काम शायद अनावश्यक होता अगर A 'और B' ने अपने कोड का अधिकांश भाग A और B के साथ साझा किया होता।

तो: कोड दोहराव हमेशा खतरनाक होता है। मुझे लगता है कि यह हमेशा व्यापार से दूर रहने की बात है और अक्सर यह आसान नहीं होता है।

Answer 7

बस स्पष्ट करने के लिए, क्योंकि मुझे यह किसी अन्य उत्तर में नहीं मिला:

DRY सभी प्रकार की सूचनाओं की पुनरावृत्ति को कम करने के उद्देश्य से सॉफ्टवेयर विकास का एक सिद्धांत है ।

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

एंडी हंट और डेव थॉमस द्वारा उल्लिखित DRY सिद्धांत कोड के दोहराव को रोकने तक सीमित नहीं है। यह कोड पीढ़ी और किसी भी स्वचालन प्रक्रियाओं की भी वकालत करता है। विडंबना यह है कि कोड पीढ़ी के परिणाम भी डुप्लिकेट कोड हो सकते हैं ...

इसका कारण पहले से ही अन्य उत्तरों में अच्छी तरह से समझाया गया है, लेकिन फाल्कन की टिप्पणी ने इसे पर्याप्त रूप से आईएमएचओ कहा है:

परिवर्तन का एक बिंदु बनाए रखना आसान है।

Comments

अरे वाह, मुझे लगा कि टैग में कुछ डेटा था। मैं वहाँ कुछ जानकारी रखूँगा।

— गुप्त

Answer 8

वहाँ बहुत DRY के रूप में ऐसी बात है। जब ऐसा होता है, तो दो अवधारणाएं जो कुछ बिंदु पर दिखाई देती हैं, वे वारंट फैक्टरिंग कोड के समान होती हैं (1) बाद में अलग-अलग हो सकती हैं जो अलग-अलग कार्यान्वयन के योग्य हैं।

दूसरे शब्दों में, कभी-कभी DRY और ढीले कपलिंग में टकराव होता है। यदि आप doStuff1 और दोस्तों को सॉफ़्टवेयर की हर नई रिलीज़ के साथ डायवर्ज करने की उम्मीद करते हैं, तो उनके कोड को डुप्लिकेट करना ठीक है।

मेरे अनुभव में, यह आंकना मुश्किल हो सकता है कि भविष्य में आपका सॉफ़्टवेयर कहां जा रहा है और इस कारण से, DRY अक्सर एक सुरक्षित विकल्प होता है।

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

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

(1) मैं "कोड" शब्द का उपयोग कर रहा हूं, लेकिन यह डिजाइन पर भी लागू होता है।

Comments

यह "बहुत अधिक शुष्क" का उदाहरण देने में सहायक होगा क्योंकि यह स्पेक्ट्रम का कम देखा हुआ अंत है।

— इनकॉगनिटो

@ गुप्त: मैंने अपना उत्तर संपादित कर लिया है। कोई ठोस उदाहरण नहीं है, लेकिन उम्मीद है कि मेरा मतलब पर्याप्त स्पष्ट है।

— जोह

Answer 9

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

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

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

मैं किस बारे में बात कर रहा हूं इसके उदाहरण। आपको महीने में एक बार एक लाख रिकॉर्ड का डेटा आयात करने की आवश्यकता है। रिकॉर्ड पहले से ही एक संग्रहीत खरीद कॉल करने वाले उपयोगकर्ता इंटरफ़ेस के माध्यम से मैन्युअल रूप से जोड़ा जा सकता है। यह खरीद, क्योंकि यह एकल रिकॉर्ड आयात के लिए डिज़ाइन किया गया था, केवल एक समय में एक रिकॉर्ड जोड़ता है। डीआरवाई का उपयोग दो स्थानों में डालने के कोड से बचने के लिए, आप सेट-आधारित आयात लिखने के बजाय बार-बार खरीद को कॉल करने के लिए एक कर्सर लिखते हैं। आयात के लिए समय 30 मिनट से 18 घंटे तक सेट-आधारित तर्क का उपयोग करेगा। अब इस मामले में DRY का पालन करने का सही तरीका यह होगा कि mulitple रिकॉर्ड आयात को संभालने के लिए खरीदारी को ठीक किया जाए। दुर्भाग्य से, किसी सरणी को किसी प्रोक में भेजना (db बैक एंड पर निर्भर करता है) के लिए अक्सर असंभव या बहुत मुश्किल होता है और प्रोक को बदलकर आप एप्लिकेशन को तोड़ देते हैं।

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

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

Answer 10

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

Comments

DRY का मुझ पर बहुत अलग प्रभाव है, हालाँकि, अगर ये आप पर इसके प्रभाव हैं, तो मुझे यह पसंद है कि किसी चीज़ का दर्शन "रुकने, सोचने और बेहतर उत्तर खोजने का संकेत" और चुनौतीपूर्ण है।

— n611x007

Answer 11

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

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

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

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

Answer 12

यदि आप थ्रोवेवे कोड लिख रहे हैं तो हाँ, DRY के बारे में परेशान न हों ।

लेकिन DRY जरूर महत्वपूर्ण है, अगर आप कोड रखने की योजना बनाते हैं।

Answer 13

वाक्यांश "अपने आप को दोहराना नहीं है" एक छोटा सा निरीक्षण है। क्या महत्वपूर्ण है "दो स्वतंत्र स्थानों में संभावित रूप से अस्थिर सूचना के एक टुकड़े को रखने से बचें ।"

यदि किसी प्रोग्राम को विगेट्स को प्रोसेस करना है, तो प्रत्येक में तीन वूज़ल्स हैं, और फॉर्म के कई लूप हैं

for (i=0; i<3; i++)
  thisWidget.processWoozle(i);

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

#define WOOZLES_PER_WIDGET 3

और प्रत्येक लूप को फिर से लिखा गया

for (i=0; i<WOOZLES_PER_WIDGET; i++) ...

इस तरह के डिज़ाइन से प्रति विजेट woozles की संख्या को बदलना बहुत आसान हो सकता है ।

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

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

Answer 14

जबकि मैं वास्तव में अन्य पोस्टरों के साथ बनाए रखने की टिप्पणियों आदि से सहमत हूं, जो सभी मान्य हैं।

मैं बहस के लिए एक छोटी सी असंतुष्ट आवाज जोड़ना चाहूंगा।

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

Comments

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

— ozz

मैं पूरी तरह से असहमत हूँ। अच्छे प्रबंधन के सिद्धांतों को समझेंगे और अगर उन्हें विस्तार से बताया जाए तो वे क्यों किए जा रहे हैं। यह गंभीर बातचीत होनी चाहिए, न कि 5 मिनट की चीज से।

— माइकल डुरंट

आपका दूसरा बुलेट पॉइंट पूरी तरह से सही है।

— जिम जी।

@ ठीक है, अपने शिल्प में गर्व एक अच्छा प्रोग्रामर के लिए भी आवश्यक है, लेकिन, शायद "प्रोग्रामर बिंदु" को "ग्राहक संतुष्टि" के लिए चिंता का एक तरीका शामिल करना चाहिए।

— जेम्स एंडरसन

Answer 15

<tl;dr>

मैं सभी दोहराए गए जवाबों को नहीं पढ़ सकता था इसलिए मुझे कुछ याद हो सकता है (और इसे खुद दोहराएगा <= देखें कि मैंने यहां क्या किया है))।

यहां उन चीजों की सूची दी गई है जो कोड दोहराव को रोकने के बारे में भयानक हैं!

1. परीक्षण करने में आसान: आपको केवल कोड की एक 'कॉपी' का परीक्षण करना होगा।
2. ठीक करने के लिए आसान: आपको केवल कोड की एक 'कॉपी' में बग को ढूंढना होगा और इसे एक बार ठीक करना होगा।
3. अद्यतन करने के लिए आसान (ऊपर के रूप में): आवश्यक बदलाव, अक्सर बहुत कम स्थानों में कोड को संशोधित करके नियंत्रित किया जा सकता है क्योंकि आपने कोड को ठीक से पुन: उपयोग करने के लिए समय लिया था और स्रोत में सैकड़ों या हजारों विभिन्न स्थानों पर समान पंक्तियों की नकल नहीं की थी।
4. पुन: उपयोग करने में आसान: जब (कुछ स्थानों पर डुप्लिकेट नहीं किया जाता है) और सामान्य रूप से नामित विधियों में रखा जाता है, तो उन्हें ढूंढना और उन्हें लिखने के बजाय उनका उपयोग करना आसान है।
5. पढ़ने में आसान: डुप्लिकेटेड कोड को पढ़ना मुश्किल है क्योंकि यह अनावश्यक रूप से क्रिया है; इसमें बहुत सी लाइनें शामिल हैं जो तर्क का हिस्सा नहीं हैं और विशिष्ट इच्छित कार्यक्षमता (उदाहरण के लिए जेनेरिक कमांड का उपयोग कार्रवाई करने के लिए मंच को सेट करने के लिए या सामान्य सरल दोहराए जाने वाले कार्यों को करने के लिए किया जाता है जिनकी कई स्थानों पर आवश्यकता होती है)। क्लीन कोड तर्क और कार्यक्षमता को पॉप-आउट बनाता है क्योंकि कोड-स्पेस को दोहराते हुए कोई पुनरावृत्ति नहीं होती है।
6. (1) और (5) के कारण डिबग करने में आसान।
7. आपको समय और पैसा बचाता है और भविष्य में और अधिक मजेदार चीजें करता है; विशेष रूप से बेहतर अधिक मजबूत कोड बनाएं। यह नीचे की रेखा है और यह उपरोक्त सभी के बहुत अधिक योग है। यदि बहुत से लोग एक ही फ़ंक्शन का उपयोग करते हैं doFoo1(a, b), तो बेहतर मौका है कि इसके कई कष्टप्रद दोष और किनारे के मामलों को उजागर और हल किया जाएगा। यदि हर कोई कोड की प्रतिलिपि बनाता है और बनाता है doFoo2(specialA)... doFuu2^n(a, b, c)तो उन्होंने समस्याओं को दोहराया doFoo1और बहुत अधिक काम किया।

</tl;dr>

दीर्घ संस्करण:

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

एक और बात यह है कि एक नौसिखिए के लिए यह एक मुद्दे की तरह लग सकता है जो केवल बड़ी कंपनियों को प्रभावित करेगा लेकिन मैंने पाया कि यह छोटे स्टार्टअप को एक बुरी तरह से प्रभावित करता है (जैसे कि डुप्लिकेट किए गए सर्वर-साइड कोड की 10,000 लाइनों में)। यह एक मानसिक अवस्था है। आपको न केवल DRY में महारत हासिल करनी चाहिए बल्कि दूसरों को भी ऐसा करने के लिए प्रोत्साहित करना चाहिए; क्योंकि अन्यथा आप ज्यादातर डुप्लिकेट कोड के लिए खुद को बर्बाद करेंगे। जब DRY के साधन हाथ में हैं और लागू किए गए हैं, तो उन्हें लागू करना बहुत आसान है। जब बहुत सारे डुप्लिकेट कोड होते हैं, तो कॉपी पेस्ट समाधान लागू करना बहुत आसान होता है।

कोड डुप्लीकेशन में जो चीजें मुझे हानिकारक लगती हैं:

1. क्या यह कार्य प्रयोग करने योग्य है? मान लीजिए कि आप एक ऐसा फ़ंक्शन ढूंढते हैं जो करता है (या वह करता है जो आपको आवश्यक है), आपको कैसे पता चलेगा कि क्या यह सही तरीके से काम करना है या यदि यह सिर्फ कोड है जिसे डुप्लिकेट और छोड़ दिया गया है।
2. निरर्थक कोड। कभी-कभी लोग डुप्लिकेट कोड, इसका उपयोग करते हैं और इसे भूल जाते हैं (वे इसे भविष्य में फिर से डुप्लिकेट कर सकते हैं)। किसी बिंदु पर कोई व्यक्ति प्रतिक्षेपक के प्रयास में कुछ स्थानों पर डुप्लिकेट किए गए फ़ंक्शन को कॉल हटाता है, लेकिन अप्रयुक्त फ़ंक्शन तब भी रहता है जब यह सक्रिय रूप से उपयोग नहीं किया जा रहा हो।
3. आप जो ढूंढ रहे हैं, उसे पाना मुश्किल है। डुप्लिकेटेड कोड जगह लेता है और उपयोगी और आवश्यक चीजों (grep जैसे उपकरणों का उपयोग करके) को खोजने से कठिन कार्य करता है क्योंकि आपको दर्जनों या हजारों परिणाम मिलते हैं, जहां आपको केवल एक मुट्ठी भर मिलना चाहिए था।
4. (पहले उल्लेख किया गया है): रखरखाव और प्रतिगमन उद्देश्यों के लिए उपयोग करने के लिए कड़ी मेहनत लेकिन भी मुश्किल है। यदि परीक्षण कोड को डुप्लिकेट किया गया है और फ़ंक्शन में ठीक से नहीं निकाला गया है, तो अन्य इसे डुप्लिकेट करेंगे। क्या कोई QoL को बेहतर बनाने के लिए API को पढ़ने में आसान, उपयोग करने में आसान लिखने के साथ परेशान करेगा? मेरे अनुभव में, नहीं, अक्सर ऐसा कुछ होता है जब लोग हाथ से निकलने तक अधिक दबाने वाले पदार्थ को दबा देते हैं।
5. कोड दोहराव को पढ़ना कठिन है क्योंकि यह कोड क्रिया को बनाता है जहां उसका होना आवश्यक नहीं है, उन स्थानों पर जहां क्रियाशीलता इच्छित कार्यक्षमता के बारे में जानकारी नहीं जोड़ती है: उदाहरण के लिए जेनेरिक विधि कॉल जिनका उपयोग किया जाता है [पर और अधिक] विभिन्न प्रकार की इच्छित कार्यक्षमता के लिए जमीन सेट करें, इस वास्तविक कार्यक्षमता को पॉप आउट करने के लिए कठिन बनाता है।
6. इसका उल्लेख बहुत किया गया है। यदि कोड गलत है, तो कुछ गरीब गैल या आदमी को उस कोड के प्रत्येक उपयोग को खोजने और बदलने की आवश्यकता होगी। उदाहरण के लिए, यदि किसी ने वर्ग कक्षा में बहुत कम स्थानों पर mysql_query में SQL इंजेक्शन असुरक्षित कॉल का उपयोग किया है, जहाँ इसकी आवश्यकता है, तो इसे ठीक करना आसान होगा और इसके बजाय PHP PDO का उपयोग करना होगा, लेकिन यदि वे इसे एक हजार से अधिक स्थानों पर कॉल की नकल करते हुए उपयोग करते हैं और ओवर, इसे ठीक करने के लिए व्यावहारिक रूप से आउटसोर्स करने की आवश्यकता होगी या कभी-कभी अधिक खतरनाक तरीके से, कोड को स्क्रैच से फिर से लिखना होगा।
7. डुप्लिकेट कोड एक बुरी आदत है। यदि आप कुछ अभ्यास करते हैं तो यह धीरे-धीरे एक दूसरा स्वभाव बन जाता है और यह आपके आस-पास के लोगों को प्रभावित करता है। जूनियर देवता आपको ऐसा करते हुए देखते हैं और करते भी हैं। आपको जो उपदेश देना है उसका अभ्यास करना चाहिए और सही काम करने की आदत डालनी चाहिए। आप और जानें। गैर-डुप्लिकेट कोड लिखना कठिन और अधिक चुनौतीपूर्ण है। यह एक पुरस्कृत आदत है।

अति उत्साही कोड दोहराव की रोकथाम और चीजों को समेटने के बारे में अंतिम नोट्स:

यह पहले भी कहा जा चुका है लेकिन कभी-कभी दोहराव से बचने के कारण आप "पीछे की ओर झुकते हैं" और ऐसे काम करते हैं जो दूसरों के समझने के लिए बहुत परिष्कृत (या महत्वहीन) होते हैं। अपठनीय कोड लिखना (या जैसा कि हम मजाक में इसे "नौकरी संरक्षण" कोड कहते हैं) अपने आप में एक मुद्दा है, यहां तक ​​कि जब कोड डुप्लिकेट को रोकना शामिल नहीं है। हालाँकि, मुझे लगता है कि अगर सही बुनियादी ढाँचे और सर्वोत्तम प्रथाओं को शुरू से ही लागू किया जाए तो कोड डुप्लीकेशन को रोकना बहुत आसान है और लोग अक्सर बेकार की बातों को करने से बच सकते हैं ताकि यह कोड डुप्लिकेट रोकथाम के लिए किए जाने वाले भविष्य के अनावश्यक और अपठनीय कार्यों को रोका जा सके आप उस शुरुआत से ही सही काम करते हैं।

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