refactoring आप खुद को काम करने वाले-भयानक कोड को पुनः सक्रिय करने से कैसे रोकते हैं?




code-smell (24)

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

यदि आप इस "दुःख" से पीड़ित हैं, तो आप खुद को कैसे रोकते हैं? या कम से कम लंबे समय तक इसे बनाए रखने के लिए मौजूदा कोड के बड़े हिस्से को बदलने से बचने के लिए कम से कम रिफैक्टरिंग का प्रबंधन करें।


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

तब तक, मैं टिप्पणियों में बदलाव के लिए विचारों को ध्यान में रखूंगा।


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


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


मैं आमतौर पर खुद को रोक नहीं पाता हूं। अगर मुझे उस कोड में एक बुरा टुकड़ा मिल रहा है जिस पर मैं काम कर रहा हूं, तो मैं इसे सीधे सही करता हूं।

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

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


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

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

तो, आमतौर पर आपको कहीं रेखा खींचनी होती है; रिफैक्टर केवल कोड जो सीधे काम पर चिंतित है, और केवल तभी जब यह एक समान समय नहीं लेगा

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

यदि आप वाणिज्यिक सॉफ्टवेयर विकास की किसी भी बाधा से मुक्त हैं, तो आपका लाभ भिन्न हो सकता है। ;)

वैसे, अच्छा सवाल - मैं भी खुद को लाइन को आकर्षित करने के बारे में सोच रहा हूं।


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


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

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

जब तक आप पुराने कोड का तर्क रखते हैं, तब भी इसे काम करना चाहिए, साथ ही कुल मिलाकर बेहतर कोड होने का अतिरिक्त बोनस भी होना चाहिए।

मैं हमेशा इसे छोड़ने से बेहतर कोड छोड़ने की कोशिश करता हूं।


मार्टिन फाउलर इस मुद्दे पर लेते हैं:

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

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

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


मैं टुकड़े टुकड़े के आधार पर रिफैक्टर करने की कोशिश करता हूं। यही है, जब मुझे नई कार्यक्षमता जोड़ने की ज़रूरत है, तो मैं इसे इस तरह से दोबारा प्रतिक्रिया देता हूं जिससे पहले उस कार्यक्षमता को जोड़ना आसान हो जाता है। यह धीमी प्रक्रिया को दोबारा सुधारता है, लेकिन यह बदलावों को जोड़ने में आसान समय बनाता है।


यह वास्तव में आसान है।

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

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

सवाल का जवाब "जोड़ा मूल्य क्या है?" भी मदद करता है।


देखभाल करना बंद करो।

मेरा मतलब है, कॉमन, हम सभी इंजीनियरों यहाँ हैं, और इंजीनियरों को बस सबसे अजीब आदर्श कोड बाहर रखना पसंद है। और हम कोशिश करते रहेंगे। और हम अपने काम के बारे में खुश नहीं होने जा रहे हैं, जब तक हम नहीं जानते कि हमने जो कुछ भी छुआ है वह टीएमएपीसीई है। इसके अलावा, हम सिर्फ इतना जानते हैं कि इस तरह से बहुत बेहतर है ...

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


मैं प्राथमिकता देता हूं।

जब मेरे पास कुछ चक्र उपलब्ध होते हैं (हेक्टेयर)

मैं आमतौर पर कोड को फिर से कारक करने की कोशिश करता हूं कि:

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

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

कुछ भी छूने के कारण हम छूने की तरह महसूस करते हैं?

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

"मौजूदा कोड को रिफैक्टर करना जो काम करता है" - यह स्पष्ट रूप से अल्पसंख्यक राय है, लेकिन यह समय की पूरी बर्बादी है। यह अच्छा है कि आप खुद को रोकने का प्रयास कर रहे हैं।

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

यह रवैया कि कामकाजी कोड को दोबारा करने के बाद "मैंने कोड को बेहतर छोड़ दिया है" अक्सर प्रोग्रामर हब्रिस होता है । कई मामलों में आप वास्तव में नहीं जानते कि आपने कोड को बेहतर छोड़ दिया है, आप बस मानते हैं कि आपने किया था। यदि आपने कोई बग ठीक नहीं किया है या कार्यक्षमता जोड़ें तो गलत होने का जोखिम क्यों लें?


जब भी मैं कुछ पसंद नहीं आया, लेकिन अब और नहीं, मैं कोड को दोबारा इस्तेमाल करता था। मुझे अनुभव से पता चला कि यह सिर्फ इसके लायक नहीं है। बेहतर चीजें हैं जिन पर आप अपना समय व्यतीत कर सकते हैं।

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

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

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



मैं नहीं कहूंगा कि मैं इस दुःख से पीड़ित हूं लेकिन ... मैं तुम्हें भाई सुनता हूं!

मुझे लगता है कि जब हमने इसे छोड़ा था, तब हमें कोड को बेहतर स्थिति में छोड़ने की जरूरत है। तो आपका पीछा महान है। आइए इसे 'रेफैक्टोरिटिस' कहते हैं।

मुझे लगता है कि हम सभी रिफैक्टरिंग के लाभों पर सहमत हैं और यह इस तरह के कोड पर निर्भर करता है कि यह कितना आवश्यक है ... प्रश्न के क्रूक्स के लिए ...

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

दिलचस्प सवाल के लिए धन्यवाद। यह मुझे आश्चर्यचकित करता है कि हमें 'रेफैक्टरर्स बेनामी' समूह की आवश्यकता है, जहां हम एक सर्कल में बैठ सकते हैं और हमारी समस्याओं और युद्ध कहानियों को साझा कर सकते हैं।


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

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

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

यदि आप उनमें से किसी एक को हाँ का उत्तर देते हैं तो यह रिफैक्टर करने का समय हो सकता है।


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

अभी भी एक लागत / लाभ किया जा सकता है, लेकिन सिद्धांत रूप में मैं लॉन्गहोर्न से सहमत हूं कि आपको खुद को रोकना नहीं चाहिए।


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


मेरे लिए क्या काम किया गया था इसके लिए नौकरी से निकाल दिया गया था। : \

उस ने कहा, मेरी मूल समस्या दो गुना थी:

  1. मैं कोड को दोबारा कर रहा था कि किसी ने मुझे काम करने के लिए कहा नहीं था।

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

मैंने जो सीखा वह था:

  1. उस कोड पर काम न करें जिस पर आपको काम करने की आवश्यकता नहीं है, और कोई भी आपको काम करने के लिए नहीं कहता है। अतीत में परिणामों को देखते हुए, अब इसे याद रखना आसान है।

  2. जब आपको कोड को दोबारा करने की आवश्यकता होती है तो आपको काम करना चाहिए, परीक्षण में जगहें हैं, लेकिन उन्हें स्वचालित होने की आवश्यकता नहीं है।

बहुत अधिक टीडीडी सामान पढ़ने के बाद, मैंने स्वचालित परीक्षणों के बारे में सोचने का प्रयास किया क्योंकि एकमात्र प्रकार का परीक्षण है। हकीकत में, Debug.Print स्टेटमेंट का भी एक गुच्छा यह पता लगाने के लिए एक सभ्य परीक्षण हो सकता है कि कार्यक्षमता लगातार रह रही है या नहीं।

अगर आपको रिफैक्टर करना है, और आप स्वचालित परीक्षण नहीं कर सकते हैं, तो आपको किसी प्रकार का परीक्षण करना होगा, चाहे वह प्रिंटिंग टेक्स्ट हो या यूआई स्क्रिप्ट, या जो भी हो। किसी भी परीक्षण से कोई भी प्रभावी परीक्षण बेहतर नहीं है।


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

मैं Doxygen का एक बड़ा प्रशंसक हूं, जो मुझे एक साधारण छड़ी करने की अनुमति देता है:

/**
 * Function to rule the world
 * @todo make this actually work
 */

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

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

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

आपके द्वारा सभी कोडों के लिए उपयोग किए जाने के बाद और चीजों को और अधिक सुसंगत बनाने के बारे में कुछ विचार दिया है .. फिर अंदर गोता लगाएँ। अन्यथा, आप अपने पिछले पुन: फैक्टरिंग को फिर से फैक्टरिंग कर देंगे (क्या एक दुष्चक्र है जो वर्षों में लिया गया उपयुक्त बनने के लिये!)।

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


मैंने अतीत में इसका सामना किया है, और मैं अपनी 'बुरी' अच्छी आदत को कम करता हूं।

असल में, मैं निम्नलिखित करता हूं:

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

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

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

वैसे भी। आप की देखभाल करने से अधिक मस्तिष्क डंप हो सकता है, लेकिन उम्मीद है कि यह मदद करता है।


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


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

इसके अलावा, एक बहुत ही वास्तविक जोखिम है, आप विरासत गड़बड़ी में तय की गई बग पेश करेंगे। इससे आपको गैर-व्यावसायिक दिखाई देगा।

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

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

आम तौर पर आपके पास दो मुद्दे होंगे: समय की पूरी कमी, और रिफैक्टर को आवंटित करने के खिलाफ प्रबंधन को धक्का देना। यदि उनमें से कोई भी मुद्दा नहीं है, तो अपने आप को बहुत भाग्यशाली मानें।

संपादित करें: जोएल स्पॉस्की का सबसे अच्छा जवाब है , मुझे विश्वास है।