Inleiding
In software‑ontwikkeling horen we vaak: “DRY – Don’t Repeat Yourself”. Het klinkt als een gouden regel, maar in de praktijk kan blind vasthouden aan DRY leiden tot onduidelijke, fragiele code. Deze tekst legt uit waarom je soms beter een stukje code dupliceert dan een slecht doordachte abstractie bouwt.
Het gevaar van een verkeerde abstractie
Een abstractie is bedoeld om gemeenschappelijke logica te centraliseren. Als de onderliggende functionaliteit echter niet echt gelijk is, ontstaat er een lelijke abstractie. Gevolgen:
- Onverwachte bijwerkingen: Een wijziging in de abstractie beïnvloedt onverwacht meerdere plekken.
- Moeilijke leesbaarheid: Ontwikkelaars moeten nu door een extra laag heen om te begrijpen wat er gebeurt.
- Beperkte flexibiliteit: Nieuwe use‑cases passen niet meer in de starre structuur.
Wanneer duplicatie de betere keuze is
Duplicatie mag niet automatisch als schuld worden gezien. Overweeg het volgende:
- Kleine, geïsoleerde functionaliteit – Een paar regels die in één context logisch zijn, hoeven niet centraal te staan.
- Verschillende requirements – Als de toekomstige eisen per locatie uiteenlopen, blijft duplicatie onderhoudbaar.
- Snelle prototyping – Bij een proof‑of‑concept kun je sneller itereren zonder een complexe abstractie.
Praktische richtlijnen
- Analyseer de gemeenschappelijkheid: Zijn de variabelen, error‑handling en performance‑aspecten echt gelijk?
- Start met duplicatie: Schrijf de code op de plek waar hij nodig is. Als later meerdere plekken exact dezelfde logica hebben, refactor dan.
- Houd abstracties klein: Een goede abstractie heeft een enkele verantwoordelijkheid en is makkelijk te testen.
- Documenteer intentie: Leg in commentaar vast waarom je voor duplicatie hebt gekozen; later kan dit helpen bij refactoring.
Voorbeeldscenario
Stel je voor dat je twee API‑endpoints hebt die elk een JSON‑payload transformeren, maar met een iets andere validatieregel. Een poging om één functie te maken leidt tot een wirwar van if‑statements en parameters. Door twee aparte functies te houden, blijft elke functie helder en kun je later, als de regels samenvallen, één gemeenschappelijke functie extraheren.
Conclusie
DRY is een nuttige richtlijn, maar geen onfeilbare wet. Het belangrijkste is om de kwaliteit van je code te bewaken. Soms is duplicatie de kortste weg naar leesbare, onderhoudbare software. Wanneer je later echte duplicatie ziet, kun je altijd refactoren naar een solide abstractie – nu niet eerder.