𝗛𝗼𝘄 𝗪𝗲 𝗗𝗲𝗰𝗶𝗱𝗲 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗥𝗲𝗳𝗮𝗰𝘁𝗼𝗿 𝗮𝗻𝗱 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗥𝗲𝘄𝗿𝗶𝘁𝗲

Elke ontwikkelaar krijgt hiermee te maken.

De codebase is traag. Het toevoegen van functies duurt te lang. Nieuwe medewerkers hebben moeite om het systeem te begrijpen. Uiteindelijk stelt iemand een volledige rewrite voor.

Het team splitst zich meestal in twee groepen. De ene groep wil opnieuw beginnen. De andere groep vreest het falen van eerdere rewrites. Beide kanten hebben geldige argumenten.

Een rewrite is geen wondermiddel. Het duurt vaak langer dan gepland. Je bent uiteindelijk twee systemen tegelijk aan het onderhouden. Je maakt in de nieuwe versie misschien zelfs dezelfde fouten opnieuw.

Een rewrite is zinvol in deze specifieke gevallen:

• Het datamodel is fundamenteel onjuist voor de business. • De technologie is verouderd en krijgt geen beveiligingsupdates meer. • De zakelijke behoeften zijn zo sterk veranderd dat het oorspronkelijke systeem verouderd is. • Niemand in het huidige team begrijpt hoe het systeem werkt.

Zelfs dan moet je geen 'big bang replacement' uitvoeren. Gebruik een 'strangler fig pattern'. Bouw het nieuwe systeem stukje bij beetje op naast het oude systeem.

Meestal is refactoren de juiste aanpak.

Refactoren is de juiste keuze wanneer:

• Je nog steeds functies kunt toevoegen, ook al gaat het traag. • Het team de huidige code begrijpt. • De chaos beperkt is tot specifieke modules. • De business niet kan stoppen met het leveren van nieuwe functies.

Voordat je een keuze maakt, vraag je af waarom de code slecht is geworden.

Als het probleem technische schuld (technical debt) is, refactor dan de slechtste onderdelen. Als het probleem een gebrek aan code reviews of een slechte cultuur is, zal een rewrite niet helpen. Je bouwt dan alleen een nieuwe puinhoop met dezelfde oude gewoontes.

Stel deze vragen voordat je een beslissing neemt:

• Kunnen we de slechtste onderdelen in isolatie repareren? • Is het datamodel niet meer geschikt voor de huidige zakelijke behoeften? • Welke kennis verliezen we als we opnieuw beginnen? • Heeft de business de stabiliteit om een lange transitie op te vangen?

Opnieuw beginnen voelt goed. De rewrite voltooien is het moeilijke deel. Meestal is een gestructureerd refactoringplan veiliger en effectiever.

Bron: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk