Hoe onderhoudsbaarheid meten

Elke interne ontwikkelaar heeft het minstens één keer gezegd: "Ik wil die module niet aanraken, ik ben niet zeker wat er kapot gaat." Elke CEO heeft zijn financeteam horen klagen dat een "snelle fix" in het ordersysteem drie weken in plaats van drie dagen duurde. Elke IT-manager heeft gezien hoe een eenvoudig feature-verzoek uitgroeide tot een meertalige archeologieproject, alleen maar om te begrijpen hoe de bestaande code überhaupt werkt.

Dit zijn allemaal symptomen van hetzelfde onderliggende probleem: lage onderhoudbaarheid. Het probleem is dat de meeste bedrijven onderhoudbaarheid pas opmerken wanneer deze al weg is — niemand plant een controlebeurt ervoor in, zoals zij dat doen voor een serverback-up of een veilighheidsaudit. Dit artikel geeft je een concrete manier om onderhoudbaarheid te meten voordat het een crisis wordt, zodat je kunt bepalen of je systeem een afstelling, refactoring of volledige herbouw nodig heeft.

Dit bouwt voort op ons bredere artikel over hoe je bedrijfssoftware onderhoudsbaar kunt houden naarmate deze groeit — als dat artikel het "waarom het belangrijk is," dan is dit de "hoe check ik dit eigenlijk."

Wat betekent "onderhoudbaarheid" eigenlijk?

Onderhoudbaarheid is de gemakkelijkheid waarmee een systeem kan worden begrepen, aangepast, uitgebreid en gerepareerd — door iemand die niet per se degene is die het oorspronkelijk heeft gebouwd. Het is niet hetzelfde als "de software werkt." Een systeem kan vandaag perfect in productie draaien en toch bijna onhoudbaar zijn, omdat niemand behalve één ontwikkelaar (die volgende maand weg zou kunnen gaan) begrijpt hoe het in elkaar zit.

Een nuttige gedachtetest: als je leidinggevende ontwikkelaar morgen door een bus wordt aangereden, zou een competente vervanger de order-verwerkingsmodule goed genoeg begrijpen om deze veilig binnen een week te wijzigen? Als het eerlijke antwoord "nee, dat zou maanden duren" is, heb je een onderhoudbaardheidsprobleem, ongeacht hoe soepel de software op dit moment draait.

Waarom kun je niet gewoon "voelen" of software onderhoudsbaar is?

Omdat intuïtie onbetrouwbaar is in beide richtingen. Een systeem dat vijf jaar geleden in een verouderd hulpmiddel is gebouwd, kan zeer onderhoudsbaar zijn als het schoon was gestructureerd, gedocumenteerd en modulair gehouden. Ondertussen kan een systeem dat vorig jaar op de nieuwste stack is gebouwd al een warboelenwarboel zijn als er onder druk van deadline shortcuts zijn genomen.

We hebben dit specifiek in FileMaker-projecten gezien: een 15 jaar oude oplossing met consistente naamgevingsconventies, duidelijke scriptmappen en een gegevensmodeldiagram aan de muur is vaak gemakkelijker uit te breiden dan een twee jaar oud systeem met 40 layouts met de naam "Layout 2 copy," scripts die op zes verschillende plaatsen worden geactiveerd, en bedrijfslogica verborgen in layout-berekeningen. Leeftijd is niet het signaal. Structuur is.

Welke concrete metrieken kun je gebruiken om onderhoudbaarheid te meten?

Je hebt geen academisch softwaretechnisch framework nodig om echt inzicht te krijgen. Deze vijf praktische metingen werken goed voor aangepaste bedrijfssoftware, inclusief FileMaker-oplossingen, ERP's en verbonden systemen:

1. Tijd tot eerste veilige wijziging. Geef een ontwikkelaar die het systeem nooit heeft aangeraakt, een klein, duidelijk gedefinieerd wijzigingsverzoek (bijv. "voeg een kortingsveld toe aan het factuurscherm"). Meet hoe lang het duurt voordat zij deze wijziging zonder onderbrekingen elders kunnen aanbrengen. Dagen is gezond; weken is een waarschuwingssignaal.
2. Wijzigingsfoutenpercentage. Van de laatste 20 geïmplementeerde wijzigingen, hoeveel veroorzaakten een bug, een ondersteuningsticket of een terugdraaiing binnen twee weken? Boven ongeveer 15-20% suggereert dat de structuur van het systeem je niet beschermt tegen onbedoelde neveneffecten.
3. Afhankelijkheidsdichtheid. Kies één kernrotatie of -module (bijv. de klantrecord). Tel hoeveel andere scripts, layouts of externe integraties direct afhankelijk zijn van de exacte huidige structuur. Hoe hoger het getal, hoe brozer elke wijziging aan die module wordt — dit is vaak waar FileMaker-oplossingen fragiel worden, omdat een layout, een script en een API-connector kunnen allemaal stilzwijgend afhankelijk zijn van dezelfde veldnaam.
4. Documentatiedekking. Welk percentage van de bedrijfskritieke scripts, workflows of API-eindpunten heeft minstens een verklaring van één alinea over wat zij doen en waarom? Geen documentatie is niet automatisch fataal voor een klein systeem, maar het wordt een serieuze aansprakelijkheid zodra het team voorbij twee ontwikkelaars groeit.
5. Onboardingtijd. Hoe lang duurt het voordat een nieuwe ontwikkelaar productief wordt — in staat om een echte, niet-triviale wijziging met begeleiding van een mentor, maar zonder veel begeleiding in te dienen? Twee weken is goed voor de meeste gemiddelde systemen; drie maanden is een waarschuwingssignaal.

Hoe zet je deze metrieken om in een echt antwoord?

Het meten van één hiervan in isolatie vertelt je weinig. Het patroon over alle vijf heen is wat telt. Een systeem met snelle tijd tot eerste veilige wijziging maar zeer hoge afhankelijkheidsdichtheid kan vandaag onderhoudsbaar lijken en onhoudbaar worden op het moment dat je je derde integratie toevoegt. Een systeem met uitstekende documentatie maar een hoog wijzigingsfoutenpercentage suggereert dat de documentatie intentie beschrijft, niet realiteit — wat bijna erger is dan geen documentatie, omdat het mensen actief misleidt.

Een praktische manier om dit als driemaandelijks of jaarlijks onderzoek uit te voeren:

• Kies 3-5 representatieve modules of workflows (niet het hele systeem tegelijk).
• Geef elk een score op de vijf metingen hierboven, zelfs ruwweg (groen/geel/rood is prima om mee te beginnen).
• Zoek naar herhaalde rode vlaggen over modules heen — dat is je werkelijk risicogebied, niet de ene luide klacht van vorige week's ondersteuningsticket.
• Vergelijk de score met dezelfde oefening zes of twaalf maanden eerder, als je die hebt. Trend is belangrijker dan enig moment in een keer.

Verandert het platform of de tooling hoe je dit meet?

De metrieken blijven hetzelfde, maar waar het risico verborgen zit, verandert afhankelijk van je platform.

In FileMaker concentreert het onderhoudbaarheidsrisico zich vaak op enkele specifieke plaatsen: bedrijfslogica verspreid over lay-outberekeningen in plaats van gecentraliseerde scripts, scripts die op meerdere plaatsen worden geactiveerd zonder enkele bron van waarheid, en naamgevingsconventies die verschuiven naarmate verschillende ontwikkelaars het bestand in de loop der jaren aanraken. Afhankelijkheidsdichtheid (metriek 3) is meestal de meest openbarende controle in een FileMaker-systeem, omdat FileMaker het erg gemakkelijk maakt om naar een veld of script vanuit veel plaatsen te verwijzen zonder dat een compiler je waarschuwt wanneer die verwijzing breekt.

In systemen die hebben begonnen met het toevoegen van AI-ondersteunde ontwikkeling aan de workflow — gebruikmakend van hulpmiddelen zoals Claude of vergelijkbare AI-coderingsassistenten om scripts te genereren, refactors voor te stellen of documentatie te schrijven — krijgt onderhoudbaarheidsmetingen een extra rimpel die de moeite waard is om in het oog te houden. AI-gegenereerde code kan schoon en goed van commentaar voorzien lijken, terwijl deze stilzwijgend patronen introduceert die niet overeenkomen met de rest van de codebase, of logica dupliceert die elders in het systeem al bestaat. Behandel AI-ondersteunde wijzigingen als een aparte categorie in je wijzigingsfoutenpercentagetracering, minstens voor de eerste paar maanden, zodat je kunt zien of zij onderhoudbaarheid echt helpen of alleen meer code produceren, sneller, die iemand nog steeds moet onderhouden.

Als je de interfacelaag hebt gemoderniseerd — bijvoorbeeld door een hulpmiddel zoals FM BetterForms te gebruiken om een FileMaker back-end een modernere, responsieve web-achtige voorkant te geven — meet de gebruikersinterface en de back-end afzonderlijk. Een mooie nieuwe interface kan achterliggende onderhoudsbaardheidsproblemen maskeren (of zelfs verergeren) als het onderliggende gegevensmodel en scripts niet tegelijkertijd zijn opgeruimd. We hebben teams zien doen met een gebruikersinterfaceverversing, een golf van verlichting voelen omdat alles "modern" uitziet, en anderhalf jaar later ontdekken dat dezelfde warboelscripts van daarvoor nog steeds aanwezig zijn, alleen in een mooier jasje.

Wat moet je doen zodra je weet dat je onderhoudbaardheidsscore laag is?

Het getal kennen is alleen nuttig als het een beslissing verandert. Een paar eerlijke volgende stappen afhankelijk van wat je vindt:

• Hoge afhankelijkheidsdichtheid in één module, alles anders is prima → isoleer en refactor die ene module voordat het wordt de bottleneck voor elke toekomstige functie.
• Lage documentatiedekking maar laag wijzigingsfoutenpercentage → je bent waarschijnlijk prima op korte termijn, maar je bent één kritieke persoon weg van een crisis. Begin eerst met het documenteren van de meest gebruikte workflows.
• Hoog wijzigingsfoutenpercentage overal → dit is meestal geen codeproblem, het is een procesproblem. Controleer of wijzigingen worden herzien en getest vóór implementatie, niet alleen de code zelf.
• Lange onboardingtijd → dit is vaak het eerste betrouwbare waarschuwingssignaal van een systeem dat een black box wordt, zelfs voordat bugs in productie beginnen.

Veelgestelde vragen: softwareonderhoudsbaarheid meten

Hoe vaak moeten we onderhoudbaarheid meten? Minstens eenmaal per jaar voor stabiele systemen; driemaandelijks als je actief het team groeit, integraties toevoegt of frequent wijzigingen verzendt.

Kunnen we onderhoudbaarheid zonder een speciaal hulpmiddel meten? Ja. De vijf metingen hierboven kunnen in een spreadsheet worden bijgehouden. De discipline om consistent te meten is veel belangrijker dan de geavanceerdheid van het hulpmiddel.

Is een onderhoudsbaardheidsscore hetzelfde als codekwaliteit? Nee. Code kan technisch schoon zijn en toch moeilijk te onderhouden zijn als niemand begrijpt waarom het op die manier was geschreven, of als het strak is gekoppeld aan systemen die onafhankelijk veranderen. Onderhoudbaarheid gaat over het hele systeem en de relatie van het team ermee, niet alleen de code zelf.

Verbetert het omschakelen van platform automatisch de onderhoudbaarheid? Nee — en dit is één van de duurzamere misverstanden die we zien. Een herbouw op een nieuw platform erft elke ongedocumenteerde bedrijfsregel en onduidelijke vereiste van het oude systeem, tenzij iemand deze tijdens de migratie opzettelijk vastlegt en opruimt. Platformkeuze is minder belangrijk dan structuur, documentatie en proces.

Een snelle checklist vóór je volgende onderhoudsbaarheidscontrole

• Hebben we gemeten hoe lang een kleine, echte wijziging voor iemand die de module niet kent, duurt?
• Kennen we ons wijzigingsfoutenpercentage voor de laatste 20 implementaties?
• Hebben we in kaart gebracht welke scripts, layouts of integraties van onze meest gebruikte tabellen of velden afhankelijk zijn?
• Is er minstens een verklaring van één alinea voor elke bedrijfskritieke workflow?
• Weten we hoe lang het momenteel duurt voordat een nieuwe ontwikkelaar hun eerste echte wijziging verzendt?
• Volgen we deze wijzigingen afzonderlijk in ons foutpercentage als we AI-ondersteunde codering gebruiken?
• Hebben we de back-end afzonderlijk op verborgen schulden gecontroleerd als we de gebruikersinterface hebben gemoderniseerd?

Als deze controlebeurt meer rode dan groene vlaggen naar voren brengt, is dat geen uitspraak dat alles moet worden herbouwd — het is een startpunt voor een gericht gesprek. Loggix voert regelmatig exact dit soort onderhoudsbaarheidsonderzoeken uit op aangepaste FileMaker-systemen, ERP's en de API-integraties die hen verbinden, en van daaruit in kaart wat de juiste volgende stap is — een gerichte refactoring, een slimmer gebruik van AI-hulpmiddelen in de bestaande workflow, een gemoderniseerde interfacelaag of een breder adviesgesprek over waar het systeem heen moet.