Default रूपमा refactor गर। Rewrite तब मात्र न्यायोचित हुन्छ जब अवस्थित system स्वीकार्य लागतमा आवश्यकता पूरा गर्न विकास हुन सक्दैन, र तपाईंले त्यो गर्दा पनि मूल्य डेलिभर गरिरहन सक्नुहुन्छ। धेरैजसो "हामीलाई rewrite चाहिन्छ" भन्ने प्रवृत्ति वास्तवमा अव्यवस्थित tech-debt समस्या हो जसलाई incremental refactoring ले धेरै कम जोखिमका साथ समाधान गर्छ।
| संकेत | Refactor तर्फ झुक | Rewrite तर्फ झुक |
|---|---|---|
| Architecture ले आवश्यकता पूरा गर्छ | हो | होइन |
| Test/spec coverage | न्यून वा उच्च | समानता प्रमाणित गर्न पर्याप्त उच्च |
| Incrementally ship गर्न सकिन्छ | हो | कठिन, big-bang |
| टीमले कोड बुझ्छ | हो | होइन, र मूल लेखकहरू गइसके |
Refactor-बनाम-rewrite निर्णय Tech Lead ले गर्ने सबैभन्दा उच्च-प्रभावका निर्णयहरूमध्ये एक हो। यसलाई rewrite तर्फ बिगारे तपाईंले delivery एक वर्ष freeze गर्न सक्नुहुन्छ र अझै असफल हुन सक्नुहुन्छ; refactor तर्फ बिगारे तपाईंले velocity बिस्तारै रगताम्य गुमाउनुहुन्छ। यसलाई रुचि होइन, लागत-र-जोखिम निर्णयको रूपमा प्रस्तुत गर्नुले नै senior निर्णयलाई प्राथमिकताबाट छुट्याउँछ।