मैं अज्ञात डुप्लिकेट कोड को कैसे रोकूं?


33

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

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

मैं कोड बेस के लिए नया हूं, लेकिन टीम लीड जो वर्षों से इस पर काम कर रहा है, वही समस्या है। यह बहुत सारे कोड और काम दोहराव की ओर जाता है, और इस तरह, जब कुछ टूटता है, तो यह आमतौर पर मूल रूप से एक ही कोड की 4 प्रतियों में टूट जाता है

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

इसके अलावा, उपयोगिता फ़ंक्शंस आमतौर पर या तो कुछ स्टेटिक हेल्पर क्लास में होते हैं, कुछ नॉन-स्टैटिक हेल्पर क्लास में होते हैं जो किसी एक ऑब्जेक्ट पर काम करते हैं, या क्लास पर एक स्टैटिक तरीका होता है, जिसमें यह मुख्य रूप से "हेल्प" करता है।

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


जवाबों:


30

इसका सरल उत्तर यह है कि आप वास्तव में कोड के दोहराव को नहीं रोक सकते। हालांकि आप इसे एक कठिन सतत दोहराव वृद्धिशील प्रक्रिया के माध्यम से "ठीक" कर सकते हैं जो दो चरणों में उबलती है:

चरण 1. विरासत कोड पर परीक्षण लिखना शुरू करें (अधिमानतः परीक्षण ढांचे का उपयोग करके)

चरण 2. परीक्षणों से सीखी गई बातों का उपयोग करके डुप्लिकेट किए गए कोड को फिर से लिखना / फिर से लिखना

आप डुप्लिकेट किए गए कोड का पता लगाने के लिए स्थैतिक विश्लेषण टूल का उपयोग कर सकते हैं और C # के लिए ऐसे उपकरणों का भार है जो आपके लिए ऐसा कर सकते हैं:

इस तरह के उपकरण आपको कोड में अंक खोजने में मदद करेंगे जो समान चीजें करते हैं। यह निर्धारित करने के लिए परीक्षण लिखना जारी रखें कि वे वास्तव में क्या करते हैं; उपयोग करने के लिए डुप्लिकेट कोड को सरल बनाने के लिए समान परीक्षणों का उपयोग करें। यह "रीफैक्टरिंग" कई तरीकों से किया जा सकता है और आप इस सूची का उपयोग सही निर्धारण के लिए कर सकते हैं:

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

  1. परिवर्तन बिंदुओं को पहचानें
  2. परीक्षण बिंदु खोजें
  3. निर्भरता को तोड़ो
  4. परीक्षण लिखिए
  5. बदलाव और रिफलेक्टर करें

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

इस मामले में

ओपी के मामले में मैं कल्पना कर सकता हूं कि "उपयोगिता विधियों और ट्रिक्स" के लिए एक अनचाहे कोड का कारण शहद का बर्तन होता है जो कई रूप लेता है:

ध्यान दें कि इनमें कुछ भी गलत नहीं है, लेकिन दूसरी ओर वे आमतौर पर बनाए रखने और बदलने के लिए कठिन हैं। .NET में एक्सटेंशन्स मेथड स्टैटिक मेथड हैं, लेकिन टेस्टिंग में अपेक्षाकृत आसान हैं।

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

चूंकि ओपी कोड में नया है, इसलिए आपको कुछ भी करने से पहले कुछ अन्य चीजें करनी चाहिए:

  • कोडबेस से सीखने के लिए समय निकालें, यानी "सब कुछ" तोड़ें, "सब कुछ" का परीक्षण करें, वापस लौटें।
  • करने से पहले अपने कोड की समीक्षा करने के लिए टीम के किसी व्यक्ति से पूछें। ;-)

सौभाग्य!


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

@ एर्लज़: स्टेटिक कोड विश्लेषण बहुत बढ़िया है! ;; इसके अलावा, जब भी आपको बदलाव करने की आवश्यकता हो, तो बदलावों को आसान बनाने के लिए समाधानों के बारे में सोचें (इस के लिए पैटर्न कैटलॉग के लिए
रिफलेक्टर की जांच

+1 अगर मैं इस क्यू को "अतिरिक्त मददगार" के रूप में पुरस्कृत करने के लिए किसी व्यक्ति ने इस क्यू पर इनाम रखा तो मुझे समझ में आएगा। रिफ्लेक्टर टू पैटर्न कैटलॉग सोना है, इस तरह की चीजें GuidanceExplorer.codeplex.com के फैशन में शानदार प्रोग्रामिंग एड्स हैं।
जेरेमी थॉम्पसन

2

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

मैंने हाल ही में पुस्‍तक सॉफ़्टवेयर इंजीनियरिंग को पुन: प्रयोज्य घटकों के साथ पढ़ा और यह वास्तव में संगठन स्तर पर कोड पुन: प्रयोज्य को बढ़ावा देने के लिए बहुत ही दिलचस्प विचारों का एक सेट है।

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

वैचारिक और तकनीकी

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

अन्य बुनियादी तकनीकी कठिनाइयों में शामिल हैं

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

लेखक के अनुसार, किसी संगठन की परिपक्वता के आधार पर पुन: प्रयोज्य के विभिन्न स्तर होते हैं।

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

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


1

2 संभावित उपाय हैं:

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

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

मुझे व्यक्तिगत रूप से नहीं लगता कि रोकथाम संभव है। जितना अधिक आप कोशिश करते हैं, उतना ही यह पहले से मौजूद सुविधाओं को खोजने के लिए समस्याग्रस्त है।


0

मुझे नहीं लगता कि इस तरह की समस्याओं का सामान्य समाधान है। यदि डेवलपर्स के पास मौजूदा कोड देखने के लिए पर्याप्त इच्छा है तो डुप्लिकेट कोड नहीं बनाया जाएगा। साथ ही डेवलपर्स यदि चाहें तो मौके पर समस्याओं को ठीक कर सकते हैं।

यदि भाषा C / C ++ डुप्लीकेशन मर्ज है तो लिंकिंग के लचीलेपन के कारण आसान हो जाएगा (कोई भी externपूर्व सूचना के बिना किसी भी कार्य को कॉल कर सकता है )। जावा या .NET के लिए आपको सहायक वर्गों और / या उपयोगिता घटकों को तैयार करने की आवश्यकता हो सकती है।

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


0

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

इसके लिए एक समाधान है और इसे जेनरिक कहा जाता है जिसे जावा 6 में पेश किया गया है। यह C ++ के समकक्ष है जिसे टेम्प्लेट कहा जाता है। जेनेरिक क्लास के भीतर सही कोड का अभी तक पता नहीं है। कृपया जावा जेनरिक की जांच करें और आपको इसके लिए टन और टन प्रलेखन मिलेगा।

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

सुनिश्चित करें कि जेनेरिक वर्ग की हर विधि का उपयोग किया जाता है। आप कोड कवरेज टूल भी पेश कर सकते हैं: जेनेरिक कोड पूरी तरह से कोड कवरेज होना चाहिए क्योंकि इसका उपयोग कई स्थानों पर किया जाएगा।

इसके अलावा टेस्टिंग कोड यानी जेयूनाइट का उपयोग करें या पहले नामित वर्ग के लिए समान है जो कोड के जेनेरिक टुकड़े के साथ संयोजन में उपयोग होने जा रहा है।

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

हाँ, यह एक थकाऊ काम है, लेकिन जैसे-जैसे आप आगे बढ़ेंगे, बेहतर होगा और बेहतर होगा कि आप समान कक्षाओं को चीर दें और इसे किसी ऐसी चीज़ से बदल दें जो बहुत साफ सुथरी, अच्छी तरह से लिखी जाए और बनाए रखने में बहुत आसान हो।

मेरी भी ऐसी ही स्थिति है जहां सामान्य वर्ग में अंततः 6 या 7 अन्य समान समान वर्गों को प्रतिस्थापित किया गया है जो लगभग सभी समान थे लेकिन समय-समय पर विभिन्न प्रोग्रामर द्वारा कॉपी और पेस्ट किए गए हैं।

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

आशा है कि यह मदद करेगा और सौभाग्य।


0

मैं वास्तव में यहाँ और साथ कम से कम लोकप्रिय राय को प्रतिध्वनित करने जा रहा हूं Gangnusऔर सुझाव देता हूं कि कोड दोहराव हमेशा हानिकारक नहीं होता है और कभी-कभी कम बुराई हो सकती है।

यदि कहें, तो आप मुझे उपयोग करने का विकल्प देते हैं:

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

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

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

लेकिन सोचने के लिए युग्मन और स्थिरता भी है, और यहां कुछ मामूली दोहराव है और एक डिकॉप्लिंग तंत्र के रूप में काम कर सकता है जो पैकेज की स्थिरता (अपरिवर्तनीय प्रकृति) को भी बढ़ाता है।

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


-2

यह मत भूलो कि कोड दोहराव हमेशा हानिकारक नहीं होता है। कल्पना करें: अब आपके पास अपनी परियोजना के बिल्कुल अलग मॉड्यूल में हल करने के लिए कुछ कार्य हैं। बस अब यह एक ही काम है।

इसके तीन कारण हो सकते हैं:

  1. इस कार्य के आसपास कुछ थीम दोनों मॉड्यूल के लिए समान है। इस मामले में कोड का दोहराव खराब है और इसे तरल किया जाना चाहिए। इस विषय का समर्थन करने और दोनों मॉड्यूल में इसके तरीकों का उपयोग करने के लिए एक वर्ग या एक मॉड्यूल बनाना चतुर होगा।

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

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

और यह तीसरा मामला अक्सर होता है। यदि आप "अनजाने" नकल करते हैं, तो ज्यादातर यह बहुत ही कारण के लिए है - यह एक वास्तविक दोहराव नहीं है!

इसलिए, इसे तब साफ रखने का प्रयास करें जब यह वास्तव में आवश्यक हो और नकल से डरे नहीं, यदि यह नहीं होना चाहिए।


2
code duplication is not always harmfulएक गरीब सलाह है।
ट्यूलेंस कोरडोवा

1
क्या मुझे आपके अधिकार के लिए झुकना चाहिए? मैंने अपने कारणों को यहां रखा था। अगर मैं गलत कर रहा हूं, तो दिखाओ कि गलती कहां है। अब बल्कि यह चर्चा को बनाए रखने की आपकी घटिया क्षमता के रूप में प्रतीत होता है।
गंगानुस

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

मैं है यहाँ तर्क डाल दिया। आपने नहीं किया अधिकारियों का संदर्भ 16 वीं सदी से काम नहीं करेगा। आप गारंटी नहीं दे सकते कि आपने उन्हें सही तरीके से समझा है और वे मेरे लिए भी अधिकारी हैं।
गंगनुस

आप सही हैं, कोड डुप्लिकेट सॉफ्टवेयर विकास में मुख्य समस्याओं में से एक नहीं है , और इससे बचने के लिए कोई प्रतिमान और कार्यप्रणाली विकसित नहीं की गई है।
तुलसी कोर्डोवा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.