DRY, oftewel “Don’t Repeat Yourself,” is een fundamenteel principe in softwareontwikkeling dat stelt dat elke stuk kennis of logica binnen een systeem maar op één plek hoort te bestaan. Het doel is simpel: herhaling voorkomen. Dit lijkt op het eerste gezicht misschien vanzelfsprekend, maar in de praktijk sluipt duplicatie vaak ongemerkt in codebases, vooral naarmate projecten groeien.
Het DRY-principe werd voor het eerst geformuleerd in het boek The Pragmatic Programmer van Andrew Hunt en David Thomas. Zij stelden dat duplicatie de natuurlijke vijand is van een onderhoudbare en schaalbare codebase. Wanneer logica of data op meerdere plekken voorkomt, ontstaat het risico dat wijzigingen op de ene plek niet worden doorgevoerd op andere plekken. Met bugs en inconsistente applicatiegedragingen als gevolg.
DRY is dus geen kwestie van elegantie of stijl, maar een praktische richtlijn die helpt om software begrijpelijk, flexibel en betrouwbaar te houden.
DRY staat voor Don’t Repeat Yourself en betekent letterlijk: herhaal jezelf niet. In softwareontwikkeling verwijst dit naar het vermijden van duplicatie in code, logica, documentatie of zelfs configuratie. Het idee is dat elke “stukje kennis” in een systeem één enkele, ondubbelzinnige representatie moet hebben.
Een veelgebruikte definitie uit The Pragmatic Programmer luidt:
“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”
Eenvoudig gezegd: als een stuk logica al ergens bestaat, schrijf het dan niet ergens anders opnieuw. Als die logica ooit verandert, moet je elke kopie updaten, wat tijdrovend, foutgevoelig en moeilijk te onderhouden is.
Hoewel het principe vaak wordt toegepast op broncode, geldt DRY net zo goed voor:
Database design: zoals het normaliseren van gegevens om herhaling te voorkomen.
Configuratiebestanden: zoals het vermijden van dubbele instellingen in verschillende omgevingen.
Build pipelines of scripts: denk aan herbruikbare stappen in CI/CD-processen.
Documentatie: door centraal beheerde stukken tekst te gebruiken in plaats van alles te kopiëren.
DRY is dus geen specifiek programmeertrucje, maar een manier van denken: Waar komt deze logica nog meer voor, en hoe kan ik dat centraliseren of hergebruiken?
Het DRY-principe is essentieel omdat duplicatie problemen veroorzaakt vooral als projecten groeien en meerdere ontwikkelaars samenwerken. Hieronder lees je waarom DRY zo’n belangrijke rol speelt in professionele softwareontwikkeling.
Wanneer dezelfde logica op meerdere plekken staat, is het risico groot dat er één vergeten wordt bij een wijziging. Stel je voor dat je een berekening in vijf verschillende bestanden hebt staan. Als de regels veranderen, moet je die berekening op al die plekken aanpassen. Eén fout of vergeten aanpassing kan leiden tot inconsistent gedrag in de applicatie.
Met DRY verplaats je die logica naar één centrale plek. Daardoor hoef je slechts één wijziging door te voeren, wat het risico op fouten drastisch vermindert.
Code die DRY is, is eenvoudiger te onderhouden. Ontwikkelaars hoeven minder te zoeken en minder te begrijpen, omdat de logica gecentraliseerd is. Dit zorgt voor snellere updates, kortere debugging-tijd en overzichtelijke codebases.
In teams voorkomt DRY dat ontwikkelaars elkaars code dupliceren of onnodig herschrijven. Als logica eenmaal goed geïmplementeerd is, kunnen anderen die hergebruiken in plaats van opnieuw op te bouwen.
DRY moedigt het gebruik aan van herbruikbare componenten, functies of modules. Daardoor wordt het makkelijker om nieuwe functionaliteiten toe te voegen zonder bestaande onderdelen aan te tasten. De code groeit mee met het project, zonder dat de complexiteit explodeert.
Stel: je bouwt een formulier dat controleert of een e-mailadres geldig is. In een niet-DRY scenario zou je die validatielogica kopiëren naar elk formulier. In een DRY-aanpak bouw je één herbruikbare validatiefunctie die in alle formulieren gebruikt kan worden. Dat scheelt tijd, fouten en onderhoud.
Hoewel DRY in theorie logisch klinkt, zijn er in de praktijk talloze momenten waarop duplicatie tóch opduikt. Hieronder bespreken we een aantal veelvoorkomende situaties waarin het belangrijk is om het DRY-principe bewust toe te passen.
Vaak zie je dezelfde berekeningen of regels terugkeren in meerdere delen van een applicatie. Denk aan het berekenen van kortingen, btw of verzendkosten. Als die logica niet wordt gecentraliseerd, ontstaat er duplicatie in controllers, services of front-end code.
Oplossing: verplaats de logica naar één gedeelde functie of module.
In front-end frameworks zoals React of Vue komt duplicatie vaak voor bij visuele elementen: knoppen, formulieren of kaarten die telkens opnieuw worden opgebouwd met kleine variaties.
Oplossing: bouw herbruikbare componenten die je met props kunt aanpassen.
Zowel in development als productieomgevingen worden vaak dezelfde instellingen herhaald in verschillende config-bestanden. Dit leidt tot verwarring of fouten wanneer slechts één bestand wordt aangepast.
Oplossing: gebruik centrale configuratiebestanden of maak gebruik van variabelen (bijvoorbeeld .env-bestanden).
In grote applicaties komen dezelfde queries of joins vaak meerdere keren terug. Als de structuur van de database wijzigt, moeten al die plekken handmatig aangepast worden.
Oplossing: gebruik opgeslagen procedures, views of een ORM (zoals Prisma of Hibernate) met gecentraliseerde modellen.
Zonder structuur ontstaan snel dubbele regels in stylesheets. Vooral bij grote projecten met meerdere ontwikkelaars raakt CSS snel vervuild.
Oplossing: werk met utility-first CSS (zoals Tailwind), component-based styling of SCSS-variabelen.
Duplicatie in code of configuratie oplossen begint bij het herkennen van herhalende patronen. Pas daarna kun je ze aanpakken met de juiste aanpak. Er zijn verschillende manieren om duplicatie te verminderen of te elimineren, afhankelijk van het soort project en waar de duplicatie zich bevindt.
Een van de meest voorkomende methodes om DRY toe te passen is door herhalende logica te abstraheren naar functies, methodes, classes of modules.
Bijvoorbeeld:
// Duplicatie
const prijsMetBtw1 = prijs1 * 1.21;
const prijsMetBtw2 = prijs2 * 1.21;
// DRY aanpak
function berekenBtw(prijs) {
return prijs * 1.21;
}Deze aanpak voorkomt herhaling, maakt de code duidelijker én eenvoudiger aan te passen als het btw-tarief verandert.
Veel repetitieve taken kun je automatiseren. Denk aan:
Build scripts (bijv. Webpack, Gulp)
Test suites
CI/CD pipelines
Door standaardstappen te automatiseren, voorkom je handmatige fouten en dubbele logica over verschillende scripts of systemen.
In databases betekent DRY vaak: normaliseren. Dit houdt in dat je gegevens opsplitst in tabellen, zodat je informatie maar op één plek hoeft op te slaan. Zo voorkom je dat bijvoorbeeld klantgegevens zowel in een orders- als klantentabel staan.
Voorbeeld:
| OrderID | KlantID | KlantNaam (fout) |
|---|---|---|
| 101 | 1 | Jan Jansen |
Beter:
Klantentabel:
| KlantID | Naam |
|---|---|
| 1 | Jan Jansen |
Ordertabel:
| OrderID | KlantID |
|---|---|
| 101 | 1 |
Deze structuur zorgt voor betrouwbaardere data en minder onderhoud.
Hoewel DRY een krachtig principe is, bestaat er niet één universele aanpak voor alle situaties. Soms is het juist goed om herhaling toe te staan of abstracties uit te stellen. Er zijn alternatieve benaderingen die in sommige contexten beter werken, vooral bij jonge of snel veranderende projecten.
WET staat in de praktijk voor het tegenovergestelde van DRY: Write Everything Twice of zelfs “We Enjoy Typing”. Het idee is dat herhaling in sommige fases van een project acceptabel is, bijvoorbeeld:
Bij prototypes of experimenten
Wanneer je nog niet zeker weet wat stabiele logica is
Om leesbaarheid of snelheid van oplevering te verhogen
Voordeel: snelle iteratie, minder abstractie. Nadeel: als je niet oplet, groeit duplicatie snel uit tot een onderhoudsprobleem.
AHA is een meer pragmatische kijk op DRY. Het staat voor Avoid Hasty Abstractions, oftewel: vermijd overhaaste abstracties. Deze aanpak moedigt aan om pas te abstraheren als duplicatie zich daadwerkelijk meerdere keren voordoet én stabiel lijkt.
Stel, je ziet twee bijna identieke functies. De DRY-reflex is: “Dit moet één functie worden.” Maar als die functies net iets te veel van elkaar verschillen, kan het te vroeg combineren leiden tot ingewikkelde, slecht te begrijpen code.
AHA zegt: abstraheren mag, maar alleen als het écht logisch is.
Samengevat:
Het DRY-principe is populair met goede reden, maar zoals bij elk principe, zijn er ook valkuilen. In deze sectie kijken we naar de voordelen van DRY én de situaties waarin het juist tegen je kan werken.
Doordat logica maar op één plek staat, hoef je wijzigingen slechts één keer door te voeren. Dit verkleint de kans op fouten en inconsistent gedrag in je applicatie.
DRY dwingt je om code op te delen in duidelijke, herbruikbare blokken. Dat maakt het voor andere ontwikkelaars (en je toekomstige zelf) makkelijker om te begrijpen wat er gebeurt.
Door DRY ga je sneller denken in functies, modules of componenten die op meerdere plekken kunnen worden ingezet. Dit versnelt toekomstige ontwikkeling.
Goed geïsoleerde en gecentraliseerde logica is veel gemakkelijker te testen. DRY helpt ervoor te zorgen dat uw bedrijfsregels op één plek staan, waardoor unit testen gerichter en effectiever worden.
Een veelgemaakte fout is het te snel abstraheren van twee stukken code die slechts oppervlakkig op elkaar lijken. Dit leidt tot onnodig complexe functies met veel parameters of conditionele logica.
Als je DRY doordrijft, kan code moeilijker te volgen worden. Soms is het begrijpelijker om iets kort opnieuw te schrijven, zeker bij kleine scripts of eenvoudige logica.
Wanneer logica te ver verstopt zit in abstracties of helpers, moet je als ontwikkelaar vaak meerdere bestanden of lagen doorlopen om te begrijpen wat er gebeurt.
Niet iedereen begrijpt de abstractie op dezelfde manier. Te generieke oplossingen kunnen botsen met hoe andere teamleden de code lezen of uitbreiden.
Hoewel DRY een krachtig hulpmiddel is, is het slechts één van de vele principes in softwareontwikkeling. Het wordt vaak gecombineerd met andere ontwerpprincipes, maar het is belangrijk om de verschillen en raakvlakken te begrijpen.
Het Single Responsibility Principle (SRP) stelt dat een module, class of functie maar één verantwoordelijkheid of reden tot verandering mag hebben. DRY gaat over herhaling voorkomen, SRP gaat over duidelijke verantwoordelijkheden.
Hoewel verschillend, vullen deze principes elkaar aan. Als je DRY toepast zónder SRP in gedachten te houden, kun je eindigen met een grote “utility-functie” die veel te veel doet. Andersom geldt: als je SRP toepast zonder op DRY te letten, kun je eindigen met veel dubbele logica in aparte classes.
KISS is een ander populair principe dat stelt: maak het niet ingewikkelder dan nodig is. Waar DRY soms uitnodigt tot het maken van abstracties, waarschuwt KISS juist voor te veel complexiteit.
Een goede DRY-implementatie houdt ook KISS in het achterhoofd. Maar als je te vroeg DRY toepast, kun je KISS breken bijvoorbeeld door kleine, eenvoudige stukjes code te vervangen door een generieke maar moeilijk leesbare helper.
Balans is de sleutel: gebruik DRY om duplicatie te verminderen, maar houd het simpel en begrijpelijk.
Het DRY-principe klinkt eenvoudig, maar in de praktijk vereist het een doordachte aanpak. Hieronder vind je praktische tips om DRY op een effectieve manier toe te passen, zonder in de valkuil van overmatige abstractie te trappen.
Als code moeilijk te hergebruiken is, dan wordt het al snel gekopieerd. Zorg er dus voor dat functies en modules:
Goed gedocumenteerd zijn
Logische input en output hebben
Op zichzelf staan (geen verborgen afhankelijkheden)
Een herbruikbaar stuk code hoort op meerdere plekken bruikbaar te zijn zónder dat het extra complexiteit introduceert.
Zodra je duplicatie ziet, is de verleiding groot om direct te abstraheren. Maar niet alle herhaling vraagt om DRY. Soms is het beter om duplicatie tijdelijk te accepteren en pas te refactoren zodra het patroon zich blijft herhalen.
Vuistregel: komt dezelfde logica op drie plekken voor? Dan is het waarschijnlijk tijd om te abstraheren.
Wat voor jou een logische abstractie is, kan voor anderen verwarrend zijn. Communiceer dus goed binnen het team wanneer je gedeelde helpers of modules toevoegt. Zorg er ook voor dat iedereen begrijpt waarom een stuk code op een bepaalde manier is opgezet.
DRY werkt het beste in combinatie met principes zoals:
SRP voor duidelijke verantwoordelijkheden
KISS om het simpel te houden
YAGNI (You Aren’t Gonna Need It) om alleen te abstraheren als dat écht nodig is
Door deze principes te combineren, bouw je code die niet alleen herbruikbaar is, maar ook begrijpelijk en onderhoudbaar blijft.
Het DRY-principe – Don’t Repeat Yourself – helpt ontwikkelaars om duplicatie te vermijden en software overzichtelijk, betrouwbaar en schaalbaar te houden. Door logica, data en configuratie slechts op één plek te beheren, voorkom je fouten, versimpel je onderhoud en werk je efficiënter samen binnen teams.
Toch vraagt DRY om nuance. Te vroege of geforceerde abstracties kunnen juist leiden tot verwarring of onnodige complexiteit. Door DRY te combineren met andere principes zoals SRP, KISS en AHA, ontstaat er een gezonde balans tussen herbruikbaarheid en eenvoud.
Kortom: DRY is geen dogma, maar een richtlijn. Herhaal jezelf niet onnodig, maar durf soms ook even af te wijken, als dat de leesbaarheid of snelheid ten goede komt.
Don't Repeat Yourself (DRY) is een softwareprincipe dat stelt dat elk stukje logica of kennis in een systeem maar op één plek hoort te bestaan, om duplicatie te voorkomen.
Herhaling leidt tot fouten, inconsistente applicatiegedragingen en moeilijk onderhoud. DRY zorgt voor herbruikbare, overzichtelijke en foutarme code.
Te veel of te vroege abstractie kan code complex maken, slechter leesbaar en moeilijker te debuggen. DRY moet daarom met aandacht en context worden toegepast.
