लेगेसी कोड समय के साथ और खराब होता जाता है
लेगेसी कोड समय के साथ बेहतर नहीं होता। यह और खराब होता जाता है।
पिछले हफ्ते, मैंने एक बग ठीक करने में तीन घंटे बिताए। इसमें केवल 20 मिनट लगने चाहिए थे। समस्या 2019 का एक वैलिडेशन मॉड्यूल (validation module) थी। हर कोई इसे नज़रअंदाज़ कर रहा था क्योंकि "यह काम करता है।" लेकिन यह काम नहीं कर रहा था। मुझे फ़ाइल के अंदर 2020 का एक TODO कमेंट मिला।
कई लोग लेगेसी कोड को एक वैकल्पिक ऋण (optional debt) की तरह मानते हैं। उन्हें लगता है कि जब उनके पास समय होगा, तब वे इसे चुका देंगे। लेगेसी कोड फफूंद (mold) की तरह है। यह फैलता है। यह आपके सिस्टम के अन्य हिस्सों को भी दूषित कर देता है। आप इसे जितना अधिक नज़रअंदाज़ करेंगे, इसे साफ करना उतना ही महंगा होता जाएगा।
यह एक बुरा चक्र बनाता है:
- आपको एक अव्यवस्थित प्रोजेक्ट विरासत में मिलता है।
- आप अपने फीचर को काम कराने के लिए एक और 'if' स्टेटमेंट जोड़ देते हैं।
- छह महीने बाद, कोई और भी यही करता है।
- एक साल बाद, फ़ाइल में 800 लाइनें होती हैं और एक भी टेस्ट नहीं होता।
इस "काम करने वाले" कोड की कुछ छिपी हुई लागतें हैं:
- डेवलपमेंट की गति कम हो जाती है। आप कोड लिखने के बजाय कॉन्टेक्स्ट (context) पढ़ने में अधिक समय बिताते हैं।
- बग्स बढ़ जाते हैं। एक चीज़ ठीक करने से दूसरी चीज़ खराब हो जाती है।
- ऑनबोर्डिंग (onboarding) कठिन हो जाती है। नए डेवलपर्स को यह समझने में संघर्ष करना पड़ता है कि हर जगह लॉजिक की डुप्लीकेसी क्यों है।
इन रेड फ्लैग्स (red flags) पर नज़र रखें:
- बेकार या भ्रामक कमेंट्स।
- अलग-अलग फ़ाइलों में डुप्लिकेट बिजनेस लॉजिक।
- सर्कुलर डिपेंडेंसीज़ (circular dependencies) और हाई कपलिंग (high coupling)।
सब कुछ फिर से लिखने (rewrite) की कोशिश न करें। फुल रीराइट्स 80% बार विफल हो जाते हैं। आप उस चीज़ को फिर से बनाने में महीनों बिता देते हैं जो पहले से मौजूद है, जबकि बिजनेस नए फीचर्स का इंतज़ार कर रहा होता है।
कैरेक्टराइजेशन टेस्ट (characterization tests) के साथ इंक्रीमेंटल रिफैक्टरिंग (incremental refactoring) का उपयोग करें:
- वर्तमान व्यवहार (behavior) को टेस्ट के साथ कैप्चर करें, भले ही वह अजीब क्यों न हो।
- उस व्यवहार को बदले बिना रिफैक्टर करें।
- इसे तब तक दोहराते रहें जब तक कोड पढ़ने योग्य न हो जाए।
- उसके बाद ही असली टेस्ट के साथ व्यवहार बदलें।
जाल से बचने के लिए इन नियमों का पालन करें:
- बिना टेस्ट के कभी रिफैक्टर न करें।
- रिफैक्टरिंग के दौरान व्यवहार न बदलें। एक बग कोई ऐसा अनडॉक्युमेंटेड फीचर हो सकता है जिस पर क्लाइंट निर्भर करता हो।
- शांत कोड (quiet code) को अकेला छोड़ दें। यदि कोई मॉड्यूल तीन साल से नहीं बदला है और कोई समस्या पैदा नहीं कर रहा है, तो उसे वैसा ही रहने दें।
अपनी ऊर्जा उस कोड पर केंद्रित करें जिसे आप बार-बार छूते हैं।
स्रोत: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h