Dit zijn drie principes die elke ontwikkelaar zou moeten volgen, omdat ze gaan over schone code. In dit artikel gaan we begrijpen wat elk van hen betekent.

DRY Principle

DRY staat voor Don’t Repeat Yourself. In het boek ‘The Pragmatic Programmer’ zien we deze definitie voor DRY:

Elk stuk kennis moet een enkele, ondubbelzinnige, gezaghebbende representatie hebben binnen een systeem.

Dit betekent dat je geen dubbele code moet hebben. Het is gemakkelijker om code te onderhouden die maar op één plaats staat, want als je iets in de code moet veranderen, hoef je dat maar op één plaats te doen. Bovendien, als u dezelfde code op twee of meer plaatsen heeft, is de kans groot dat deze code in de loop van de tijd anders wordt, en als dit gebeurt wordt het een gemakkelijke manier om bugs in uw systeem te introduceren. Gedupliceerde code maakt de code ook complexer en onnodig groter.

Je moet ook geen dubbelzinnige code schrijven. Uw klassen, uw variabelen, uw functies, ze moeten een specifieke naam hebben, en hun naam moet overeenkomen met hun verantwoordelijkheid. Als je een functie hebt, zou je moeten weten wat de functie doet door alleen maar de naam te lezen, zonder dat je de code erbinnen hoeft te lezen.

In het boek ‘The Pragmatic Programmer’ kunnen we ook zien dat:

DRY gaat over het dupliceren van kennis, van intentie. Het gaat over het uitdrukken
van hetzelfde op twee verschillende plaatsen, mogelijk op twee totaal verschillende manieren

Het betekent dat het niet alleen over copy and past code gaat – ja, dat valt er ook onder – maar verder gaat dan dat. Het gaat ook om het hebben van verschillende code die hetzelfde doet. Misschien kun je op twee of meer plaatsen verschillende code hebben, maar ze doen hetzelfde op verschillende manieren, ook dit moet worden vermeden.

KISS Principle

KISS is een acroniem voor Keep It Simple, Stupid. Dit principe zegt over om je code eenvoudig te maken. Je moet onnodige complexiteit vermijden. Een eenvoudige code is gemakkelijker te onderhouden en gemakkelijker te begrijpen.

U kunt dit principe toepassen in het ontwerp en in de uitvoering van de code. U moet dubbele code elimineren, onnodige functies verwijderen, geen onnodige variabelen en methoden gebruiken, namen voor variabelen en methoden gebruiken die zinvol zijn en overeenkomen met hun verantwoordelijkheden, en altijd als het mogelijk is, de bekende normen voor code-ontwikkeling volgen. U moet ook de verantwoordelijkheden van uw klassen en de verantwoordelijkheden van de lagen van het project scheiden.

Soms hoeft u niet iets nieuws te implementeren om uw behoeften bij te wonen, kunt u gewoon gebruik maken van de functies van de programmeertaal die u gebruikt. Daarvoor is het goed dat je de mogelijkheden kent van de programmeertaal waarmee je werkt.

Als je in een code werkt die al is geïmplementeerd, en je ziet iets dat niet nodig is of eenvoudiger kan, dan moet je overwegen om het te refactoren.

YAGNI Principle

YAGNI staat voor You Ain’t Gonna Need It. Het is een principe uit de softwareontwikkelingsmethodologie van Extreme Programming (XP). Dit principe zegt dat je geen functies moet maken die niet echt nodig zijn.

Dit principe lijkt op het KISS-principe, omdat ze allebei streven naar een eenvoudiger oplossing. Het verschil tussen beide is dat YAGNI zich richt op het verwijderen van onnodige functionaliteit en logica, en KISS zich richt op de complexiteit.

Ron Jeffries, een van de medeoprichters van XP, heeft ooit gezegd:

Implementeer altijd dingen wanneer je ze daadwerkelijk nodig hebt, nooit wanneer je alleen maar voorziet dat je ze nodig hebt.

Dit betekent dat je functionaliteit niet moet implementeren alleen omdat je denkt dat je die ooit nodig zult hebben, maar pas als je die echt nodig hebt. Als je dat doet, voorkom je dat je tijd kwijt bent aan implementaties die niet eens nodig waren, en misschien wel nooit gebruikt zullen worden.

Conclusie

Als je deze principes volgt, zul je betere code kunnen schrijven. Vergeet niet dat een schone code is makkelijker te main, gemakkelijker te begrijpen en zeker zal het bespaart u tijd wanneer u nodig hebt om iets te wijzigen of te implementeren. Vermijd het gebruik van dubbele code, probeer uw code zo eenvoudig mogelijk te houden, en implementeer alleen functies wanneer het echt nodig is.