Wanneer moet een module worden herbouwd in plaats van gerepareerd?

Je hebt het invoiceringmodule dit kwartaal drie keer gepatcht. Elke fix werkt een week, en dan breekt er weer iets anders — een rapport telt niet correct op, een knop geeft alleen op dinsdag een fout, een collega wijzigt één veld en plots klopt de verzendberekening niet meer. Niemand op het team wil dat deel van het systeem nog aanraken, en iedereen wijkt er stilzwijgend omheen in plaats van het goed op te lossen.

Dat gevoel — "we zijn bang voor dit module" — is het duidelijkste signaal dat reparatie niet meer werkt. Dit artikel geeft je een praktische manier om module voor module te beslissen of je door gaat met patchen of dat je moet herbouwen.

Waarom houdt "zet het gewoon recht" uiteindelijk op te werken?

Elke patch voegt een kleine hoeveelheid complexiteit boven op het oorspronkelijke ontwerp. Elk fix is op zichzelf redelijk: een extra voorwaarde hier, een workaround daar, een nieuw veld om een uitzondering op te slaan. Maar voorwaarden stapelen zich op. Een module die vijf jaar geleden een schoon script van 200 regels was, kan uitgroeien tot een warnet van geneste if-statements, elk toegevoegd om een specifieke klant, een specifieke promotie of een specifiek edge case aan te pakken dat niemand heeft gedocumenteerd.

Dit is technische schuld in zijn meest concrete vorm. Het is geen vaag begrip — het zijn de werkelijke opgetelde kosten van elke snelweg genomen om een deadline te halen. Rente op die schuld wordt betaald elke keer dat iemand het hele script moet lezen om slechts één veld toe te voegen, of elke keer dat een fix op de ene plek iets op de andere plek breekt omdat de logica te verstrengeld is om veilig over na te denken.

Op een bepaald moment overschrijdt de cost van het begrijpen van bestaande code de cost van het schrijven van nieuwe code die hetzelfde werk schoon doet. Dat is het moment waarop herbouwen goedkoper wordt dan repareren — hoewel het van tevoren voelt als de duurdere optie.

Wat zijn de concrete waarschuwingstekens dat een module moet worden herbouwd?

Je hebt geen intuïtie nodig — je kunt deze signalen rechtstreeks controleren:

1. Dezelfde area breekt herhaaldelijk. Als het kortingsberekeningsscript in zes maanden vier aparte bugfixes nodig had, is het probleem niet de laatste bug — het is het ontwerp.
2. Niemand wil het aanraken. Als je interne developer zegt "laten we dat deel niet aanraken, het is fragiel," dat is een rechtstreekse erkenning dat het module niet meer onderhoudbaar is.
3. Fixes kosten onevenredig veel tijd. Een wijziging van één regel bedrijfslogica die één uur zou moeten duren maar drie dagen duurt vanwege verborgen afhankelijkheden, is een teken dat de structuur elk wijziging tegen gaat.
4. Het overleeft alleen omdat één persoon het onthoudt. Als het begrijpen van het module afhangt van een developer die het acht jaar geleden heeft gebouwd en inmiddels weg is, heb je één single point of failure, geen onderhoudbaar systeem.
5. Nieuwe vereisten passen niet in de vorm van het oude ontwerp. Een module gebouwd voor voorraadbeheer in één magazijn die nu drie magazijnen, batch tracking en API-driven voorraadsynchronisatie van een webshop moet afhandelen, wordt gevraagd iets te doen waarvoor het nooit is ontworpen.
6. Workarounds zijn permanent geworden. Handmatige exports naar Excel "voor nu" die twee jaar stiekem hebben gedraaid, zijn een teken dat het module zijn werk niet meer kan doen zonder menselijk patchen eromheen.

Als een module twee of meer van deze signalen vertoont, is het een kandidaat voor herbouwen — niet omdat het oud is, maar omdat reparatie risico niet meer vermindert.

[[IMAGE:right|oude verwarde code module versus schoon herbouwd module, naast elkaar]]

Wanneer is reparatie nog steeds de juiste keuze?

Herbouwen is niet automatisch de verantwoorde keuze — het is een echte cost, en een onnodig herbouwen kan budget verbranden en nieuwe bugs introduceren in iets dat eigenlijk goed werkte. Reparatie is meestal goed wanneer:

• De bug is geïsoleerd en raakt niet de kernlogica van het module (een weergaveopmaakingskwestie, een ontbrekende validatie, een eenmalige uitzondering).
• Het module heeft in dit gebied nog niet eerder een fix nodig gehad.
• De bedrijfsvereisten eromheen zijn stabiel — niemand vraagt dit deel van het systeem iets fundamenteel nieuws te doen.
• De fix kan in uren, niet dagen, gemaakt, getest en ingezet worden.

Een goed vuistregel: als je de fix in één zin kunt beschrijven en het vereist niet dat je eerst drie andere eigenaardigheden van het systeem aan iemand nieuws uitlegt, is het waarschijnlijk een echte reparatie, niet een symptoom van diepere rot.

Hoe beslis je — een praktisch kader

Loop door deze checklist voor het module in kwestie:

• Hoeveel bugfixes heeft dit module in de afgelopen 12 maanden nodig gehad? (3+ suggereert structurele problemen)
• Hoe lang duurt een gemiddelde kleine wijziging hier, vergeleken met vergelijkbare modules elders in het systeem?
• Begrijpt minstens één ander developer naast de originele auteur dit module goed genoeg om het veilig aan te passen?
• Groeien de bedrijfsvereisten voor dit module (nieuwe markten, nieuwe integraties, nieuwe rapportagebehoeften) of zijn ze stabiel?
• Is er een handmatige workaround die dit module vandaag ondersteunt?
• Als dit module morgen volledig uitviel, hoe lang zou het duren om service te herstellen — uren of weken?

Score eerlijk. Als de meeste antwoorden wijzen op instabiliteit, afhankelijkheid van stamkennis, of groeiende vereisten waar het module niet voor ontworpen was, plan een herbouw. Als de antwoorden wijzen op een stabiel, goed begrepen, af en toe buggy stuk code, ga door met repareren — en investeer je budget in het module dat werkelijk aandacht nodig heeft.

Hoe ziet een echte herbouw-versus-reparatie-beslissing er in de praktijk uit?

Beschouw een FileMaker-gebaseerd orderbeheerssysteem dat acht jaar is gegroeid. Het kernorder-entry module is solide — af en toe kleine bugs, snelle fixes, iedereen begrijpt het. Dat module blijft zoals het is.

Het voorraadbeheermodule daarentegen was gebouwd voor één magazijn en is vijf keer gepatcht om een tweede magazijn, nabestelbeheer en een webshop-integratie via een script dat elke nacht een spreadsheetexport pollt. Elke patch heeft de logica moeilijker gemaakt, en de laatste twee wijzigingen hebben elk iets onverwants breekt. Dat module is een duidelijke herbouwkandidate.

De herbouw zelf hoeft niet betekenen van nul af aan beginnen. In een modern FileMaker-omgeving kan herbouwen betekenen dat je het gegevensmodel en de bedrijfslogica correct herontwerpt, dan het interface herbouwt met iets als FmBetterforms zodat het module ook een schoner, moderner gebruikerservaring krijgt in plaats van slechts een technische herschrijving achter dezelfde oude schermen. Waar het module repetitieve beoordelingen omvat — zoals het markeren van welke nabestellingen handmatig beoordeling nodig hebben — kan een gerichte AI-laag zoals Klai tijdens de herbouw worden toegevoegd om handmatige selectie te verminderen, iets dat awkward op de oude structuur zou zijn vastgebeven maar natuurlijk in een herbouwde past.

Wat gebeurt er als je door gaat met repareren voorbij het moment dat je had moeten herbouwen?

De cost blijft niet gelijk — het samengesteld. Elke extra patch maakt de uiteindelijke herbouw duurder, omdat er meer gedrag is om omgekeerd te engineeren en behouden. Ondertussen breekt het module steeds weer in productie, wat echte bedrijfsimpact betekent: orders onjuist berekend, voorraadhoeveelheden fout, klanten beïnvloed. Teams onderschatten dit vaak omdat de reparatiekosten klein zijn en verdeeld, terwijl de herbouwkost één zichtbaar getal is — maar opgeteld kosten de reparaties meestal meer dan de herbouw zou hebben gekost.

Dit is precies het patroon beschreven in Loggix's bredere gids over hoe je bedrijfssoftware onderhoudbaar kunt houden als deze groeit: onderhoudsbaarheid is iets wat je eenmaal bereikt, het is iets wat je actief beheert module voor module als het systeem en het bedrijf beide blijven veranderen.

Veelgestelde vragen

Kunnen we slechts één module herbouwen zonder de rest van het systeem aan te raken? Ja — dit is een van de echte voordelen van een modulaire architectuur. Als het module duidelijke grenzen heeft (zijn eigen tabellen, zijn eigen scripts, gedefinieerde inputs en outputs), kan het in isolatie worden herbouwd en ingewisseld, zonder een volledige systeemherschrijving.

Hoe weten we dat de herbouw niet zal dezelfde problemen accumulate? Documenteer de bedrijfsregels die het oude module werkelijk afhandelde (niet gewoon waarvoor het oorspronkelijk ontworpen was) voordat je herbouwt, en bouw met duidelijke scheiding tussen gegevens, logica en interface. Een herbouw gedaan zonder aan te pakken waarom het originele module verviel zal op dezelfde manier vervallen.

Is een herbouw altijd duurder dan een reparatie? Vooruit, meestal wel. Over een horizon van 2-3 jaar, vaak niet — omdat reparatiekosten op een instabiel module neiging hebben zich te herhalen en te groeien, terwijl de onderhoudskost van een goed gebouwde herbouw vlak blijft.

Moeten we herbouwen tijdens een rustig moment of gewoon ernaast passen bij ander werk? Herbouwen onder tijdsdruk, ingeklemd tussen andere prioriteiten, is hoe het originele module fragiel eindigde. Behandel een herbouw als zijn eigen omgrensd project met zijn eigen timeline, niet als bijzaak.

Als je naar een module staart waarvan je vermoedons dat het deze grens heeft overschreden, helpt het een tweede, technische mening in te winnen voordat je budget ergens voor inzet. Loggix werkt regelmatig met teams samen om dit exact in te schatten — een bestaand FileMaker-module of legacy-systeem beoordelen, uitzoeken of de slimmere stap een gerichte reparatie, een gefaseerde herbouw of een modern vervangingssysteem is gebouwd met tools zoals FmBetterforms voor het interface of Klai voor de intelligente delen van de workflow — zodat de beslissing gebaseerd is op de werkelijke stand van de code, niet op hoe lang het al hoofdpijn veroorzaakt.