कॉपी / पेस्ट-पैटर्न कैसे ठीक करें?


16

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

इसे रोकना आसान नहीं है, क्योंकि कोड आधार पूरी कंपनी के लिए खुला है। बहुत सारे लोग इस पर काम करते हैं।

अब जब कि गड़बड़ पहले से ही है, तो उन अतिरेक को दूर करने का सबसे अच्छा तरीका क्या है, बहुत ज्यादा टूटे बिना?


3
सबसे कष्टप्रद बात यह है कि जब कोड किसी साइट से कॉपी / पेस्ट हो जाता है और तब भी टिप्पणियाँ डिलीट नहीं होती हैं। तो आप पा सकते हैं: "// उस कार्लो के लिए धन्यवाद" ... और जब आप उन्हें इंगित करते हैं तो वे बस हंसते हैं और कहते हैं: "इसे छोड़ दो!))"। यह पेशेवर और दुख की बात नहीं है !!!
9

2
न केवल सलाहकार
एंडर्सके

जवाबों:


14

जवाब का एक हिस्सा रिफैक्टरिंग है

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

दूसरा हिस्सा शिक्षा है

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

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

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


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

@ शेरगिया तापिया - सच है, लेकिन आप इसके बिना रिफ्लेक्टर नहीं कर सकते। वास्तविकता में आपका स्वागत है, 2011 2011।
स्कॉट व्हिटलॉक

1
@ शेरगियो, अगर आपका मतलब है कि इकाई परीक्षण विरासत कोड कठिन है, तो मैं और अधिक सहमत नहीं हो सकता। मुझे उद्धृत वाक्य का विस्तार करते हुए खुशी हो रही है "पहले, आपको इकाई परीक्षणों को लिखने का कठिन और तनावपूर्ण कार्य शुरू करना चाहिए ..." :-) हालांकि, अगर आपका मतलब है कि चूंकि इकाई परीक्षण कठिन है, तो किसी को भी इसके बिना प्राप्त करने का प्रयास करना चाहिए। यह, मैं दृढ़ता से असहमत हूं (व्यावहारिक अनुभव पर आधारित है, सिद्धांत पर नहीं)। विरासत कोड को बनाए रखने के लिए कोई शाही सड़क नहीं है।
Péter Török

9

@Peter जैसी शिक्षा के हिस्से के रूप में, आप अपने कोडिंग मानकों के इस भाग को लागू करने में मदद करने के लिए PMD की तरह कॉपी और पेस्ट डिटेक्टर पेश कर सकते हैं और इसे अपने बिल्ड के हिस्से के रूप में उपयोग कर सकते हैं।

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


1
मुझे यह पसंद है, अच्छा है!
ozz

क्या किसी ठेकेदार के अनुबंध में एक कोडिंग मानक के पालन की आवश्यकता है?
आर्मंड

1
@ एलिसन आपको जो भी पसंद हो उसका पालन करने की आवश्यकता हो सकती है, जब तक आप सामने वाले को बता देते हैं कि आपको कोई समस्या नहीं होनी चाहिए। एक ठेकेदार के रूप में मैं जिन भी विकास की कंपनियों के काम करने की आवश्यकता का पालन करता हूं, उनमें से एक उनके सांकेतिक मानकों के अनुरूप है। ट्रंक को सबमिट करने से पहले कोड की समीक्षा करना भी इसे हल करने में मदद कर सकता है
DBlackborough

धन्यवाद, आपकी पोस्ट के बाद मुझे पायथन / जावा के लिए clonedigger.sourceforge.net भी मिला ।
LennyProgrammers

@ G3D समझ में आता है; क्या आपको काम करने के लिए एक कोडिंग मानक होना पसंद है? स्वीकृति के रूप में कोड समीक्षाओं के साथ मेरा मुद्दा यह है कि एक ठेकेदार के रूप में मुझे चिंता होगी कि कोड को मनमाने कारणों से खारिज किया जा सकता है (उदाहरण के लिए राजनीति, या बजट में परिवर्तन)
आर्मंड

8

लोग (सलाहकार) जितनी जल्दी हो सके सुविधाओं को जारी करने के लिए दबाव महसूस करते हैं

आपको कोई तकनीकी समस्या नहीं है, आपको एक सामाजिक समस्या है। दरअसल, आपको प्रबंधन की समस्या है।

इसे रोकना आसान नहीं है, क्योंकि कोड आधार पूरी कंपनी के लिए खुला है। बहुत सारे लोग इस पर काम करते हैं।

"कोड आधार पूरी कंपनी के लिए खुला है" एक गैर-मुद्दा है। कोई बात नहीं।

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

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

आपको करना होगा

  1. पुरस्कारों को सुदृढ़ करने वाले प्रबंधकों के साथ शीर्ष पर शुरू करें। आपको मौजूदा अभ्यास को उजागर करना होगा और लागतों और जोखिमों का दस्तावेजीकरण करना होगा। आपको एक विकल्प का प्रस्ताव करना होगा जो लागत और जोखिम को कम करता है।

  2. आपको उस संगठन में अपने बाकी कार्यकाल के लिए लागत और जोखिम को लगातार दस्तावेज़ करना और उजागर करना होगा। अनवरत। तथ्य आधारित। लागत और जोखिम। हर हफ्ते अधिक लागत और कॉपी-और-पेस्ट से अधिक जोखिम।

  3. आपको प्रबंधकों को नए दृष्टिकोण का श्रेय लेने में मदद करनी होगी, जिससे वे अच्छे दिखेंगे और आपको अनदेखा किया जाएगा।

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


1
+1 विशेष रूप से "आपको प्रबंधकों को नए दृष्टिकोण का श्रेय लेने में मदद करनी होगी जिससे वे अच्छे दिखेंगे और आपको नजरअंदाज कर दिया जाएगा।" बेहतर है कि सभी तैयार रहें अक्सर यह वास्तविकता है :-(
पेराटोक

@ Péter Török: बहुत से लोग इस पर ध्यान देते हैं। वे या तो कॉपी / पेस्ट के कारण होने वाली समस्याओं पर तथ्यों को एकत्र नहीं करते हैं या वे बार-बार प्रबंधन को मामला नहीं बनाते हैं।
S.Lott

मुझे पता है कि यहां एक गहरी, गैर-तकनीकी समस्या है। लेकिन यह एक समस्या है जो किसी को भी जल्द ही ठीक कर सकता है। यह एक थर्ड-पार्टी लाइब्रेरी में एक बग की तरह है जिसे आपको काम करने की आवश्यकता है।
LennProgrammers

@ Lenny222: आपकी टिप्पणी से कोई मतलब नहीं है। "यह एक समस्या दोपहर है जो परवाह करता है कभी भी जल्द ही ठीक कर सकता है" सवाल का स्पष्ट रूप है। इस टिप्पणी का क्या अर्थ है? उत्तर से क्या गायब है? आपको और क्या चाहिए?
S.Lott

यह एक सतत शिक्षा प्रक्रिया होगी।
जेएफओ 17

5

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

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

कुल समय बिताया: 4 घंटे। मैं जरूरत पड़ने पर 20 घंटे की मैराथन में जाने के लिए तैयार था और इस बात से आश्चर्यचकित था कि मैं कितनी तेजी से नियंत्रण में बढ़ती गड़बड़ लाया। एक बोनस के रूप में, हेडर निर्भरता के मुद्दों का एक गुच्छा ठीक करना आसान था। इसके अतिरिक्त, चूंकि हमारा बहुत सा मालिकाना सामान अब लिंक करने के लिए स्थिर वस्तुओं में है, इसलिए हम अपने ग्राहकों को दे सकते हैं, जो पहले की तुलना में स्रोत कोड तक पहुंच पाते हैं।

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

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


जिज्ञासु, क्या आपको कोई ऐसा मिला जो समान था?
17

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

5

मैं अब तक दिए गए जवाबों से सहमत हूं। तुम्हे करना चाहिए:

  • इकाई परीक्षण बनाएं
  • refactor
  • शिक्षित
  • मानकों को कोड करने और उल्लंघन का पता लगाने में प्रयास करें

लेकिन दूसरी तरफ आपको यह देखने की जरूरत है कि लोगों को पेस्ट कॉपी करने और इसे ठीक करने के क्या कारण हैं।

  • हो सकता है कि लोग एक अच्छे तरीके से कोड का पुन: उपयोग न कर सकें क्योंकि यह बहुत से युग्मित है
  • लोगों को पता नहीं हो सकता है कि एक पुस्तकालय है जिसका वे उपयोग कर सकते हैं
  • लाइब्रेरी कोड पर्याप्त सामान्य नहीं हो सकता है और अपने स्वयं के संस्करण को पकाना मौजूदा लाइब्रेरी का उपयोग करने की तुलना में आसान है
  • एक अच्छी वर्जनिंग (स्रोत नियंत्रण नहीं) रणनीति नहीं हो सकती है और जेनेरिक लाइब्रेरी को बदलने से कई अन्य अनुप्रयोगों का भी परीक्षण हो सकता है।

इसलिए मुझे लगता है कि कॉपी / पेस्ट पैटर्न को रोकने के लिए आपको पुन: उपयोग को आसान बनाने की आवश्यकता है।

  • पुस्तकालयों को खोजने योग्य और अच्छी तरह से प्रलेखित करें
  • पुस्तकालयों को हर चीज से स्वतंत्र करना
  • एक अच्छी संस्करण रणनीति के बारे में सोचें
  • संगतता सुनिश्चित करें
  • पुस्तकालयों की आसान विस्तारशीलता के बारे में सोचें

फ्रेमवर्क डिजाइन दिशानिर्देश पढ़ें

उम्मीद है की यह मदद करेगा।


3

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

यदि आप डेवलपर्स को "अधिक बुरा" नहीं बताने के लिए, उस अधिक बारीक रवैये का उपयोग करने के तरीके खोज सकते हैं, बल्कि "यह अधूरा है, तो क्या आप मेरे साथ काम कर सकते हैं रिफैक्टरिंग?"


2

मैं यहां एक ही समस्या से चिंतित हूं, और इस पर मेरा ध्यान है: इसे उल्टा न होने देने की कोशिश न करें, बस रिफ्लेक्टर जब यह बहुत खराब हो जाए।

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


2

जो भी प्रभारी है वह गलती पर है। एक व्यक्ति को कोड की प्रत्येक पंक्ति की समीक्षा करने की उम्मीद नहीं की जा सकती है, लेकिन वे मानक और समय सीमा निर्धारित करते हैं।

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

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


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

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

1

कॉपी / पेस्ट कोड को खत्म करने का एकमात्र तरीका (IMHO) कोड समीक्षाएं हैं, कोड के माध्यम से जांच करने के लिए एक व्यक्ति (या अधिमानतः अधिक) होता है और जब उन्हें ऐसा कोड मिलता है जो कॉपी / पेस्ट कार्रवाई से लगता है तो प्रोग्रामर को रिफ्लेक्टर दें।


1

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

@Anders K. समीक्षाएँ अभ्यास को बनाए रखने के लिए एक अच्छा साधन हैं। जब लोगों को कोड लिखने के लिए मजबूर किया जाता है तो वे यह नहीं मानते हैं कि इससे बहुत अधिक घर्षण पैदा होता है। वे कर सकते हैं के रूप में जल्द ही पुराने खरगोश में वापस गिर जाएगी। मेरा दृढ़ विश्वास है कि आपको शिक्षा के साथ शुरुआत करनी चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.