आप कैसे तय करते हैं कि किसी सिस्टम को refactor करना है बनाम शुरू से rewrite करना है?

Question

Accepted Answer

डिफ़ॉल्ट रूप से **refactoring** चुनें। एक rewrite तभी उचित है जब मौजूदा सिस्टम अब स्वीकार्य लागत पर आवश्यकताओं को पूरा करने के लिए विकसित नहीं हो सकता, और आप इसे करते समय मूल्य प्रदान करना जारी रख सकते हैं। अधिकांश "हमें rewrite चाहिए" प्रवृत्तियाँ वास्तव में एक अप्रबंधित tech-debt समस्या होती हैं जिसे incremental refactoring बहुत कम जोखिम के साथ हल करता है।

## मैं इस पर कैसे तर्क करता हूँ

- **क्या मुख्य architecture अभी भी व्यवहार्य है?** अगर data model, सीमाएँ, और runtime नई आवश्यकताओं तक खिंच सकते हैं, तो refactor करें। अगर मूलभूत धारणाएँ गलत हैं (गलत storage paradigm, scale करने का कोई तरीका नहीं, language/platform end-of-life), तो rewrite एक वास्तविक उम्मीदवार बन जाता है।
- **change frequency क्या है?** जो कोड शायद ही कभी बदलता है, उसे सुंदर होने की ज़रूरत नहीं। जहाँ टीम रोज़ काम करती है, वहाँ प्रयास केंद्रित करें।
- **क्या हम मौजूदा व्यवहार को समझते हैं?** एक rewrite वर्षों के encode किए गए edge-case ज्ञान को फेंक देता है। अगर कोई tests और कोई spec नहीं है, तो rewrite पुराने बग्स को फिर से पेश करेगा।

## एक निर्णय framework

| संकेत | refactor की ओर झुकें | rewrite की ओर झुकें |
| --- | --- | --- |
| Architecture आवश्यकताओं में फिट | हाँ | नहीं |
| Test/spec coverage | कम या उच्च | समानता सत्यापित करने के लिए पर्याप्त उच्च |
| Incrementally ship कर सकते हैं | हाँ | कठिन, big-bang |
| टीम कोड समझती है | हाँ | नहीं, और मूल लेखक चले गए |

## Trade-offs

- **Refactor:** कम जोखिम, निरंतर delivery, लेकिन वास्तव में सड़ी हुई नींव पर धीमा।
- **Rewrite:** साफ़ स्लेट, लेकिन आप एक **feature-freeze कर** चुकाते हैं, **dual-maintenance लागत** उठाते हैं, और क्लासिक second-system over-engineering जाल का जोखिम लेते हैं।
- **strangler-fig** मध्य रास्ते को प्राथमिकता दें: नए सिस्टम को पुराने के साथ खड़ा करें, traffic को incrementally route करें, पुराने को टुकड़े-टुकड़े करके हटाएँ। यह refactor-स्तर के जोखिम के साथ rewrite के लाभ देता है।

## गलतियाँ

- व्यावसायिक लागत नहीं, बल्कि **सौंदर्य या resume-संचालित** कारणों से rewrite करना।
- छिपे हुए व्यवहार को कम आँकना; हमेशा पहले tests के साथ मौजूदा व्यवहार को characterize करें।
- एक बहु-तिमाही big-bang rewrite जो कुछ भी ship नहीं करता — गति और भरोसा दोनों ढह जाते हैं।

## यह क्यों महत्वपूर्ण है

refactor-बनाम-rewrite निर्णय एक Tech Lead द्वारा लिए गए सबसे उच्च-लाभ वाले निर्णयों में से एक है। इसे rewrite की ओर गलत करें और आप delivery को एक साल के लिए जमा सकते हैं और फिर भी विफल हो सकते हैं; इसे refactor की ओर गलत करें और आप धीरे-धीरे velocity का रक्तस्राव करते हैं। इसे स्वाद के निर्णय नहीं, बल्कि लागत-और-जोखिम के निर्णय के रूप में फ्रेम करना ही वह है जो senior निर्णय को प्राथमिकता से अलग करता है।

संकेत	refactor की ओर झुकें	rewrite की ओर झुकें
Architecture आवश्यकताओं में फिट	हाँ	नहीं
Test/spec coverage	कम या उच्च	समानता सत्यापित करने के लिए पर्याप्त उच्च
Incrementally ship कर सकते हैं	हाँ	कठिन, big-bang
टीम कोड समझती है	हाँ	नहीं, और मूल लेखक चले गए