+31 (0) 53 30 33 600

Hoe realiseer je kwalitatief goede code

 – Schrijf simpele code units  (‘Write simple units of code’)

- Blog 7 - 

Kwalitatief goede software voorkomt hoge kosten voor onderhoud en aanpassingen, performance problemen, downtime, gegevensverlies en imagoschade. Vandaar dat we bij OVSoftware garant staan voor de goede kwaliteit van de softwarecode die we opleveren. Dit doen we onder andere door bij de ontwikkeling van maatwerk softwareoplossingen, de tien richtlijnen voor codekwaliteit van de Software Improvement Group (SIG) toe te passen. In een serie van tien blogs leggen onze IT-specialisten uit wat deze richtlijnen zijn, hoe zij developers ondersteunen bij het schrijven van code en welke voordelen ze opleveren voor de klant.

‘Write simple units of code’ – wat houdt dat in?
Hoe beoordeel je of een codebase simpel is of complex? Een stuk code kan voor een buitenstaander of iemand die net als developer begint heel ingewikkeld lijken. Voor de ontwikkelaar van deze code of een heel ervaren persoon is het waarschijnlijk prima te volgen. Of iets simpel of complex is, is dus subjectief. Toch is er een punt waarop een stuk code zo complex is, dat het doorvoeren en testen van aanpassingen risicovol en tijdrovend wordt. Daarom wil je complexiteit meetbaar maken. Een van de manieren waarop je dit kunt doen, is met de eerder beschreven SIG-richtlijn: ‘Schrijf kleine functies’. Deze richtlijn schrijft voor dat elke methode (een aantal regels code dat ervoor zorgt dat een actie wordt uitgevoerd) maximaal 15 regels code bevat. Een andere manier om objectief te bepalen hoe ingewikkeld de code al dan niet is, is door te kijken hoeveel ontwikkelpaden (beslisbomen voor uiteenlopende scenario’s) een methode bevat. Een ontwikkelpad begint op een zogenaamd branch point waarbij je door gebruik te maken van bijvoorbeeld een ‘IF’, ‘OR’ of ‘AND’  statement verschillende wegen kunt bewandelen. Bijvoorbeeld: IF leeftijd is >18 dan gebeurt X, anders Y. Of een ‘OR’ statement: IF leeftijd >18 OR leeftijd ==55 (gelijk aan 55)…. etc. De uitkomst van het statement bepaalt welke kant je opgaat op een branch point. Door het aantal branch points te beperken tot vier per methode, weet je zeker dat je methodes overzichtelijk blijven.

Murat Yilmaz

Meer informatie? Neem contact met mij op!



De richtlijn toegepast in de praktijk 

De richtlijn is dus om simpele code units te schrijven door je te houden aan een maximaal aantal van vier branch points per methode. Als je nieuwe code aan het schrijven bent, dan hou je continu in de gaten dat je dit aantal niet overschrijdt. Heb je toch meer dan vier branche points nodig, dan maak je een nieuwe methode aan waar je één of meerdere extra branch points in onderbrengt. De naam van de methode geeft aan welke actie wordt uitgevoerd, hierdoor is de opbouw van de code voor iedereen goed te volgen. Daarom is het belangrijk dat de code die je onderbrengt in een methode altijd past binnen de uit te voeren actie van die methode. Werk je aan verbeteringen van bestaande code en zie je dat er sprake is van te veel branch points per methode, dan ga je op dezelfde manier te werk door het teveel aan branch points onder te brengen in een nieuwe methode.


Zo helpt de richtlijn mij als ontwikkelaar
In mijn werk maak ik dagelijks gebruik van de tien SIG-richtlijnen. Net als verschillende andere richtlijnen zorgt de richtlijn om simpele code units te schrijven ervoor dat de code makkelijker te begrijpen, aan te passen en te testen is. Mede doordat je niet meer dan vier branch points in één methode kwijt kunt, blijven de methodes klein. Bovendien kun je aan de naam van de methode precies zien wat deze in de praktijk moet doen. Wil je wat aanpassen aan je code dan is het veel makkelijker om een groot aantal kleine, duidelijk beschreven methodes te doorzoeken dan een hele grote ‘blop’ code. Het is sneller te doorzien waar aanpassingen nodig zijn en ook het testen van aangepaste code kost zo minder tijd en moeite.

Dit levert de richtlijn op voor de klant 
De richtlijnen van de SIG dragen bij aan code van hoge kwaliteit waardoor je deze beter kunt onderhouden. Eenvoudige, goede code betekent dat ik als developer minder tijd kwijt ben aan het zoeken, doorgronden, aanpassen en testen ervan. Het zorgen voor een kwalitatief goede codebase betekent dat je gedurende de hele levensloop van de ontwikkelde software profiteert van de voordelen. Minder bugs, minder downtime, snel kunnen doorvoeren en testen van correcties en aanvullingen. En hoe minder tijd developers aan dit soort zaken besteden, hoe minder het de opdrachtgever kost.


Over de auteur
Murat heeft in 2019 zijn Bachelor’s degree in Computer Software Engineering behaald aan de Haagse Hogeschool in Zoetermeer. Zijn afstudeeropdracht heeft hij succesvol uitgevoerd bij OVSoftware, waar hij na zijn afstuderen fulltime aan de slag is gegaan. De afgelopen periode heeft hij gewerkt aan een diversiteit aan opdrachten die bijdragen aan zijn allround inzetbaarheid bij klanten. Uiteindelijk wil hij zich gaan specialiseren in artificial Intelligence en blockchain omdat dit naar zijn idee boeiende materie is en technologieën van de toekomst.

Contact

Wil je meer informatie over OVSoftware?
Neem dan contact op.

Werken bij OVSoftware

Wil je meer weten over onze bedrijfscultuur en vacatures?
Bekijk dan onze werken bij pagina

Branches

Wil je meer weten over de branches waarbinnen OVSoftware actief is?
Bekijk de branches.

Referenties & Projecten

Lees hier klantreferenties en door OVSoftware begeleide lopende en afgeronde projecten waar wij trots op zijn.

Over ons

OVSoftware is één van de eerste softwarebedrijven van Nederland.
Lees meer over ons.

Volg ons op