Een refactoring kan duplicatie verminderen en wijzigingen toch moeilijker maken als die verwarrende abstracties introduceert of de complexiteit naar een andere plek verplaatst. Om het resultaat te beoordelen, volstaat het niet om scores te vergelijken of alleen te controleren of de tests slagen: je moet bepalen wat je wilt verbeteren, meerdere signalen bekijken en nagaan of het systeem eenvoudiger te wijzigen is.
Deze gids legt uit hoe je de onderhoudbaarheid van een PHP-applicatie vóór en na een refactoring meet, zonder metrics op zichzelf tot doel te maken. De methode is bruikbaar voor een klasse, module of bedrijfsproces, zolang je hetzelfde bereik vergelijkt en de context vastlegt.
Waarom één metric de onderhoudbaarheid niet aantoont
Onderhoudbaarheid is het vermogen om een systeem met een aanvaardbaar risico te begrijpen, te testen en te wijzigen. Geen enkele indicator vertegenwoordigt deze vermogens op zichzelf. Minder regels code betekent niet noodzakelijk minder complexiteit; een hogere testdekking garandeert geen nuttige tests; en een gunstige statische score laat niet zien of het team het ontwerp begrijpt.
Bovendien kunnen metrics veranderen om redenen die niets met de refactoring te maken hebben: een bijgewerkte tool, andere analyseregels, wijzigingen in het bereik of gegenereerde code die in het rapport wordt opgenomen. Daarom moet je een getal interpreteren samen met de berekeningsmethode, het geanalyseerde gebied en de bekende beperkingen.
Het doel is niet om abstract te bewijzen dat de wijziging “de code heeft verbeterd”. Het is om na te gaan of een concreet probleem is opgelost zonder onevenredige risico’s te introduceren.
Bepalen welk vermogen om wijzigingen door te voeren je wilt verbeteren
Formuleer vóór het meten een toetsbare en afgebakende hypothese. Bijvoorbeeld: “Door de berekeningsregels uit deze klasse te halen, kunnen we ze testen zonder de HTTP-flow te starten” of “Door de afhankelijkheden van deze service te verminderen, zijn minder wijzigingen nodig om een regel toe te voegen”. De hypothese benoemt een verwacht resultaat en schrijft geen architectuur voor omdat die toevallig populair is.
Baken het gebied en de betrokken bewerkingen af: klassen, endpoints, commando’s, jobs of bedrijfsregels. Noteer ook wat buiten scope valt, zoals een externe integratie of bekende technische schuld die niet wordt aangepakt. Zonder die afbakening kan een vergelijking het effect van de refactoring vermengen met andere wijzigingen.
Vertaal de hypothese bij voorkeur naar praktische observaties. Wordt het eenvoudiger om de regel te vinden? Kan die zonder een echte database worden getest? Neemt het aantal modules af dat moet worden gewijzigd voor een veelvoorkomende aanpassing? Kies enkele vragen die het team met bewijs kan beantwoorden.
Een nulmeting vastleggen voordat je de code wijzigt
Leg de beginsituatie vast bij een herkenbare revisie van de repository, met dezelfde tools en configuratie die je later gebruikt. Voor een PHP-gebied kan een combinatie van de volgende signalen nuttig zijn:
- Complexiteit: bekijk lange methoden, vertakkingen en plekken waar beslissingen zich opstapelen. Cyclomatische complexiteit kan richting geven, maar beschrijft op zichzelf niet hoe moeilijk een regel te begrijpen is.
- Koppeling: breng directe afhankelijkheden, vermengde verantwoordelijkheden en verbindingen met infrastructuur in kaart. Kijk of een wijziging vereist dat je niet-gerelateerde componenten kent of aanpast.
- Duplicatie: vind herhaalde logica en maak onderscheid tussen onbedoelde duplicatie en vergelijkbare regels die onafhankelijk van elkaar moeten evolueren.
- Tests: leg vast welke belangrijke gedragingen zijn afgedekt, welke tests betrouwbaar zijn en welke afhankelijkheden maken dat een test externe services nodig heeft.
- Operatie en oplevering: noteer relevante productieproblemen of regressies, hoe moeilijk het is om de wijziging uit te rollen en welke handmatige stappen erbij horen, als die verband houden met het gebied.
Bewaar bij statische analyse de naam en versie van de tool, de regels en het commando. Zonder die informatie is het getal niet reproduceerbaar. Scheid ook gegenereerde of externe code wanneer de configuratie dat toestaat en documenteer de uitsluitingen.
Controleerbare indicatoren kiezen en hun beperkingen vastleggen
Kies indicatoren die antwoord geven op de hypothese. Voor een refactoring die logica wil isoleren, kunnen het aantal afhankelijkheden dat nodig is om die logica te testen, de aanwezigheid van relevante gedragstests en de tijd die een teamlid nodig heeft om het wijzigingspunt te vinden nuttig zijn. Om koppeling te verminderen, kun je bekijken hoeveel componenten moeten worden aangepast voor een representatieve taak.
Beschouw tijden en aantallen niet als universele waarheden: de omvang van de taak, de ervaring van degene die haar uitvoert en onderbrekingen spelen mee. Leg die omstandigheden vast als je deze gegevens gebruikt en behandel het resultaat als een signaal, niet als een vergelijking van de productiviteit van personen.
Documenteer elke indicator met vier gegevens: wat die meet, hoe je die verkrijgt, welk resultaat je verwachtte en wat die niet kan aantonen. Een telling van afhankelijkheden kan bijvoorbeeld een afname laten zien, maar bewijst niet dat de nieuwe abstracties gemakkelijk te begrijpen zijn. De technische review moet dat beoordelen.
Voor en na vergelijken met dezelfde methode
Herhaal na de refactoring de analyse voor hetzelfde bereik, met dezelfde configuratie en waar mogelijk onder gelijkwaardige omstandigheden. Houd functionele en structurele wijzigingen in de review uit elkaar. Als beide tegelijk zijn gewijzigd, geef dan aan welk bewijs bij welke wijziging hoort en schrijf niet het volledige resultaat toe aan de refactoring.
Test naast de metrics ook een echte of representatieve wijziging: een regel corrigeren, een bedrijfsvoorwaarde toevoegen of een integratie aanpassen. Controleer welke bestanden moesten worden gewijzigd, welke tests nodig waren en waar onduidelijkheden ontstonden. Je hoeft geen kunstmatige taak te bedenken als er al vergelijkbaar werk bestaat; je moet wel voorkomen dat je een anekdotische indruk als doorslaggevend resultaat presenteert.
Een consistente verbetering combineert signalen: bijvoorbeeld minder afhankelijkheden om een regel te testen, gerichtere tests en een wijzigingspad dat het team kan uitleggen. Als de complexiteit van een methode afneemt, maar de logica meer verspreid raakt of de flow moeilijker te volgen wordt, moet de balans opnieuw worden beoordeeld.
Metingen combineren met review en feedback van het team
In de technische review moet worden nagegaan of verantwoordelijkheden duidelijker zijn, namen het domein weerspiegelen en de nieuwe interfaces een echte behoefte vervullen. De review moet ook zoeken naar geïntroduceerde risico’s: dubbele contracten, verwarrend omgekeerde afhankelijkheden, onbedoelde gedragswijzigingen of een nieuwe laag die alleen aanroepen doorgeeft.
Feedback van het team levert bewijs over begrip en werking op. Vraag of het eenvoudiger is geworden om de regel te vinden, een test te schrijven of de omvang van een wijziging in te schatten. Koppel antwoorden aan concrete voorbeelden en leg meningsverschillen vast: een architectuur kan duidelijk zijn voor degene die haar heeft gemaakt en ondoorzichtig voor degene die het systeem onderhoudt.
Controleer in PHP ook of de refactoring bestaande contracten respecteert: types, exceptions, side-effects, serialisatie en waarneembaar gedrag van API’s. Een netter intern ontwerp compenseert geen functionele regressie of onvoorziene incompatibiliteit.
Veelgemaakte fouten bij het meten van onderhoudbaarheid
- Testdekking najagen: het percentage verhogen kan oppervlakkige tests opleveren. Beoordeel of gedrag en risicoscenario’s worden getest, niet alleen of regels code worden uitgevoerd.
- Minder regels code belonen: code compacter maken kan beslissingen verhullen en wijzigingen moeilijker te reviewen maken. Omvang is geen directe maat voor duidelijkheid.
- Een score optimaliseren: code aanpassen aan een tool kan het ontwerpprobleem ongemoeid laten. Onderzoek wat de wijziging betekent en bevestig het effect met een echte taak.
- Verschillende scopes vergelijken: nieuwe bestanden, uitgesloten code of gewijzigde regels combineren maakt de interpretatie ongeldig. Houd de methode stabiel of licht verschillen toe.
- Gedrag negeren: een refactoring moet het verwachte gedrag behouden, tenzij de functionele wijziging afzonderlijk is gedefinieerd en gevalideerd.
Kort sjabloon om te bepalen hoe je verdergaat
Leg bij het afronden van de evaluatie het volgende vast:
- Gebied en doel: welk deel is geherstructureerd en welk vermogen om wijzigingen door te voeren moest worden verbeterd.
- Nulmeting en methode: code-revisie, tools, configuratie, scope en uitsluitingen.
- Waargenomen signalen: resultaten voor en na, plus de beperkingen van elke indicator.
- Praktische validatie: tests, technische review en bewijs uit een representatieve wijziging.
- Resterende risico’s: niet-afgedekt gedrag, uitgestelde technische schuld en operationele effecten die nog moeten worden gecontroleerd.
- Besluit: ga verder als de hypothese standhoudt en de risico’s aanvaardbaar zijn; stuur bij bij gemengde signalen of begripsproblemen; stop als de kosten of risico’s groter zijn dan het verwachte voordeel.
De slotvraag is niet of de code een betere score heeft, maar of het team dat deel met meer duidelijkheid en controle kan wijzigen. Een reproduceerbare nulmeting, verschillende aanvullende signalen en een eerlijke review helpen om die beslissing te nemen zonder refactoringactiviteit te verwarren met een aangetoonde verbetering.
