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