Refactoring కు default అవ్వండి. ఇప్పటికే ఉన్న system ఒక ఆమోదయోగ్యమైన ఖర్చుతో requirements ను అందుకోవడానికి ఇక evolve కాలేనప్పుడు, మరియు మీరు దాన్ని చేస్తూనే విలువను అందించడం కొనసాగించగలిగినప్పుడు మాత్రమే ఒక rewrite సమర్థనీయం. చాలా "మాకు rewrite అవసరం" అంతర్ ప్రేరణలు నిజంగా incremental refactoring చాలా తక్కువ risk తో పరిష్కరించే ఒక unmanaged tech-debt సమస్య.
| Signal | Lean refactor | Lean rewrite |
|---|---|---|
| Architecture requirements కు సరిపోతుంది | Yes | No |
| Test/spec coverage | Low లేదా high | parity ను verify చేయడానికి తగినంత high |
| Incrementally ship చేయవచ్చు | Yes | Hard, big-bang |
| Team కోడ్ ను అర్థం చేసుకుంటుంది | Yes | No, మరియు original authors లేరు |
refactor-vs-rewrite నిర్ణయం ఒక Tech Lead తీసుకునే అత్యధిక-leverage నిర్ణయాలలో ఒకటి. rewrite వైపు దాన్ని తప్పుగా చేస్తే మీరు delivery ను ఒక సంవత్సరం పాటు freeze చేసి ఇంకా విఫలమవ్వగలరు; refactor వైపు దాన్ని తప్పుగా చేస్తే మీరు velocity ను నెమ్మదిగా రక్తస్రావం చేస్తారు. దాన్ని ఒక taste నిర్ణయం కాకుండా ఒక cost-and-risk నిర్ణయంగా ఫ్రేమ్ చేయడం, ఇది senior judgment ను preference నుండి వేరు చేస్తుంది.