Domyślnie wybieraj refaktoryzację. Rewrite jest uzasadniony tylko wtedy, gdy istniejący system nie może już ewoluować, by spełnić wymagania przy akceptowalnym koszcie, i gdy potrafisz dalej dostarczać wartość w trakcie. Większość instynktów „potrzebujemy rewrite'u” to w rzeczywistości niezarządzany problem tech debtu, który stopniowa refaktoryzacja rozwiązuje przy znacznie mniejszym ryzyku.
| Sygnał | Skłaniaj się do refaktoru | Skłaniaj się do rewrite'u |
|---|---|---|
| Architektura pasuje do wymagań | Tak | Nie |
| Pokrycie testami/specyfikacją | Niskie lub wysokie | Wystarczająco wysokie, by zweryfikować parytet |
| Można dostarczać przyrostowo | Tak | Trudne, big-bang |
| Zespół rozumie kod | Tak | Nie, a oryginalni autorzy odeszli |
Decyzja refaktor kontra rewrite jest jedną z najbardziej dźwigniowych, jakie podejmuje Tech Lead. Pomyl się w stronę rewrite'u, a możesz zamrozić dostarczanie na rok i i tak ponieść porażkę; pomyl się w stronę refaktoru, a powoli wykrwawiasz velocity. Ujęcie tego jako decyzji o koszcie i ryzyku, a nie decyzji o guście, jest tym, co odróżnia seniorski osąd od preferencji.