Waarom is schone code belangrijk?
Als je 10 developers vraagt wat ‘goede code’ is, krijg je 10 verschillende antwoorden. Daarom vonden wij het belangrijk om deze discussie binnen Blis te voeren en samen tot een idee van ‘goede code’ te komen. Toen we allemaal het boek gelezen hadden, planden we een aantal avondbijeenkomsten om het erover te hebben.
Maar wat maakt schone code goede code? En wat is ‘schone code’ eigenlijk? Code is schoon als hij voor iedereen leesbaar is. Als developer duik je vaak diep in de uitdaging die voor je ligt. Je bent volledig geconcentreerd op het realiseren van je oplossing en je bent blij en trots als je het werkend krijgt. Maar werkende code is niet je enige verantwoordelijkheid. Je code gaat deel uitmaken van een applicatie die kritieke bedrijfsprocessen ondersteunt en moet daarom goed te onderhouden en snel aan te passen zijn. Ook door iemand die er niet bij was toen hij geschreven werd.
Dat betekent dat een developer die over een jaar naar jouw code kijkt makkelijk moet kunnen begrijpen wat jij gedaan hebt en waarom. Om dat te bereiken volgt clean code consistente conventies en gebruikt hij duidelijke taal. Een developer die een bug moet oplossen, zal dus veel sneller kunnen zien waar het misgaat. Maar je maakt met schone code ook minder bugs, omdat het makkelijker te zien is hoe de verschillende delen van de code samenhangen en samenwerken.
Wat ons betreft is schone code dus de hoeksteen van elk goed softwareontwikkelingsproces.
Een gemeenschappelijke taal
Het boek van Robert bestaat uit 3 delen. In het eerste deel legt hij uit wat hij bedoelt met clean code. Hij gaat in op naamgeving, het schrijven van logische error handling en het formatteren van je code. Het tweede deel staat vol case studies en oefeningen. In het derde deel vat hij de geleerde lessen samen en geeft je als developer de kennis en technieken die je nodig hebt om aan code te ‘ruiken’ of hij goed geschreven is.
De kern en het bestaansrecht van het boek worden goed samengevat in deze quote:
“The ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code.”
Klopt helemaal. Als developer ben je continu oude code aan het lezen om uit te vinden waar je aanpassingen moet doen, hoe je functionaliteit het beste kunt toevoegen en hoe je bugs kunt oplossen. En je kunt met slordige code dus heus wel een product of feature werkend en live krijgen, maar in de tijd daarna verdwaal je in je eigen rommel. Het schrijven van schone code bespaart je dus veel tijd, frustratie, fouten en – uiteindelijk – geld.
In zijn boek noemt Robert een aantal principes voor leesbare, heldere code. De belangrijkste is dat je allemaal een gezamenlijke taal spreekt. En dan heb ik het niet over de programmeertaal, maar over een set met werkafspraken binnen die taal. Als iedereen zich consequent aan dezelfde principes houdt, weet je altijd de weg in elkaars code. Dat maakt aanpassen en onderhouden veel makkelijker.
Het belang van kennisdeling
Door samen na te denken over de cases en ideeën uit het boek, kwamen we – onder het genot van pizza en een drankje – tot leuke en vruchtbare discussies. We daagden elkaar uit om te vertellen wat ons was opgevallen in het boek, of er dingen in stonden waar we het niet mee eens waren en welke dingen uit het boek we graag binnen Blis Digital in de praktijk wilden brengen.
Om maar met dat laatste te beginnen: we merkten al snel dat junior developers wel graag schone code wíllen schrijven, maar niet precies weten (of kunnen vinden) wat de regels daarvoor zijn. Meer ervaren developers kennen die regels veelal ‘uit de overlevering’ en passen ze ‘op gevoel’ toe. We besloten dus om meer te gaan doen aan kennisoverdracht tussen junior en senior developers. Niet door dikke handboeken te gaan schrijven, maar door vaker samen aan tafel en achter een monitor te zitten. Dat zal ons ook helpen bij het verder standaardiseren van onze code-conventies en het dus leesbaarder maken van onze code.
Jezelf blijven uitdagen
We zijn het trouwens lang niet met alles uit het boek eens. Ten eerste is het al een jaar of 14 oud en op verschillende punten is er voortschrijdend inzicht. Ten tweede heeft Martin een hele strikte zwart-wit visie op de zaak. Hier bij Blis zijn we wat pragmatischer en kiezen we bijvoorbeeld voor kleine projecten een iets minder streng regime van codestandaarden. Maar de visie van Martin, namelijk dat software nooit af is en dat je altijd moet blijven werken om hem beter te maken, daar staan wij 100% achter. En tijdens dat werk groei je als mens, als professional en als bedrijf ook. Omdat je jezelf continu uitdaagt om het beter te doen.
De IJzeren Driehoek
Wat de grootste uitdaging is bij het schrijven van goede code, daar hoeven de meeste developers niet lang over na te denken: tijd. De ‘ijzeren driehoek’ van projectmanagement zien we terug in codekwaliteit: budget en beschikbare uren zijn voor het gevoel van veel developers vaak te krap om de code echt clean te maken. Een voorbeeld daarvan kwam ook langs toen we het over software-onderhoud hadden. De belangrijkste KPI daarbij is hoeveel issues er zijn opgelost. Maar je kunt een issue in 20 uur of in 40 uur oplossen. In dat eerste geval heb je werkende code die niet per se lekker leesbaar is. Wij, als developers, moeten dus beter leren uitleggen waarom je wél die extra tijd moet nemen.
Inspiratie voor het nieuwe jaar
We organiseren bij Blis Digital vaker dit soort avonden. Omdat het leuk is. En omdat we elkaar graag beter leren kennen. Maar vooral omdat we merken dat het delen van kennis, ervaring en inzichten ons helpt om betere software te maken. We hebben elkaar tijdens deze avonden weer van genoeg inspiratie voorzien en we gaan in het komende jaar dus weer aan het werk om nog slimmer software bouwen. Want code die ‘werkt’ is gewoon niet goed genoeg. Code is pas goed als iedereen die eraan werkt hem begrijpt.
