Elke developer die lang genoeg aan een volwassen codebase werkt, kent het moment. De code is gelaagd geworden door jaren van aanpassingen. Beslissingen zijn genomen door mensen die het bedrijf al lang verlaten hebben. De architectuur past niet meer bij hoe de applicatie vandaag gebruikt wordt. En dan valt de zin: "Dit systeem is niet meer te redden. We beginnen opnieuw."

Ik heb die conclusie vaak zien trekken. Ze klinkt logisch, ze voelt bevrijdend, en ze is meestal fout.

Joel Spolsky schreef er in 2000 al een klassieker over, "Things You Should Never Do": it's harder to read code than to write it. Wie code leest die hij niet zelf schreef, vindt ze bijna per definitie rommelig. Dat zegt weinig over de code en veel over hoe lezen werkt.

Belangrijker is wat er in die rommelige code zit. Een productiesysteem dat jaren draait, bevat onzichtbare kennis. De uitzondering die ooit een escalatie bij een klant veroorzaakte en sindsdien stilletjes wordt afgevangen. Business logica die nergens beschreven staat maar wel klopt. Een koppeling met een extern systeem die op subtiel gedrag steunt waar geen letter documentatie over bestaat.

Die kennis staat niet in de documentatie, want die is verouderd of onvolledig. Ze zit ook niet in de hoofden van het huidige team, want de mensen die de oorspronkelijke keuzes maakten, zijn weg. Ze zit alleen nog in de code.

Bij een herschrijving gooi je dat allemaal weg. De nieuwe applicatie repliceert de zichtbare functionaliteit, en de onzichtbare kennis ontdek je pas achteraf, klacht per klacht, telkens als een gebruiker meldt dat iets "vroeger wel werkte". Daarom lopen grote herschrijfprojecten zo vaak uit of stranden ze helemaal. Zelden omdat de developers niet goed genoeg waren. Bijna altijd omdat iedereen de complexiteit van het bestaande systeem onderschatte.

Wanneer herschrijven wél de juiste keuze is

Ik wil eerlijk blijven: soms kan het echt niet anders. Als de applicatie gebouwd is op een taal of framework waar je geen developers meer voor vindt. Als de architectuur zo fundamenteel gebroken is dat elke incrementele verbetering op de fundering zelf botst. Of als de zakelijke vereisten zo drastisch veranderd zijn dat het bestaande systeem geen bruikbare basis meer is.

Dat zijn echte scenario's, we zijn ze allemaal al tegengekomen. Ze zijn alleen zeldzamer dan de meeste teams denken op het moment dat de frustratie het hoogst is.

Wat refactoren concreet inhoudt

Refactoren is niet "eens opruimen". Het is de structuur van een systeem verbeteren zonder het gedrag te veranderen, in kleine, controleerbare stappen.

Hoe dat er in de praktijk uitziet, hangt af van de applicatie, maar het patroon is herkenbaar. We beginnen bijna altijd met testcoverage op de kritieke flows, want zonder vangnet is elke aanpassing gokwerk. Daarna gaat het om modules met te veel verantwoordelijkheid opsplitsen, business logica uit controllers en views halen, en dependencies bijwerken zonder de boel te destabiliseren. Elke stap levert een applicatie op die exact hetzelfde doet als ervoor, maar iets beter te begrijpen, te testen en uit te breiden is.

Het grote verschil met een herschrijving: dit gebeurt terwijl de applicatie gewoon in productie draait. Er is geen big bang, geen migratieweekend, geen periode waarin twee systemen naast elkaar onderhouden moeten worden zonder dat één van beide af is.

De middenweg voor grote systemen: strangler fig

Voor grote applicaties bestaat er een derde weg: het strangler fig pattern. Je vervangt het systeem module per module. Nieuwe functionaliteit bouw je in de nieuwe architectuur, de bestaande code blijft ondertussen actief, en stap voor stap verhuist het verkeer van oud naar nieuw tot er van het oude systeem niets meer overblijft.

Bij grotere moderniseringstrajecten werken wij meestal zo. Het risico blijft klein, de business draait door en het team bouwt tijdens het traject precies de systeemkennis op die bij een klassieke herschrijving verloren gaat.

Eerst kijken, dan oordelen

Bij Refaktory zit de voorkeur in onze naam, dus enige vooringenomenheid mag je ons aanwrijven. Daarom beginnen we nooit met een aanbeveling maar met een technische audit: hoe staat de codebase ervoor, waar zit de risico's, wat kost welke weg over meerdere jaren. Komt daar uit dat herschrijven de enige realistische optie is, dan zeggen we dat, met de reële kosten en risico's erbij. We hebben niets aan een advies dat zes maanden later ontploft.

Veelgestelde vragen

Hoe weet ik of mijn applicatie refactorbaar is? Vrijwel elke applicatie is refactorbaar. De echte vraag is hoeveel werk het is en wat het oplevert en dat verschilt enorm per codebase. Daarom doen we altijd eerst een technische audit.

Is refactoren goedkoper dan herschrijven? In de meeste gevallen aanzienlijk, om twee redenen. Herschrijfprojecten lopen structureel uit omdat de complexiteit van het oude systeem onderschat wordt. En refactoring levert tussentijds al waarde op, terwijl een herschrijving pas iets oplevert als alles af is.

Kunnen we de applicatie blijven gebruiken tijdens een refactoring? Ja, dat is net het punt. De applicatie blijft in productie draaien terwijl het werk gebeurt.

Wat als de codebase echt niet meer te redden is? Dan zeggen we dat, met de reële kosten en risico's van een herschrijving erbij. Een advies dat niet klopt, komt vroeg of laat toch bij ons terug.