Things You Should Never Do, Part I (2000)
किसी बड़े software system को शुरुआत से फिर से लिखना अक्सर messy legacy code से बचने का आकर्षक रास्ता माना जाता है, लेकिन टिप्पणीकार तर्क देते हैं कि यह आम तौर पर मौजूदा system में निहित मूल्य और feature parity तक पहुँचने में लगने वाले समय को कम आँकता है। कई लोग incremental refactoring, मज़बूत tests, और documentation को अधिक सुरक्षित रास्ते के रूप में रेखांकित करते हैं, जबकि यह मानते हैं कि कुछ दुर्लभ मामलों में code इतना खराब हो सकता है, requirements या technology इतनी बदल चुकी हो सकती है, या performance constraints इतने गंभीर हो सकते हैं कि पूर्ण पुनर्लेखन उचित हो। बातचीत greenfield projects के मनोवैज्ञानिक आकर्षण, stalled rewrites के व्यावसायिक जोखिमों, और छोटे rewritable codebases तथा लाखों lines of code वाले mission-critical systems के बीच अंतर करने की आवश्यकता को उजागर करती है.
संपूर्ण पुनर्लेखनों के प्रति समग्र रुख
- कई टिप्पणीकार अभी भी सहमत हैं कि पूर्ण पुनर्लेखन आम तौर पर जोखिम भरे होते हैं और अक्सर आवश्यकता के बजाय मनोविज्ञान से प्रेरित होते हैं।
- अन्य लोग तर्क देते हैं कि छोटे सिस्टमों (दसियों हज़ार LOC) में या वास्तव में रोगग्रस्त कोडबेस में, शुरुआत से फिर से बनाना सबसे व्यावहारिक विकल्प हो सकता है।
- “कभी पुनर्लेखन न करें” को एक सार्वभौमिक नियम मानने की आलोचना होती है; संदर्भ और पैमाना मायने रखते हैं।
पुनर्लेखन इतने आकर्षक क्यों लगते हैं
- Greenfield काम ज़्यादा मज़ेदार होता है; आप legacy सीमाओं, operations की परेशानियों, और उलझे हुए इतिहास से बच जाते हैं।
- डेवलपर्स अक्सर मानते हैं कि वे “इस बार सही करेंगे,” क्योंकि उनके पास ज्ञात requirements और hindsight होता है।
- अपने style को दूसरों के style से पढ़ना आसान होता है, इसलिए मौजूदा कोड उससे भी बदतर दिखता है जितना वह वास्तव में हो सकता है।
- पुनर्लेखन कभी-कभी, अनजाने में भी, autonomy और control की भावना वापस ला सकते हैं।
Refactoring और incremental बदलाव के पक्ष में तर्क
- Incremental refactoring एक working system को बनाए रखता है, आपको लगातार ship करने देता है, और जोखिम कम करता है।
- Dead code हटाना, खराब हिस्सों को अलग करना, और architecture को धीरे-धीरे सुधारना अधिक टिकाऊ माना जाता है।
- Comprehensive tests और भरोसेमंद documentation change को सुरक्षित बनाकर पुनर्लेखन की इच्छा को काफी घटाते हैं।
- कुछ लोग refactor-vs-rewrite की तुलना reform-vs-revolution से करते हैं: revolutions आम तौर पर बुरी तरह खत्म होती हैं, लेकिन reform से इनकार भी विस्फोटों की ओर ले जाता है।
पुनर्लेखन कब उचित हो सकते हैं
- जब मौजूदा system एक “angry monolith/obelisk” हो, जहाँ बदलाव अप्रत्याशित रूप से production तोड़ देते हैं और velocity गिर चुकी हो।
- जब मौजूदा functionality का बड़ा हिस्सा अब ज़रूरी न हो, इसलिए नया system काफ़ी सरल हो।
- जब मूल भाषा/framework/architecture आवश्यक performance या evolution को मूल रूप से रोकता हो।
- जब code quality “type two bad” हो: कोई structure नहीं, source control नहीं, एकल विशाल files, copy-paste chaos।
- कई लोग अनुभवी teams द्वारा किए गए सफल 50–100K LOC पुनर्लेखनों की रिपोर्ट करते हैं, जो domain से गहराई से परिचित थीं।
असफलताएँ, पैमाना, और संगठनात्मक कारक
- बड़े, बहु-वर्षीय पुनर्लेखन अक्सर अटक जाते हैं: teams अंततः पुराने और नए दोनों systems को production में बनाए रखती हैं।
- बड़े company rewrites के languish करने, second-system overdesign, और ऐसी teams के उदाहरण दिए जाते हैं जो जटिल greenfield replacement को निष्पादित ही नहीं कर पातीं।
- कुछ लोग नोट करते हैं कि पुनर्लेखन एक stealth career move हो सकता है: rewrite शुरू करो, greenfield coding का आनंद लो, और support तथा कठिन समझौतों के आने से पहले निकल जाओ।
अन्य विषय
- इस पर बहस कि code पढ़ना कठिन है या लिखना; अधिकांश सहमत हैं कि गहरी समझ ही असली कठिन हिस्सा है।
- Frameworks पर चर्चा होती है, एक तरीका idioms को मानकीकृत करने और onboarding आसान बनाने का; अन्य लोग जवाब देते हैं कि frameworks भी खराब हो सकते हैं और कोई सार्वभौमिक समाधान नहीं हैं।