Herbouwen of repareren? Wat een code-audit je eerst vertelt

“We moeten het helemaal opnieuw bouwen.” Het is een zin die ik vaak hoor, meestal nadat een applicatie jarenlang door verschillende developers is aangepast, nieuwe functies steeds langer duren en elke release iets anders kapotmaakt.

Soms klopt het. Maar een volledige herbouw is duur, duurt langer dan gepland en brengt eigen risico’s mee. Voordat je die beslissing neemt, wil je weten wat er werkelijk aan de hand is. Daar is een code-audit voor.

Wat een code-audit is

Bij een audit loopt een ervaren developer de applicatie systematisch door: de code, de database, de afhankelijkheden, de hosting en de manier waarop er wordt gedeployed. Het resultaat is geen vaag oordeel maar een schriftelijk rapport met concrete bevindingen, op volgorde van risico, en een advies wat eerst moet.

Je hoeft zelf niet technisch te zijn om er iets aan te hebben. Een goed rapport legt per bevinding uit wat het probleem is, wat het je kost en wat het kost om het op te lossen.

Waar ik naar kijk

Structuur en leesbaarheid

Is duidelijk waar welke logica zit, of staat dezelfde berekening op vijf plekken net iets anders? Slecht gestructureerde code is de belangrijkste reden dat kleine wijzigingen veel tijd kosten.

Tests

Zijn er geautomatiseerde tests, en testen ze de dingen die er echt toe doen? Zonder tests is elke wijziging een gok, en dat verklaart vaak waarom releases spannend zijn.

Beveiliging

Verouderde pakketten met bekende lekken, wachtwoorden in de code, ontbrekende controles op wie wat mag. Dit zijn vaak de bevindingen met de hoogste prioriteit, en meestal relatief snel te verhelpen.

Afhankelijkheden en versies

Draait de applicatie op een framework- of PHP-versie die geen updates meer krijgt? Hoe ver loopt ze achter, en hoe groot is de stap om bij te komen?

Database en prestaties

Trage pagina’s komen vaak door een handvol zware queries of ontbrekende indexen. Dat is gericht te verbeteren zonder iets te herbouwen.

Deployment en hosting

Hoe komt een wijziging live? Handmatig via FTP, of via een geautomatiseerde pipeline? Is er een back-up, en is die ooit teruggezet?

Repareren of herbouwen: hoe je kiest

In de meeste audits blijkt de basis beter dan gevreesd. De problemen zitten geconcentreerd in een paar onderdelen, en die zijn stap voor stap te verbeteren terwijl de applicatie gewoon blijft draaien. Herbouwen is pas de juiste keuze als:

• het onderliggende framework of de taal geen toekomst meer heeft en een upgrade praktisch een herbouw is;
• het datamodel niet past bij hoe je bedrijf nu werkt, en elke nieuwe functie daar omheen moet werken;
• de kosten van onderhoud structureel hoger liggen dan wat een nieuwe versie zou kosten.

Ook dan is een herbouw zelden een big bang. Vaak werkt het beter om onderdelen één voor één te vervangen, zodat er geen maandenlange periode is waarin niets nieuws live gaat.

Wat je na een audit hebt

• Een helder beeld van de staat van je applicatie, in begrijpelijke taal.
• Een geprioriteerde lijst: wat moet nu, wat kan later, wat mag blijven zoals het is.
• Onderbouwing voor een beslissing: repareren, gefaseerd vervangen of herbouwen, met een inschatting van de kosten.

Twijfel je over de staat van een applicatie die je hebt overgenomen of laten bouwen? Een audit is een relatief kleine investering vergeleken met een herbouw die achteraf niet nodig bleek. Neem gerust contact op, dan bespreken we wat een audit voor jouw situatie inhoudt.