feb

Ik ken een collega-developer wiens persoonlijke mantra was: “Mijn code leest als een goed boek”. Hoewel er zeker overeenkomsten zijn, vereist het schrijven van software ook andere vaardigheden en een speciale mindset. Een kwaliteit van een goede software developer is dat hij beknopt schrijft. Goede computercode is doelgericht, kort en bondig, to the point.

Als ik een boek lees vind ik het fijn wanneer het verhaal geleidelijk wordt opgebouwd. Elke bladzijde, elk hoofdstuk onthult nieuwe elementen en een deel van de verhaallijnen borduurt daarop voort. Een beetje herhaling helpt het verhaal in te prenten. Het verhaal ontrafelt zich naar mate je verder leest. Je nieuwsgierigheid naar het verloop blijft geprikkeld.

Een andere manier van schrijven
Code schrijven vergt echter een andere aanpak. Het maakt een computer niet uit hoe spannend een stuk code is, het heeft geen emoties. Zolang de commando’s kloppen, wordt prima begrepen wat de bedoeling is. Een computer klaagt niet wanneer de ontwikkelaar geen prachtige volzinnen gebruikt. Integendeel, “volzinnen” in code, maken de software log. Het zorgt ervoor dat de computer er meer moeite mee heeft. Het programma verbruikt meer geheugen en het zorgt voor een langzamere uitvoering. Bij programmeren draait alles om efficiency, niet om de psyche van een computer.

Daarnaast houdt een computer niet van dubbel geschreven code. Als developer leer je structuren op die manier te bekijken. Je focust je op het schrijven van duidelijke, kleine, functionele blokken, die maar één doel hebben. Die blokken gebruik je waar je ze nodig hebt, in plaats van jezelf te herhalen en hetzelfde stuk, misschien nét ietsje anders, nog een keer te schrijven. Een goed codeblok vervult een simpele rol en die schrijf je zelden meer dan één keer in de broncode van je programma. Repeterende code is meer werk voor de developer, meer werk voor de computer en vergroot de kans op fouten. Houd je aan de KISS en DRY-principes: Keep it simple, stupid. Don’t repeat yourself.

Voor code schrijven heb je een glazen bol nodig
Het grootste verschil tussen het schrijven van proza en een computerprogramma is het verloop van het verhaal. Een computerprogramma heeft niet één enkel begin en einde. Het verloop van een computerprogramma kan veranderen door een eerdere, of gelijktijdige uitvoering van datzelfde computerprogramma. Het verloop van een boek blijft hetzelfde ongeacht hoe vaak je het leest en hoeveel mensen het tegelijkertijd aan het lezen zijn.

Na het schrijven van het laatste hoofdstuk is het boek af en kan het gedrukt worden. Een computerprogramma start pas nadat zijn verhaal, de code, is geschreven. Voor een spannende thriller is het soms goed wanneer een personage op een bloederige manier aan zijn einde komt, in softwareontwikkeling wil je dat juist voorkomen. Daarom moet je als developer een glazen bol hebben en een beetje denken als een jurist, met oog voor de kleinste details.

Voor ieder mogelijk toekomstig scenario moet er bedacht worden waar je programma mee te maken krijgt, zoals onjuiste invoer of het abrupt onderbreken van een proces door een storing. Je moet kunnen voorspellen op welke manier dingen “niet volgens de regels” gaan. Jouw geschreven code moet kunnen constateren wanneer de uitvoering van het rechte pad, de zogenaamde “happy flow”, afraakt. Oog voor detail is daarbij cruciaal. Wanneer een afwijkende situatie zich voordoet, moet je programmatuur een oplossing kunnen bieden of anderzijds een straf uitdelen in de vorm van een foutmelding of zelfs een crash van het programma.

Deze “straf” is geen persoonlijke vendetta maar een doelbewuste keuze van de developer om te voorkomen dat de situatie uit de hand loopt en in een bloedbad eindigt. Toch zijn er weinig mensen die deze keuze op prijs stellen wanneer ze door een foutmelding niet verder kunnen werken.

Probeer je de chaos voor te stellen die ontstaat als het programma niet zou stoppen. De developer ziet deze scenario’s al voor zich voordat ze zich voltrekken. Die glazen bol zou het werk van de developer een stuk vereenvoudigen, zolang het maar geen matglas is. Rest mij nu om dit blog af te sluiten in de stijl van een goede developer: niet bloederig, kort en bondig, to the point.