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.
Hoe ik erover redeneer
- Is de kernarchitectuur nog levensvatbaar? Als het datamodel, de grenzen en de runtime kunnen rekken naar de nieuwe eisen, refactor. Als de fundamentele aannames verkeerd zijn (verkeerd storage-paradigma, geen manier om te schalen, language/platform end-of-life), wordt een rewrite een echte kandidaat.
- Wat is de change frequency? Code die zelden verandert hoeft niet mooi te zijn. Concentreer de inspanning waar het team dagelijks werkt.
- Begrijpen we het huidige gedrag? Een rewrite gooit jaren aan ingecodeerde edge-case-kennis weg. Als er geen tests en geen spec zijn, zal een rewrite oude bugs herintroduceren.
Een beslissingsframework
| 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 |
Trade-offs
- Refactor: lager risico, continue levering, maar traag op een werkelijk verrot fundament.
- Rewrite: schone lei, maar je betaalt een feature-freeze tax, draagt dual-maintenance cost, en riskeert de klassieke second-system over-engineering valkuil.
- Geef de voorkeur aan het strangler-fig tussenpad: zet het nieuwe systeem naast het oude op, route verkeer incrementeel, verwijder het oude stuk voor stuk. Het geeft rewrite-voordelen met refactor-niveau risico.
Valkuilen
- Herschrijven om esthetische of resume-driven redenen, niet om businesskosten.
- Verborgen gedrag onderschatten; karakteriseer huidig gedrag altijd eerst met tests.
- Een meerdere-kwartalen big-bang rewrite die niets ge-shipt — momentum en vertrouwen storten beide in.
Waarom het belangrijk is
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.