Definitie: Refactoring is het herstructureren van bestaande broncode zonder dat het externe gedrag van de software verandert. Het doel is code leesbaarder, beter onderhoudbaar en makkelijker uitbreidbaar te maken, zodat toekomstige aanpassingen sneller en veiliger gaan.
In het kort
- Bij refactoring verandert de binnenkant van de software, niet wat de gebruiker ziet of wat de software doet.
- De term verscheen volgens Wikipedia voor het eerst in 1990 in een artikel van William Opdyke en Ralph Johnson; Martin Fowler maakte het begrip breed bekend met zijn boek uit 1999.
- Refactoring gebeurt in kleine stappen, elk gecontroleerd met geautomatiseerde tests.
- Het is een belangrijke manier om technische schuld af te lossen zonder de software opnieuw te bouwen.
Wat is refactoring?
Software groeit. Er komen functies bij, uitzonderingen worden ingebouwd en verschillende ontwikkelaars voegen hun eigen stukken toe. Na verloop van tijd ontstaat code die nog werkt, maar lastig te lezen en te wijzigen is. Een functie van honderden regels, dezelfde berekening op vijf plekken of namen waaruit niemand meer kan afleiden wat ze doen.
Refactoring is het opruimen en herordenen van die code. Je splitst lange stukken op, geeft onderdelen duidelijke namen, haalt dubbele code samen en zet logica op de plek waar die hoort. Het belangrijkste kenmerk: de software doet daarna precies hetzelfde als daarvoor. Een gebruiker merkt niets, behalve misschien dat de software sneller wordt of dat toekomstige aanpassingen sneller klaar zijn.
Het Nederlandse werkwoord is refactoren, ook wel code refactoren. Soms wordt het vertaald als herstructureren of herfactoren, maar de Engelse term is in de praktijk gangbaar.
Waar komt de term refactoring vandaan?
Volgens Wikipedia dateert het eerste gebruik van de term in de literatuur van september 1990, in een artikel van William Opdyke en Ralph Johnson. Opdyke schreef in 1992 een proefschrift over het refactoren van objectgeoriënteerde frameworks. De grote doorbraak kwam in 1999 met het boek Refactoring: Improving the Design of Existing Code van Martin Fowler. TechTarget noemt Fowler de vader van refactoring. Zijn boek beschrijft een catalogus van kleine, benoemde technieken die nog altijd als referentie gelden.
Een voorbeeld van refactoring
Monkey Vision geeft het voorbeeld van een checkout in een webshop met 800 regels code in één bestand. Validatie, betaling en verzendopties staan door elkaar. Elke aanpassing aan de betaling raakt ook de rest, en niemand durft er nog aan te komen.
Bij refactoring splits je die code op in aparte onderdelen: één voor het controleren van de invoer, één voor de betaling en één voor de verzendopties. Elk onderdeel krijgt een duidelijke taak en een heldere naam. De klant ziet dezelfde checkout, met dezelfde stappen en uitkomsten. Maar wil je later een nieuwe betaalmethode toevoegen, dan hoef je alleen het betaalonderdeel aan te passen.
Welke refactoringtechnieken zijn er?
| Techniek | Wat je doet | Waarom |
|---|---|---|
| Extract method | Een stuk van een lange functie in een eigen functie zetten | Kortere, begrijpelijke onderdelen |
| Rename | Een variabele, functie of klasse een duidelijkere naam geven | Code die zichzelf uitlegt |
| Duplicaten samenvoegen | Herhaalde code vervangen door één gedeelde functie | Een wijziging hoeft maar op één plek |
| Magische getallen vervangen | Een losse waarde zoals 0,21 vervangen door een benoemde constante | Duidelijk wat het getal betekent |
| Move method | Een functie verplaatsen naar het onderdeel waar die logisch hoort | Logica bij elkaar, minder afhankelijkheden |
| Extract class | Een te grote klasse opsplitsen | Elk onderdeel één verantwoordelijkheid |
| Conditionals vervangen | Lange reeksen als-dan-regels ombouwen naar een overzichtelijker structuur | Makkelijker uitbreiden met nieuwe gevallen |
Moderne code-editors hebben veel van deze technieken ingebouwd. Hernoemen of een functie afsplitsen gaat dan met een paar klikken, en de editor past alle verwijzingen automatisch aan.
Wanneer is refactoren nodig?
Refactoring begint meestal bij een code smell: een signaal in de code dat er iets niet goed zit. Denk aan zeer lange functies, bijna dezelfde code op meerdere plekken of een klasse die te veel taken heeft. Goede momenten om te refactoren zijn:
- Voordat je een nieuwe functie toevoegt, als de bestaande code er slecht op aansluit. TechTarget adviseert om dan eerst te refactoren.
- Na een grote bugfix, als duidelijk werd dat de structuur de fout in de hand werkte.
- Bij prestatieproblemen, bijvoorbeeld door inefficiënte gegevensophaling.
- Bij een overdracht, zodat een nieuwe ontwikkelaar de code kan begrijpen.
- Doorlopend, als vast onderdeel van het werk, in kleine stappen.
Refactoring, herschrijven of herbouwen?
| Refactoring | Herstructureren | Herbouwen | |
|---|---|---|---|
| Wat verandert | Interne opbouw van code | Architectuur of technologie | Alles |
| Extern gedrag | Gelijk | Kan veranderen | Kan veranderen |
| Omvang | Kleine stappen | Groter traject | Volledig nieuw project |
| Risico | Laag, mits er tests zijn | Gemiddeld | Hoog |
Phoenixnap maakt dit onderscheid tussen refactoring en restructuring: herstructureren kan de architectuur, de technologie of het gedrag aanpassen, terwijl refactoring binnen de bestaande structuur blijft.
Monkey Vision hanteert een vuistregel: refactor als de code nog minstens twee jaar mee moet en uitbreiding wordt verwacht, en overweeg herbouw als herstel duurder wordt dan vervangen. Een volledige herbouw lijkt aantrekkelijk, maar je verliest ook alle kennis en uitzonderingen die in de bestaande code zitten.
Hoe pak je refactoring goed aan?
- Zorg voor tests. Geautomatiseerde tests leggen vast wat de software nu doet. Zonder tests weet je niet zeker of het gedrag gelijk blijft.
- Bepaal een doel. Wat moet beter: leesbaarheid, snelheid, uitbreidbaarheid van een specifiek onderdeel?
- Werk in kleine stappen. Eén wijziging, dan testen. Faalt een test, draai de laatste stap terug.
- Scheid refactoring van nieuwe functies. Combineer niet in één wijziging het opruimen van code en het toevoegen van gedrag; dat maakt fouten moeilijk te vinden.
- Leg vast wat je doet. Commit vaak en beschrijf waarom een wijziging nodig was.
- Laat meekijken. Een code review door een collega vangt fouten en houdt de keuzes begrijpelijk.
Red-green-refactor
Refactoring is ook een vast onderdeel van test-driven development, een werkwijze waarbij je eerst een test schrijft en daarna pas de code. TechTarget noemt deze aanpak red-green-refactor. Het werkt in drie stappen:
- Rood. Je schrijft een test voor de functie die je wilt bouwen. De test faalt, omdat de functie nog niet bestaat.
- Groen. Je schrijft de eenvoudigste code die de test laat slagen, zonder je druk te maken over de netheid.
- Refactor. Nu de test slaagt, ruim je de code op. De test bewaakt dat het gedrag gelijk blijft.
Zo wordt refactoring geen apart project dat je uitstelt, maar een gewoonte bij elke wijziging.
Refactoring met AI-tools
AI-codeassistenten en codeeragents zoals Claude Code kunnen helpen bij refactoring. Real Python noemt refactoring en analyse over meerdere bestanden als toepassing van zulke tools. Ze kunnen een lange functie opsplitsen, betere namen voorstellen of dubbele code opsporen. Dat versnelt het werk, maar de regels blijven gelijk: er moeten tests zijn die bewaken dat het gedrag niet verandert, en een ontwikkelaar moet de wijzigingen beoordelen. Een AI-tool weet niet welke uitzonderingen er om een goede reden in de code zitten.
Veelgemaakte fouten bij refactoring
- Refactoren zonder tests, waardoor ongemerkt gedrag verandert.
- Te veel tegelijk aanpakken, waardoor een wijziging niet meer te overzien is.
- Te lang wachten, tot de code zo verweven is dat kleine stappen niet meer lukken.
- Geen duidelijk doel, waardoor refactoring een eindeloos project wordt.
- Het vergeten te plannen. Refactoring levert geen zichtbare nieuwe functie op en verdwijnt daardoor makkelijk van de planning.
Wat kost refactoring?
Refactoring kost ontwikkeltijd zonder direct zichtbaar resultaat. Daar staat tegenover dat elke volgende aanpassing sneller kan, met minder kans op fouten. De afweging is dezelfde als bij technische schuld: hoe langer je wacht, hoe duurder het wordt. Veel teams reserveren daarom een vast deel van hun tijd voor onderhoud en opruimwerk, in plaats van te wachten op een groot project.
Wat betekent dit voor jouw project?
Voordat code wordt aangepast, moet duidelijk zijn hoe het bestaande systeem werkt. Bij TaskZen zijn voor de rapportage eerst de bestaande componenten en de broncode onderzocht. Die volgorde vind ik belangrijk: eerst begrijpen wat er staat, dan bepalen wat beter kan.
Voor jou als opdrachtgever is het goed om te weten dat refactoring bij gezond onderhoud hoort. Spreek bij doorontwikkeling af hoe er wordt getest, hoe wijzigingen worden vastgelegd en hoeveel ruimte er is om code op te ruimen. Dan blijft de software ook op langere termijn aanpasbaar.
Loopt je bestaande applicatie vast bij elke aanpassing? Stuur me wat er nu gebeurt, wie ermee werkt en welke aanpassing je wilt doen. Dan bepalen we samen de logische eerste stap.
Veelgestelde vragen over refactoring
Wat is refactoring?
Refactoring is het herstructureren van bestaande broncode zonder het externe gedrag te veranderen. Het maakt code leesbaarder en beter onderhoudbaar, zodat toekomstige aanpassingen sneller en veiliger gaan.
Wat is het verschil tussen refactoring en herschrijven?
Bij refactoring verbeter je de bestaande code in kleine stappen terwijl de software hetzelfde blijft werken. Bij herschrijven bouw je een onderdeel of de hele applicatie opnieuw, met meer risico en een groter traject.
Waarom moet je code refactoren?
Code refactoren voorkomt dat software steeds moeilijker en duurder te wijzigen wordt. Het lost technische schuld af, maakt fouten makkelijker te vinden en helpt nieuwe ontwikkelaars de code sneller te begrijpen.
Verwante termen
Technische schuld · Broncode · Doorontwikkeling en onderhoud · Software-architectuur · Framework · Maatwerk software
← Terug naar de kennisbank