Kies standaard voor refactoren. Een rewrite is alleen gerechtvaardigd wanneer het bestaande systeem niet langer kan evolueren om aan de eisen te voldoen tegen acceptabele kosten, en je waarde kunt blijven leveren terwijl je het doet. De meeste "we hebben een rewrite nodig"-instincten zijn eigenlijk een onbeheerd tech-debt-probleem dat incrementeel refactoren met veel minder risico oplost.
| Signaal | Neig naar refactor | Neig naar rewrite |
|---|---|---|
| Architectuur past bij de eisen | Ja | Nee |
| Test-/spec-dekking | Laag of hoog | Hoog genoeg om pariteit te verifiëren |
| Kan incrementeel shippen | Ja | Lastig, big-bang |
| Team begrijpt de code | Ja | Nee, en oorspronkelijke auteurs weg |
De refactor-versus-rewrite-beslissing is een van de beslissingen met de hoogste hefboomwerking die een Tech Lead neemt. Doe je het fout richting rewrite, dan kun je de levering een jaar bevriezen en alsnog falen; doe je het fout richting refactor, dan bloed je langzaam velocity. Het framen als een kosten-en-risico-beslissing, geen smaakbeslissing, is wat senior oordeel scheidt van voorkeur.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren