Profielfoto
Karl van Heijster

softwareontwikkelaar · filosoof · spreker

Een goede ontwikkelaar begrijpt eerst het probleem

Een softwareontwikkelaar is niet iemand die code schrijft. Iemand die slechts dat doet, kan, ondanks al zijn inspanningen, van geen enkele toegevoegde waarde zijn. Want uiteindelijk gaat het niet om de code. Het gaat niet om de code, zelfs niet als die code precies doet wat er gevraagd wordt. – Software ontwikkelen gaat om het oplossen van problemen.

Goede code is geteste code

Goede code is geteste code. Het is testbare code, zeker – en er zijn tests die het bewijzen. Als er geen tests zijn, dan is het geen goede code. – De vraag hier is natuurlijk: wat is goede code, wat betekent “goede code”? Is het code die doet wat het moet doen? Die netjes gestructureerd is? Die er goed uitziet?

Grote refactorslagen ondermijnen vertrouwen

Wat een stakeholder betreft is een grote refactorslag een enorme kostenpost zonder aantoonbaar resultaat. Een team dat erop staat niet verder te kunnen werken zonder eerst een hele tijd heel veel geld uit te geven – nota bene zonder daar iets voor terug te geven! –, ondermijnt het vertrouwen dat de stakeholder hen daarmee geeft.

Imperatieve Options?

Ik gebruik Options graag, ze voorkomen een hoop foutmeldingen. Maar, belangrijker nog, ze maken mijn code expressiever en eleganter. Of liever: ze hebben de potentie dat te doen. Laatst kwam ik tijdens een codereview een functie tegen, waarop mijn primaire reactie was: dit moet anders. – Maar waarom?

Testen is als flossen

Code unittesten is als je tanden flossen: de meeste mensen doen het niet, en als ze het doen, doen ze het op het verkeerde moment.

De ontologie van immutability

Het gebruik van immutable datastructuren maak je code veiliger, eenvoudiger en beter onderhoudbaar. Toch voelt het voor de meesten van ons vreemd, een totaal nieuw object te instantiëren wanneer één property wijzigt. – Waarom?

Een slaapliedje

Slaap, draadje, slaap, / daar buiten loopt een schaap / een millisec. of honderd. / Maar jij slaapt er vijfhonderd. / Slaap, draadje, slaap, / daar buiten loopt een schaap.

Immutability en het Single-Responsibility Principe

Het correct – en dus volledig – instantiëren van een object is één verantwoordelijkheid. Het geïnstantieerde object gebruiken is een andere. Wie beide met elkaar vermengt, schrijft onnodig complexe code. Dat is waarom we er naar moeten streven onze objecten nooit aan te willen passen.

Leren door het te doen?

Onlangs had ik een sollicitatiegesprek – ik bedoel: ik had een gesprek met een junior ontwikkelaar die bij ons kwam solliciteren. Ik stelde een vraag die ik elke sollicitant stel: hoe leer je? Ze gaf het antwoord dat elke sollicitant tot nog toe heeft gegeven: door het te doen. De cynicus in mij vertaalt dat naar: ik doe maar wat. Maar een realistischer vertaling is waarschijnlijk: ik heb er nog nooit echt over nagedacht.