Waarom je wilt sturen op clean code.

Mooie code, wat heeft de klant daar aan? Daar zie ik toch niets van in de applicatie? Als het maar werkt, hoe die code er uitziet boeit toch niet? Daar betaal ik toch niet extra voor? Zomaar een paar vragen die kunnen spelen als het gaat om clean code. Wij zijn ervan overtuigd dat het wél belangrijk is. Zowel vanuit het perspectief van de klant als van de ontwikkelaar.

Harm-Jan Hazelhorst Lead developer
Harm-Jan Hazelhorst, Lead developer bij CODE14

Wat is clean code?

Een softwareapplicatie maak je in code. Als softwareontwikkelaar ben je een groot deel van de tijd bezig met deze code. Je bouwt er dingen bij, je past dingen aan en soms haal je dingen weg. Doordat je continue in die code bezig bent veranderd die code veel. Meestal werk je met meerdere ontwikkelaars aan een project. Dan gaan de veranderingen in de codebase nog veel sneller. Ieder mens heeft z’n eigen manier van schrijven. Of het nu gaat om het schrijven van een blogpost, boek of softwarecode, iedereen heeft z’n eigen stijl. Vaak vind je je eigen stijl een goede stijl. Dat is nu eenmaal hoe mensen zijn. In de ontwikkeling van software zie je dit ook terug. Met name als je met meerdere mensen aan een project werkt dan zie je, als je ’t niet reguleert, meerdere stijlen van schrijven van code door elkaar. Na verloop van tijd is de codebase een grote mix van stijlen geworden. Dit is niet overzichtelijk en niet intuïtief. Clean code is code waarin je de verschillende stijlen van de auteurs niet ziet. Dit klinkt simpel maar probeer maar eens een boek te schrijven met een team zonder dat je weet wie welk hoofdstuk geschreven heeft!

Waarom besteden wij hier aandacht aan?

Hoe vervelend is het om een boek te lezen met meerdere stijlen van schrijven door elkaar? Ditzelfde geldt voor software. Als ontwikkelaar ben je de hele dag bezig met die code. Als die code geschreven is op een manier zoals jij het niet zou doen dan beïnvloedt dat je werk in het project. Het voelt niet eigen. Je voelt je niet thuis. Als ontwikkelaar moet je je thuis voelen in de codebase. Op het moment dat je je thuis voelt dan weet je intuïtief ook wat waar gebeurt in de applicatie. Veel mensen zijn ‘bang’ voor software. Omdat je niet kunt doorgronden wat waar gebeurt is het lastig om iets aan te passen omdat het zomaar zou kunnen zijn dat je collega iets gebouwd heeft dat op, voor je gevoel, magische wijze de werking beïnvloedt. Als iedereen de code op dezelfde manier schrijft is de kans op dit soort magische bijwerkingen een stuk kleiner! Daardoor wordt de kans op fouten in de software ook kleiner. Tenslotte willen we allemaal, zowel als klant of ontwikkelaar, dat we werkende software bouwen.

Hoe doen wij dat?

Afspraken en discipline. Dat zijn volgens ons de twee toverwoorden als het gaat om clean code. Code moet overzichtelijk en intuïtief zijn. Daarom hebben wij afspraken gemaakt over architectuur, naamgeving, schrijfstijl, workflow etc. Voor elke onderdeel in een functionaliteit hebben we afspraken hoe we de betreffende classes en methods noemen. Zo noemen we de eerste keer toevoegen altijd ‘store’. Dus niet ‘create’, ‘make’, ‘save’ of nog niets anders, we hebben afspraken gemaakt dat het ‘store’ moet zijn. Doordat iedereen dat hanteert weet je waar je iets kunt vinden. Iedere ontwikkelaar binnen ons team dient zich daar ook aan te houden. Dit controleren we door middel van merge-requests. Als een ontwikkelaar een functionaliteit gemaakt heeft wordt dit gecontroleerd door een van de andere ontwikkelaars. Die controleert alles allereerst of het naar behoren functioneert maar ook of de ontwikkelaar zich aan de afspraken gehouden heeft wat betreft de code.

Meld je aan voor onze nieuwsbrief en krijg artikelen, projecten en bedrijfsupdates rechtstreeks in je inbox.