2.19 रीफ़ैक्टरिंग और तकनीकी ऋण

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

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

सिफ़ारिशें

रीफ़ैक्टरिंग और व्यवहार परिवर्तन को सख़्ती से अलग रखें

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

पुनर्गठन से पहले एक भरोसेमंद सुरक्षा जाल स्थापित करें

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

कोड स्मेल्स को पहचानना सीखें और छोटी नामित रीफ़ैक्टरिंग लागू करें

एक कोड स्मेल एक सतही संकेत है कि नीचे कुछ ध्यान माँग रहा हो सकता है: एक फ़ंक्शन जो बहुत लंबा हो गया है, एक क्लास जो बहुत कुछ जानती है, दोहराया गया लॉजिक, एक लंबी पैरामीटर सूची, ऐसे नाम जो अपने काम के बारे में झूठ बोलते हैं। एक स्मेल एक संकेत है, फ़ैसला नहीं, इसलिए आप उसे अंधाधुंध मानने के बजाय जाँच करते हैं। प्रतिक्रिया होती है Fowler के कैटलॉग से एक छोटी, नामित रीफ़ैक्टरिंग: Extract Function, Rename Variable, Move Method, Replace Conditional with Polymorphism, और दर्जनों और। नामित चालों का उपयोग करने का मूल्य यह है कि हर एक छोटी, समझी हुई, यांत्रिक रूप से सुरक्षित होती है और अक्सर सीधे आपके IDE द्वारा समर्थित होती है। आप बड़े सुधारों को कई छोटे भरोसेमंद चरणों से बनाते हैं, पूरे समय कोड को हरा (green) रखते हुए, न कि ऐसी एक बड़ी छलांग लगाते हुए जिसे आप सत्यापित नहीं कर सकते।

अवसरवादी रीफ़ैक्टरिंग को प्राथमिकता दें, और वास्तविक संरचनात्मक आवश्यकता के लिए अभियान सुरक्षित रखें

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

बड़े संरचनात्मक परिवर्तन के लिए स्ट्रैंगलर फ़िग पैटर्न का उपयोग करें

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

तकनीकी ऋण को एक पोर्टफोलियो के रूप में लें, और इसे दृश्यमान बनाएँ

Ward Cunningham द्वारा गढ़ा गया ऋण रूपक दो चीज़ों को अलग करता है: मूलधन (गन्दा कोड या शॉर्टकट स्वयं) और ब्याज (जो अतिरिक्त प्रयास हर भविष्य के परिवर्तन को इसके कारण चुकाना पड़ता है)। सारा ऋण बराबर नहीं होता। Fowler का चतुर्भुज इसे दो अक्षों के अनुसार क्रमबद्ध करता है: जानबूझकर बनाम अनजाने में, और विवेकपूर्ण बनाम लापरवाह। विवेकपूर्ण-जानबूझकर ऋण (“हम अभी शिप करते हैं और अगले स्प्रिंट में सफ़ाई करते हैं, और हम इसकी कीमत जानते हैं”) एक वैध व्यावसायिक निर्णय है। लापरवाह-अनजाना ऋण (“डिज़ाइन पैटर्न क्या है?“) केवल नुकसान है। प्रबंधन का काम, जो निर्णय-निर्माण और गवर्नेंस (अध्याय 1.5) और ऋण को एक पोर्टफोलियो के रूप में लेने के उसके दृष्टिकोण से जुड़ता है, ऋण को दृश्यमान बनाना है ताकि उस पर तर्क किया जा सके: जहाँ काम रहता है वहाँ महत्वपूर्ण मदों को ट्रैक करें, कोड को टैग करें, और जो ब्याज आप चुका रहे हैं उसे दर्ज करें ताकि पुनर्भुगतान प्रमाण के आधार पर क्षमता के लिए प्रतिस्पर्धा करे, न कि इस आधार पर कि कौन सबसे ज़ोर से शिकायत करता है। जो ऋण आप नहीं देख सकते, उसे आप प्रबंधित नहीं कर सकते।

पुनर्भुगतान को स्थिर क्षमता के रूप में फंड करें, वीरतापूर्ण प्रयासों के रूप में नहीं

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

आंतरिक गुणवत्ता को मापें, लेकिन माप को लक्ष्य न बनने दें

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

जानें कब रीफ़ैक्टर नहीं करना है

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

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

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

अपनी टीम के साथ चर्चा करने योग्य प्रश्न

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

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

3. हमारे कोडबेस के किन हिस्सों को हमें जानबूझकर रीफ़ैक्टर नहीं करना चाहिए, और हमें यह कैसे पता चलेगा? सब कुछ रीफ़ैक्टर करना उतनी ही बड़ी विफलता है जितना कुछ भी रीफ़ैक्टर न करना, क्योंकि स्थिर, कम-छुए जाने वाले, या जल्द रिटायर होने वाले कोड को साफ़ करने में खर्च किया गया प्रयास ऐसे ऋण पर चुकाया गया ब्याज है जो आपने लिया ही नहीं था। निर्णय वास्तविक है: कोई मॉड्यूल भद्दा दिख सकता है और फिर भी निवेश के लिए गलत जगह हो सकता है यदि उसे कोई कभी बदलता ही नहीं। अपने परिवर्तन-आवृत्ति डेटा को अपने जटिलता संकेतों के साथ लाएँ, क्योंकि उच्च चर्न और उच्च जटिलता का प्रतिच्छेदन वह जगह है जहाँ सफ़ाई बढ़ती जाती है, जबकि कम-चर्न कोड को आमतौर पर अकेला छोड़ना ही सबसे अच्छा होता है। प्रतिस्पर्धी जोखिम यह है कि “हम इसे छोड़ देंगे” किसी भी कठिन चीज़ को कभी न छूने का बहाना बन जाता है। उत्तर आपको निवेश के लायक हॉटस्पॉट की एक स्पष्ट शॉर्टलिस्ट और शांत कोनों को नज़रअंदाज़ करने की अनुमति देनी चाहिए।

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

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

6. हम आंतरिक-गुणवत्ता मेट्रिक्स का उपयोग यह पता लगाने के लिए कैसे करें कि ऋण कहाँ केंद्रित है, बिना किसी संख्या को ऐसा लक्ष्य बनने दिए जिसे लोग हेरफेर करें? जटिलता, डुप्लिकेशन, कवरेज, और परिवर्तन-विफलता दर जैसे मेट्रिक्स ही किसी बड़े संगठन के लिए ऐसे कोड में देखने का एकमात्र तरीका हैं जिसे कोई एक व्यक्ति नहीं पढ़ता, फिर भी जिस क्षण किसी एक को किसी गेट या परफ़ॉर्मेंस रिव्यू से जोड़ा जाता है, Goodhart का नियम हावी हो जाता है और वह संख्या कुछ भी वास्तविक मापना बंद कर देती है। उदाहरण लाएँ जहाँ कोई मेट्रिक पहले से ही व्यवहार को चला रहा है, और पूछें कि क्या यह बातचीत शुरू कर रहा है या चुपचाप ऐसे टेस्टों को पुरस्कृत कर रहा है जो कुछ भी दावा नहीं करते और ऐसे लॉजिक को जो किसी सीमा से बचने के लिए फ़ंक्शनों में फैला दिया गया है। प्रतिस्पर्धी खिंचाव यह है कि नेतृत्व एक सरल डैशबोर्ड संख्या चाहता है, और “निर्णय का उपयोग करें” एक हरी पट्टी की तुलना में बेचना कठिन है। एंटरप्राइज़ और सरकारी संदर्भों में जहाँ मेट्रिक्स गवर्नेंस रिपोर्टिंग को फ़ीड करते हैं, स्पष्ट रहें कि गुणवत्ता संकेत निवेश को सूचित करते हैं और हॉटस्पॉट खोजते हैं लेकिन कभी व्यक्तियों को गेट नहीं करते; उत्तर को सीखने के लिए मापने और आँकने के लिए मापने के बीच एक स्पष्ट रेखा खींचनी चाहिए।

क्षेत्र-विशेष दृष्टिकोण

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

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

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

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

उदाहरण

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

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

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

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

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

• स्तर 1, आरंभ (Initiate): रीफ़ैक्टरिंग तदर्थ और प्रतिक्रियाशील है, अक्सर उसी कमिट में व्यवहार परिवर्तन के साथ मिश्रित। कोई भरोसेमंद सुरक्षा जाल नहीं है, तकनीकी ऋण अदृश्य और अनट्रैक्ड है, और सफ़ाई केवल कभी-कभार वीरतापूर्ण उभार में होती है या बिल्कुल नहीं होती।
• स्तर 2, विकास (Develop): कुछ टीमें रीफ़ैक्टरिंग को व्यवहार परिवर्तन से अलग करती हैं और जहाँ टेस्ट मौजूद हैं वहाँ उन पर टिकती हैं, और नामित रीफ़ैक्टरिंग तथा कैरेक्टराइज़ेशन टेस्ट कुछ जगहों पर दिखते हैं। प्रथा टीमों में असंगत है, ऋण पर चर्चा होती है और कभी-कभी लॉग किया जाता है, और पुनर्भुगतान तदर्थ रूप से फ़ीचरों के विरुद्ध प्रतिस्पर्धा करता है और आमतौर पर हार जाता है।
• स्तर 3, मानकीकरण (Standardize): टू-हैट अनुशासन, लेगेसी कोड के लिए कैरेक्टराइज़ेशन टेस्ट, और छोटी नामित रीफ़ैक्टरिंग पूरे संगठन में दस्तावेज़ीकृत और अपेक्षित हैं। ऋण एक साझा रजिस्टर में ट्रैक किया जाता है जो मूलधन को ब्याज से अलग करता है, और पुनर्भुगतान के लिए एक संरक्षित क्षमता हर चक्र में योजनाबद्ध और समीक्षा में लागू की जाती है।
• स्तर 4, प्रबंधन (Manage): ऋण और सफ़ाई को बेसलाइनों के विरुद्ध डेटा से मापा और नियंत्रित किया जाता है। आप हॉटस्पॉट खोजने के लिए परिवर्तन-आवृत्ति और जटिलता ट्रैक करते हैं, रीफ़ैक्टर किए गए क्षेत्रों में परिवर्तन-विफलता दर और परिवर्तन लीड टाइम देखते हैं, और हर महत्वपूर्ण मद जो ब्याज लगाती है उसे दर्ज करते हैं, ताकि पुनर्भुगतान निर्णय प्रमाण पर टिके हों और मार-या-निवेश के फ़ैसले शिकायत की मात्रा के बजाय रुझानों पर आधारित हों। गुणवत्ता संकेत ऐसे गेटों से जोड़े बिना निवेश को सूचित करते हैं जिन्हें लोग हेरफेर कर सकें।
• स्तर 5, संचालन (Orchestrate): ऋण को पूरे संगठन में उत्पाद और रखरखाव योजना के साथ एकीकृत एक निरंतर पुनर्संतुलित पोर्टफोलियो के रूप में प्रबंधित किया जाता है। संरचनात्मक परिवर्तन नियमित रूप से टीमों में समन्वित स्ट्रैंगलर फ़िग और ब्रांच बाय एब्स्ट्रैक्शन का उपयोग करता है, पुनर्भुगतान निरंतर है और जहाँ परिवर्तन बार-बार और पीड़ादायक है वहाँ के अनुरूप है, और जैसे-जैसे सिस्टम और उसकी जोखिम तस्वीर बदलती है, प्रथा भी ढलती जाती है, ताकि दीर्घजीवी कोड दशकों तक बदलने-योग्य बना रहे।

चर्चा के लिए विचार

1. रीफ़ैक्टरिंग को व्यवहार परिवर्तन से अलग रखने के लिए आपकी टीम का वास्तविक, लागू किया गया नियम क्या है, और यह समय-सीमा के दबाव में कहाँ टूट जाता है?
2. आप प्रमाण के साथ कैसे तय करते हैं कि कौन-सा कोड सफ़ाई के लायक है और कौन-सा अकेला छोड़ना सबसे अच्छा है?
3. कहाँ कैरेक्टराइज़ेशन टेस्ट आपको किसी लेगेसी क्षेत्र को सुरक्षित रूप से रीफ़ैक्टर करने देंगे जिससे आप अभी बचते हैं?
4. अपने अगले बड़े आधुनिकीकरण के लिए, एक स्ट्रैंगलर फ़िग दृष्टिकोण कैसा दिखेगा, और आप पहले कौन-सा फ़साड या एब्स्ट्रैक्शन पेश करेंगे?
5. तकनीकी-ऋण रजिस्टर का स्वामी कौन है, और पुनर्भुगतान वास्तव में फ़ीचर काम के विरुद्ध क्षमता कैसे जीतता है?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• Martin Fowler, Refactoring: Improving the Design of Existing Code, second edition
• Michael Feathers, Working Effectively with Legacy Code
• Ward Cunningham, The WyCash Portfolio Management System (OOPSLA 1992 अनुभव रिपोर्ट, ऋण रूपक का मूल)
• Martin Fowler, “TechnicalDebtQuadrant” and “StranglerFigApplication” (martinfowler.com)
• Kent Beck, Tidy First? A Personal Exercise in Empirical Software Design
• Steve McConnell, Code Complete: A Practical Handbook of Software Construction
• Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship