+31 (0) 53 30 33 600

Hoe realiseer je kwalitatief goede code

  – Zorg ervoor dat code leesbaar is   

(‘Write clean code’) – 

– Blog 10 – 

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 clean code’ – wat houdt dat in?
Het schrijven van ‘clean code’ gaat voornamelijk over leesbare code, maar dat is niet de essentie waar het hier over gaat. Waar men op doelt, is dat je ongebruikte code zoveel mogelijk verwijdert. Ballast weghalen als het ware. Van het overgrote deel van de code die je schrijft, moet elke andere developer zonder verdere uitleg kunnen zien wat het doet. Maar soms zijn er complexe stukken code waar uitleg in de vorm van ‘comments’ bij nodig is. Op zich is dat geen probleem, maar commentaren die op enig moment geen waarde meer toevoegen moet je weghalen omdat ze de code anders onnodig vervuilen. Neem bijvoorbeeld de veelvuldig geplaatste opmerking “hier moet ik nog wat mee, want dit werkt niet”. Op het moment dat deze aantekening wordt gemaakt is het een relevante opmerking waar nog iets mee moet gebeuren, maar zodra het probleem is opgelost moet je niet vergeten om het weg te halen.

Emil Cristen

Meer informatie? Neem contact met mij op!


De richtlijn toegepast in de praktijk
Padvinders hebben een regel die erop neerkomt dat ze hun kampeerplek schoner achterlaten dan dat ze deze hebben gevonden. Datzelfde geldt voor software developers die de regel van leesbare code naleven: telkens wanneer je ergens een stuk code aanpast, heb je de mogelijkheid om tegelijkertijd kleine verbeteringen op andere plekken in die code door te voeren. Stel je voert een aanpassing door in de code of een bestand en ziet dat een bepaalde functie op een andere plek ook slimmer, beter of efficiënter kan. Je hebt deze code nu toch onderhanden, dan kun je deze verbeteringen zonder al te veel moeite gelijk meepakken. Laat je het zitten dan krijg je vervuiling van je systeem en dat is nou precies wat je níet wilt.

 


Manieren waarop je de kwaliteit van de code optimaliseert zijn bijvoorbeeld:

  • waar mogelijk geen commentaar achterlaten in code, alleen als het echt niet anders kan.
  • voorkomen dat je code in comments laat staan. Oude versies van herschreven code worden vaak tijdelijk vastgelegd in de vorm van comments, maar zodra de herschreven code in gebruik wordt genomen, kun je de comments verwijderen. Alle versies van de code worden namelijk ook vastgelegd in het versiebeheersysteem, dus kunnen te allen tijde worden bekeken.
  • ervoor zorgen dat je zogenaamde ‘dode code’ die niet meer wordt gebruikt, uit het systeem verwijdert.
  • altijd duidelijke namen voor je componenten en formules en dergelijke gebruiken zodat voor iedereen direct duidelijk is wat ze doen.

 
Zo helpt de richtlijn mij als ontwikkelaar
Het is voor mij een hele bewuste keuze om naast mijn functie als CTO ook als ontwikkelaar actief te blijven. Ik wil mezelf blijven ontwikkelen en bijhouden wat er om mij heen gebeurt in de wereld. Dat betekent niet dat ik mij met elk detail ga bemoeien, maar ik wil wel weten wat er speelt en wat het op hoofdlijnen betekent. Datzelfde geldt bijvoorbeeld ook voor de richtlijnen van de SIG. In mijn rol als developer ben ik continu alert op mogelijkheden om de door mij of door anderen geschreven code verder te optimaliseren. Bijvoorbeeld door de eerder genoemde ‘dode code’ weg te halen. Mijn ervaring leert dat juist deze loze code ervoor zorgt dat ik op het verkeerde been word gezet. Dode  code dient uiteindelijk nergens meer voor, dus elke minuut die je daaraan besteedt, is er een te veel. Door deze ballast structureel weg te halen, voorkom ik tijdverspilling op een later moment.


Dit levert de richtlijn op voor de klant
Leesbare code zorgt ervoor dat deze eenvoudig overdraagbaar is aan collega’s. Als opdrachtgever ben je dan niet meer enkel aangewezen op die één of twee specifieke personen die ooit aan de wieg hebben gestaan van een bepaald softwaresysteem. In principe is de code namelijk zo duidelijk dat iedereen er in korte tijd mee aan de slag kan. Aangezien er in de meeste organisaties en bedrijven regelmatig sprake is van een veranderende teamsamenstelling, levert deze richtlijn dus vooral een bijdrage aan de continuïteit van processen en daarmee indirect ook aan de continuïteit van je bedrijf.


Over de auteur
Emil heeft zijn IT-kennis en kunde opgebouwd bij uiteenlopende bedrijven in diverse functies en is sinds 2019 als IT professional betrokken bij OVSoftware. Vanaf februari 2020 vervult hij daarnaast ook de rol van CTO, waarbij hij nauw betrokken wil blijven bij de uitvoer van software development projecten die het bedrijf voor klanten uitvoert. Emil beschikt naast technische skills over veel affiniteit met de business waardoor hij voor opdrachtgevers eenvoudig de link tussen beide kan maken.

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