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.
Functioneel denken: een praktijkvoorbeeld
Onlangs hielp ik een collega een moeilijk volgbare berg code te reduceren tot enkele eenvoudig leesbare regels. Door onze oorspronkelijke, imperatieve redeneertrant van ons af te werpen, en deze te vervangen door een declaratieve stijl, reduceerden we het netelige origineel tot een elegante functionele oplossing. – Het was een schoolvoorbeeld van de kracht van functioneel denken.
Technieken vs trucjes
Een goede programmeur is een luie programmeur – dat is een bekende wijsheid in softwareontwikkelland. Want: een luie programmeur automatiseert oninteressante, repetitieve taken, en creëert op die manier de ruimte om zich bezig te houden met interessante, afwisselende taken. – Althans, dat is één opvatting van wat het betekent om een luie programmeur te zijn. Maar er zijn nog veel meer manieren om lui te zijn. Vandaag wil ik het hebben over zo’n andere manier. Vandaag wil ik het hebben over de wens, behoefte of neiging om een techniek te reduceren tot een trucje.
Een oudergesprek
Onlangs mocht ik op mijn oude universiteit jonge studenten (en hun ouders) geruststellen: het is goed mogelijk een leuke en uitdagende baan te bemachtigen met een studie filosofie. Na afloop had ik een leuk gesprek met een Steve Jobs-lookalike – een vader, geen student –, die me vertelde dat ook hij overwoog om te leren programmeren. Hij zei wat iedereen zegt die overweegt te leren programmeren: “Ik heb het altijd leuk gevonden om dingen uit elkaar te halen om te kijken hoe ze werken.” – En ik besefte me opeens: ik heb dat totaal niet.
Waarom testen testers?
Tijdens een Retrospective gaf onze tester aan dat hij omkwam in het werk. Eigenlijk verbaasde niemand dat. Ons team bestaat uit vijf ontwikkelaars en één tester, en die ene tester is verantwoordelijk voor het schrijven van geautomatiseerde tests voor de code van al die vijf ontwikkelaars. Je kunt op je vingers natellen dat die situatie niet houdbaar is. – Dus wat te doen?