लाभ:
- एक परीक्षण सुरक्षा जाल स्थापित करने की क्षमता जो रीफैक्टरिंग से पहले वर्तमान व्यवहार को पकड़ लेती है
- एआई से छोटे, एक-चरणीय, व्यवहार-संरक्षण परिवर्तनों के लिए पूछने और प्रत्येक चरण को मान्य करने की क्षमता
- व्यावसायिक संदर्भ में तकनीकी ऋण को पहचानने और प्राथमिकता देने की क्षमता
रीफैक्टरिंग किसी कोड के बाहरी व्यवहार को बदले बिना उसकी आंतरिक संरचना में सुधार कर रही है: इसे अधिक पठनीय, सरल, अधिक रखरखाव योग्य बनाना। दूसरी ओर, तकनीकी ऋण एक डिज़ाइन समझौता है जो त्वरित समाधान के लिए किया जाता है और समय के साथ "ब्याज के साथ" वापस भुगतान किया जाता है - आज आप जो भी कोना काटते हैं वह कल मंदी या बग के रूप में वापस आ जाएगा। कृत्रिम बुद्धिमत्ता एक शक्तिशाली सहायक है जो दोहराए जाने वाले और यांत्रिक रीफैक्टरिंग कार्यों को गति देती है; लेकिन रीफैक्टरिंग का एक सुनहरा नियम है, और अकेले एआई इसकी गारंटी नहीं दे सकता: व्यवहार नहीं बदलना चाहिए।
इस इकाई में, हम सीखते हैं कि एआई के साथ सुरक्षित रीफैक्टरिंग कैसे करें: छोटे और प्रतिवर्ती कदम, परीक्षणों से सुरक्षा, कोड गंध का पता लगाना और तकनीकी ऋण को प्राथमिकता देना। महत्वपूर्ण बिंदु यह है: यह उत्तीर्ण परीक्षण है, न कि एआई का शब्द, जो साबित करता है कि व्यवहार संरक्षित है।
रिफैक्टरिंग का स्वर्णिम नियम: व्यवहार स्थिर रहता है
जो चीज़ रिफैक्टरिंग को खतरनाक बनाती है वह है "मैं सुधार कर रहा हूँ" कहते समय अनजाने में व्यवहार बदलना। किसी शर्त को सरल बनाते समय एज केस को हटाना, लूप को रूपांतरित करते समय ऑर्डर को तोड़ना, किसी फ़ंक्शन को विभाजित करते समय साइड इफेक्ट गायब होना - ये सभी "साफ-सुथरा दिखने वाला" लेकिन टूटा हुआ कोड उत्पन्न करते हैं।
इसीलिए रीफैक्टरिंग के लिए परीक्षण एक शर्त है: बदलने से पहले, आपके पास ऐसे परीक्षण होने चाहिए जो मौजूदा व्यवहार को पकड़ें। ये परीक्षण एक "सुरक्षा जाल" हैं; यदि आप रीफैक्टरिंग के दौरान गलती से कुछ तोड़ देते हैं, तो वे उसे तोड़ देंगे और आपको चेतावनी देंगे। यदि आपके पास परीक्षण नहीं हैं, तो पहले मौजूदा व्यवहार को ठीक करने वाले परीक्षण लिखें (जैसा कि हमने इकाई 5 में सीखा) - यहीं से एआई को एक नई शुरुआत मिलती है।
सावधानी: टेस्टनेट के बिना एआई-सहायता प्राप्त रिफैक्टरिंग बग के सबसे घातक स्रोतों में से एक है। यह कहना आसान है "मैंने व्यवहार बरकरार रखा"; इसका प्रमाण यह है कि परिवर्तन से पहले और बाद में भी वही परीक्षण पास होते हैं।
चरण दर चरण: सुरक्षित रिफैक्टरिंग प्रवाह
- सुरक्षा जाल स्थापित करें. ऐसे परीक्षण होने दें जो आपके द्वारा रिफैक्टर किए जाने वाले कोड के वर्तमान व्यवहार को पकड़ सकें; यदि नहीं, तो पहले उन्हें लिख लें (और उन्हें पूरा होते हुए देखें)।
- गंध का नाम बताएं. आप क्या सुधार कर रहे हैं और क्यों? "यह फ़ंक्शन 3 काम करता है", "एक ही तर्क 4 स्थानों पर दोहराया जाता है", "नाम भ्रामक हैं"।
- छोटे, एक-कदम वाले कदमों के लिए पूछें। एआई से एकल परिवर्तन के लिए कहें (उदाहरण के लिए बस "इस फ़ंक्शन को आधे में विभाजित करें"), पूरी फ़ाइल को फिर से लिखने के लिए नहीं।
- परीक्षण चलाएँ. हर कदम के बाद. यदि यह हरा है, तो जारी रखें, यदि यह लाल है, तो इसे वापस ले लें।
- अंतर पढ़ें. पंक्ति दर पंक्ति पुष्टि करें कि परिवर्तन वास्तव में व्यवहार-संरक्षण है; जब यह कहा जाता है कि एआई "केवल संरचना" है, तो तर्क में त्रुटि हो सकती है।
- छोटे-छोटे टुकड़ों में मिला लें. बड़े एक बार के रिफैक्टरिंग पीआर जोखिम भरे और अप्राप्य दोनों हैं।
तीन मिनी मामले
केस 1 - 220-लाइन फ़ंक्शन सुरक्षित रूप से विभाजित। एक टीम के पास 220-लाइन ऑर्डर प्रोसेसिंग फ़ंक्शन था। पहले 14 परीक्षण लिखे गए (एआई की मदद से) जिन्होंने वर्तमान व्यवहार को पकड़ लिया, वे सभी उत्तीर्ण हुए। फिर फ़ंक्शन को एआई द्वारा चरण दर चरण 5 छोटे फ़ंक्शन में विभाजित किया गया; प्रत्येक चरण के बाद परीक्षण चलाए गए। एक चरण में दो परीक्षण विफल हो गए - एआई एक किनारे के मामले में वापसी से चूक गया था। परीक्षणों ने इसे तुरंत पकड़ लिया और इसे ठीक कर दिया। नेटवर्क के बिना, त्रुटि उत्पादन तक पहुंच सकती थी।
केस 2 - टेस्टनेट के बिना आपदा। एक अन्य डेवलपर ने दिनांक गणना मॉड्यूल को "साफ" कर दिया जिसमें एआई के साथ कोई परीक्षण नहीं था। कोड बेहतर दिख रहा था, लेकिन यह लीप वर्ष की गलत गणना कर रहा था; दो सप्ताह बाद ग्राहक की शिकायत के साथ बग सामने आया। नुकसान रिफैक्टरिंग से बचाए गए समय से कहीं अधिक था। पाठ: परीक्षण के बिना रिफैक्टरिंग एक जुआ है।
केस 3 - तकनीकी ऋण प्राथमिकता। एक टीम ने एआई को 30 या उससे अधिक "सुधार योग्य" अंकों का बैकलॉग दिया और प्रत्येक को "परिवर्तन आवृत्ति × जोखिम × प्रयास" अक्ष पर स्कोर किया। परिणामी तालिका में, एक बदसूरत मॉड्यूल जिसे शायद ही कभी छुआ गया था वह वास्तव में कम प्राथमिकता थी, जबकि एक मध्यम-जटिलता मॉड्यूल जो अक्सर बदलता था वह उच्च प्राथमिकता थी। टीम ने अपनी ऊर्जा को सही जगह पर लगाया।
चार प्रतिलिपि योग्य टेम्पलेट
कोड गंध का पता लगाना और प्राथमिकता देना:
इस कोड में रीफैक्टरिंग उम्मीदवार की सूची "बदबू" है: लंबा कार्य, दोहराव (DRYViolation), भ्रामक नाम, गहरी नेस्टेड स्थिति, छिपा हुआ दुष्प्रभाव, जादुई संख्या। प्रत्येक के लिए: स्थान, समस्या क्यों, सुझाया गया छोटा कदम, अनुमानित जोखिम (कम/मध्यम/उच्च)। अभी कोड न बदलें, बस योजना बनाएं।
एक-कदम, व्यवहार-संरक्षण परिवर्तन:
बस यह करें: {{एकल रूपांतरण, उदा. इस फ़ंक्शन को 3 छोटे नामित फ़ंक्शंस में विभाजित करें}}। दृश्यमान व्यवहार, हस्ताक्षर और वापसी मान बदलें। 1 वाक्य में लिखें कि आपने जो कुछ भी बदला वह व्यवहार को बरकरार क्यों रखता है।
रिफैक्टर से पहले सुरक्षा जाल (लक्षणीकरण परीक्षण):
ऐसे परीक्षण लिखें जो इस फ़ंक्शन के वर्तमान व्यवहार को पकड़ते हैं (सही या नहीं); लक्ष्य यह पकड़ना है कि रीफैक्टरिंग के दौरान व्यवहार बदलता है या नहीं। विशिष्ट + बढ़त प्रविष्टियाँ शामिल करें। फ़ंक्शन के वर्तमान आउटपुट के आधार पर अपेक्षाएँ लिखें।{{फ़ंक्शन}}
तकनीकी ऋण रिकॉर्ड (बैकलॉग) निर्माण:
गंधों की निम्नलिखित सूची को प्राथमिकता तालिका में डालें: पदार्थ, प्रभावित क्षेत्र, परिवर्तन की आवृत्ति (मेरी जानकारी: {{...}}), जोखिम, अनुमानित प्रयास, अनुशंसित प्राथमिकता। उच्च प्रभाव + कम प्रयास वाले को शीर्ष पर रखें। {{गंध_सूची}}
कमजोर संकेत/मजबूत संकेत
कमज़ोर: "इस कोड को साफ़ करें और इसे बेहतर बनाएं।"
मजबूत: "इस 90-पंक्ति फ़ंक्शन को इसके बाहरी व्यवहार और हस्ताक्षर को बदले बिना, एकल जिम्मेदारी के साथ 3 छोटे कार्यों में विभाजित करें। साइड इफेक्ट्स (डीबी लिखता है) को वर्तमान क्रम में रखें। मेरे पास परीक्षण हैं, व्यवहार वही रहना चाहिए। अंतर दें और एक वाक्य में समझाएं कि प्रत्येक विभाजन व्यवहार-संरक्षण क्यों है। [कोड]"
शक्तिशाली संस्करण; इसके लिए एक विशिष्ट परिवर्तन की आवश्यकता होती है, स्पष्ट रूप से एक व्यवहार और हस्ताक्षर बाधा लागू होती है, और औचित्य की मांग होती है। "बेहतर करो" जैसे अस्पष्ट अनुरोध अनियंत्रित और जोखिम भरे परिवर्तनों को जन्म देते हैं।
रिफैक्टरिंग प्रकार
एआई विश्वसनीयता
पूर्वावश्यकता
नाम बदलें
उच्च
क्या दायरा सही है?
कार्य प्रभाग
मध्यम-उच्च
टेस्टनेट जरूरी है
दोहराव साझा करना
मध्यम
व्यवहार में अंतर छिपा हो सकता है
एल्गोरिथम/संरचना परिवर्तन
कम
व्यापक परीक्षण + मानव सत्यापन
स्थापत्य पुनर्व्यवस्था
कम
मानव-नेतृत्व वाला, AI-समर्थित
तकनीकी ऋण का प्रबंधन करना, उसे रीसेट करना नहीं
तकनीकी ऋण बिल्कुल बुरा नहीं है; कभी-कभी सोच-समझकर उधार लेना (डिलीवरी पूरा करने के लिए) सही निर्णय होता है। लक्ष्य कर्ज ख़त्म करना नहीं है, बल्कि इसे दृश्यमान और प्रबंधनीय बनाना है। एआई ऋण का पता लगाने और प्राथमिकता देने में तेज़ है, लेकिन "कौन सा ऋण चुकाया जाना चाहिए और कौन सा छोड़ दिया जाना चाहिए" का निर्णय लेने के लिए व्यावसायिक संदर्भ की आवश्यकता होती है: यह मॉड्यूल कितनी बार बदलता है, यह कितने लोगों को प्रभावित करता है, जोखिम क्या है? यह निर्णय उस टीम द्वारा किया जाता है जो कोड आधार और उत्पाद को जानती है; एआई सिर्फ विकल्पों को स्पष्ट करता है।
युक्ति: अपने रिफैक्टरिंग पीआर को उन पीआर से अलग रखें जिनमें व्यवहार परिवर्तन शामिल है। यह कहने में सक्षम होने से कि "यह पीआर सिर्फ एक रिफैक्टरिंग है, व्यवहार वही है" जांच करना आसान बनाता है और यदि कोई समस्या उत्पन्न होती है तो आप तुरंत कारण को कम कर सकते हैं।
सामान्य गलतियाँ
- टेस्टनेट के बिना रिफैक्टरिंग। आपके पास यह साबित करने के लिए कुछ भी नहीं बचा है कि व्यवहार संरक्षित है।
- इसका अर्थ है "संपूर्ण फ़ाइल साफ़ करें"। बड़े, अनियंत्रित परिवर्तन त्रुटि को छुपाते हैं और उनकी जांच नहीं की जा सकती।
- डिफ को बिना पढ़े स्वीकार करना। जब एआई ने "सिर्फ संरचना" कहा तो हो सकता है कि उसने कुछ तर्क खो दिए हों।
- व्यवहार परिवर्तन के साथ भ्रामक रिफैक्टरिंग। दोनों को एक ही पीआर में करने से मूल कारण का पता लगाना असंभव हो जाता है।
- हर गंध को ठीक करने की कोशिश की जा रही है. बदसूरत कोड जो शायद ही कभी बदलता है, अक्सर कम प्राथमिकता वाला होता है; उस स्थान पर ऊर्जा आवंटित करें जो बार-बार बदलता है।
संक्षेप में
रीफैक्टरिंग का एकमात्र नियम यह है कि व्यवहार स्थिर रहता है, और इसका प्रमाण परीक्षण हैं। एआई कोड गंध का पता लगाने, एक-चरणीय परिवर्तन और तकनीकी ऋण को प्राथमिकता देने में शक्तिशाली है; लेकिन आपको सुरक्षा जाल स्थापित करना होगा, परीक्षण चलाना होगा और प्रत्येक चरण के बाद अंतर को पढ़ना होगा। छोटे, प्रतिवर्ती कदम उठाएँ; रिफैक्टरिंग को व्यवहार परिवर्तन से अलग कर सकेंगे; और उस टीम को निर्णय लेने दें जो व्यावसायिक संदर्भ को जानती है कि कौन सा ऋण चुकाना है।
आवेदन कार्य
अपने कोड बेस से एक फ़ंक्शन चुनें जो आपको लंबा या जटिल लगे। पहले प्रिंट परीक्षण जो "सुरक्षा जाल" टेम्पलेट के साथ इसके वर्तमान व्यवहार को कैप्चर करते हैं और देखते हैं कि क्या वे सभी पास होते हैं। फिर फ़ंक्शन को "एक-चरण, व्यवहार-संरक्षण परिवर्तन" पैटर्न के साथ एक ही तरीके से दोबारा तैयार करें (उदाहरण के लिए आधे में विभाजित करना) और फिर से परीक्षण चलाएं। यदि कोई परीक्षण विफल हो जाता है, तो कारण पता करें; यदि यह बिल्कुल भी नहीं टूटता है, तो यह पुष्टि करने के लिए कि व्यवहार वास्तव में संरक्षित है, अलग-अलग पंक्ति दर पंक्ति पढ़ें।
चेकलिस्ट
- [ ] मैं जानता हूं कि रीफैक्टरिंग से व्यवहार नहीं बदलना चाहिए और इसे साबित करने के लिए परीक्षण हैं।
- [ ] मैं एक सुरक्षा जाल स्थापित कर रहा हूं जो रिफैक्टर से पहले वर्तमान व्यवहार को पकड़ लेता है।
- [ ] मैं एआई से छोटे, एक-चरणीय परिवर्तन चाहता हूं, बड़े एक-चरणीय परिवर्तन नहीं।
- [ ] प्रत्येक चरण के बाद मैं परीक्षण चलाता हूं और अंतर पढ़ता हूं।
- [ ] मैं पीआर को व्यवहार परिवर्तन पीआर से अलग रखता हूं।
- [ ] मैं व्यावसायिक संदर्भ के साथ तकनीकी ऋण को प्राथमिकता देता हूं, आंख मूंदकर शून्य करने की कोशिश नहीं करता।