Standard er å refaktorere. En omskriving er bare berettiget når det eksisterende systemet ikke lenger kan utvikle seg for å møte kravene til en akseptabel kostnad, og du kan fortsette å levere verdi mens du gjør det. De fleste "vi trenger en omskriving"-instinkter er egentlig et uhåndtert tech-debt-problem som inkrementell refaktorering løser med langt mindre risiko.
| Signal | Hell mot refaktor | Hell mot omskriving |
|---|---|---|
| Arkitektur passer kravene | Ja | Nei |
| Test-/spesifikasjonsdekning | Lav eller høy | Høy nok til å verifisere paritet |
| Kan levere inkrementelt | Ja | Vanskelig, big-bang |
| Teamet forstår koden | Ja | Nei, og originalforfatterne er borte |
Refaktor-vs-omskriving-beslutningen er en av de mest gjennomslagskraftige beslutningene en Tech Lead tar. Gjør den feil mot omskriving og du kan fryse leveransen i et år og likevel feile; gjør den feil mot refaktor og du blør velocity sakte. Å ramme den inn som en kostnads-og-risiko-beslutning, ikke en smaksbeslutning, er det som skiller seniorvurdering fra preferanse.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner