क्या ऐसे असाधारण मामले हैं जहाँ हम डुप्लिकेट कोड स्वीकार कर सकते हैं?

Question

मैं एक सॉफ्टवेयर प्रोजेक्ट पर काम कर रहा हूं, जहां हमें तीन एपीआई बनाने हैं। के लिए एक घर बैंकिंग चैनल, के लिए एक एजेंसी चैनल और के लिए एक तिहाई मोबाइल चैनल।

एजेंसी एपीआई सबसे अधिक पूर्ण है क्योंकि इसमें सभी कार्य हैं .. फिर थोड़ा छोटा होम एपीआई और फिर मोबाइल एपीआई।

यहाँ के वास्तुकारों ने एक आम परत बनाई (सभी एपीआई द्वारा साझा क्रॉस चैनल EJB सेवाएं)। लेकिन तब एपीआई अलग हैं।

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

मूल रूप से कंट्रोलर चैनलऑबजेक्ट को मैपिंग बीओ कर रहे हैं (ऐसा लगता है कि मुझे ऐसा करने के लिए सही जगह नहीं है), और कुछ अतिरिक्त उपयोगिताओं और धारावाहिक। अभी के लिए सब डुप्लिकेट है। वे कह रहे हैं कि नकल का कारण वे एपीआई स्वतंत्र चाहते हैं। "अगर कल हम एजेंसी या मोबाइल से अलग व्यवहार चाहते हैं तो हम संघर्ष नहीं करेंगे !!"

क्या कोई ऐसा मामला है जहां हमें डुप्लिकेट कोड स्वीकार करना चाहिए?

Comments

और अगर तीन कल सड़क पर उतरते हैं, तो वे तय करते हैं कि वे सभी एपीआई के बीच लगातार डेटा एक्सेस और प्रतिनिधित्व चाहते हैं ... अच्छी तरह से ... "स्ट्रगल!"

— बज़्ज़

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

— डेविड अर्नो

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

— Kay पर माइकल Kay

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

— पीटर जार्जेंस

एक तुच्छ मामला जहां डुप्लिकेट कोड स्वीकार्य हो सकता है यदि यह ऑटो-जेनरेट किया गया है

— samgak

Answer 1

दोहराव कर सकते हैं करने के लिए सही बात हो, लेकिन इस कारण के लिए नहीं।

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

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

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

Comments

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

— Deduplicator

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

— केरेन

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

— opa

एक उदाहरण जहां दोहराव उपयोगी है (और "इसे अब आपको पूरी तरह से और अधिक महंगा बनाना है ") वेब अनुप्रयोगों में इनपुट सत्यापन है: हम क्लाइंट पर पहले (संभवतः सरलीकृत) सत्यापन को नियोजित करते हैं ताकि उपयोगकर्ता को समस्याओं के बारे में तत्काल प्रतिक्रिया मिल सके; और फिर हम सर्वर पर एक ही (या अधिक गहन) सत्यापन करते हैं क्योंकि ग्राहकों पर भरोसा नहीं किया जा सकता है।

— हेगन वॉन एटिजन

@HagenvonEitzen लेकिन तकनीक स्टैक के आधार पर, दोहराव की भी आवश्यकता नहीं है। उदाहरण के लिए, आपके पास ब्राउज़र में जावास्क्रिप्ट चेक इनपुट और सर्वर पर जावा चेक हो सकता है, इसलिए आपके पास डुप्लिकेट की गई कार्यक्षमता है। लेकिन अगर आप सर्वर पर Node.js चलाना चाहते थे, तो आप डुप्लिकेट को समाप्त करते हुए ब्राउज़र में और सर्वर पर एक ही जावास्क्रिप्ट सत्यापन का उपयोग कर सकते थे। आप अब भी चाहते हैं कि कोड कई स्थानों (भरोसेमंद और अविश्वसनीय वातावरण) में चले , लेकिन कोड का डुप्लिकेट होना आवश्यक नहीं है।

— जोशुआ टेलर

Answer 2

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

दोहराव गलत अमूर्तता की तुलना में कहीं सस्ता है

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

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

Comments

आह हाँ, यदि आप सामान्यीकृत नियमों को नहीं काट सकते हैं, तो उन्हें अमूर्त करने की कोशिश केवल विफल हो सकती है। और यदि पत्राचार संयोग है, तो यह अल्पकालिक हो सकता है।

— डेडुप्लिकेटर

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

— लेफ्टरेंबाउट

Answer 3

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

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

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

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

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

Comments

मेरे लिए "अगर कल" से भी बड़ा चेतावनी संकेत है "वह कभी नहीं बदलेगा"।

— अबुजितिन गिलिफ़िस्का

@abuzittingillifirca: और इसका सवाल या मेरे जवाब से क्या लेना-देना है?

— डॉक्टर ब्राउन

मैं आपके पहले पैराग्राफ को चुनौती दे रहा हूं।

— अबुजितिन गिलिफ़िर्का

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

— डॉक्टर ब्राउन

Answer 4

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

तो आप स्वायत्तता और स्वतंत्रता हासिल करने के लिए डुप्लिकेट कोड की कीमत चुका रहे हैं।

Comments

तो यह युग्मन से बचने के लिए अंतर-घटक दोहराव है। लेकिन आप अभी भी इंट्रा-घटक दोहराव से बचना चाहेंगे, है ना?

— टेम्प्लेटेक्स

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

— बोरबिज