Implicit alege refactoring-ul. O rescriere e justificată doar când sistemul existent nu mai poate evolua ca să îndeplinească cerințele la un cost acceptabil, și poți continua să livrezi valoare în timp ce o faci. Majoritatea instinctelor „avem nevoie de o rescriere” sunt de fapt o problemă de tech debt negestionat pe care refactoring-ul incremental o rezolvă cu mult mai puțin risc.
| Semnal | Înclină spre refactor | Înclină spre rescriere |
|---|---|---|
| Arhitectura se potrivește cerințelor | Da | Nu |
| Acoperire cu teste/specificație | Scăzută sau ridicată | Suficient de ridicată ca să verifici paritatea |
| Se poate livra incremental | Da | Greu, big-bang |
| Echipa înțelege codul | Da | Nu, iar autorii originali au plecat |
Decizia refactor-vs-rescriere e una dintre cele mai pârghii decizii pe care le ia un Tech Lead. Greșește-o spre rescriere și poți îngheța livrarea un an și tot să eșuezi; greșește-o spre refactor și pierzi velocitate încet. Încadrarea ca decizie de cost-și-risc, nu de gust, e ceea ce separă judecata senioră de preferință.