Tag boeken
Objectgeoriënteerd en functioneel BTW berekenen - Revisited
Ik plaatste een tijd geleden wat kanttekeningen bij mijn aanpak Enrico Buonanno’s uitdaging om een objectgeoriënteerde BTW-calculator te schrijven. Zo zette ik mijn vraagtekens bij het feit dat ik zijn oorspronkelijke model één op één overnam. Die keuze bracht met ertoe een aparte VatCalculator-class te definiëren. En hoewel die objectgeoriënteerd was opgezet, viel deze makkelijk om te schrijven naar een functionele variant. De vraag wierp zich op: hoe objectgeoriënteerd is die oplossing? Is de vergelijking daarmee wel eerlijk? Hoe zou een “echt” objectgeoriënteerde oplossing eruit zien?
De elf rollen van variabelen
Pas wanneer de vanzelfsprekendheid van code in het geding komt, gaan we nadenken - écht nadenken - over wat er op je scherm staat en waarom. Pas dan wordt de vraag “Wat doet deze variabele hier precies?” relevant. Goed, vraag jezelf nu eens af: als dat moment komt, hoe beschrijf je de rol van een variabele dan? - Heb je enig idee waar je moet beginnen bij het beantwoorden van die vraag?
Objectgeoriënteerd en functioneel BTW berekenen
In het eerste hoofdstuk van Enrico Buonanno’s Functional Programming in C# (Second Edition) demonstreert de auteur wat functionele features van C# aan de hand van een concreet voorbeeld: het berekenen van de BTW op een (lijst) product(en). Buonanno raadt de lezer aan om dezelfde functionaliteit ook op een objectgeoriënteerde manier te implementeren, om die oplossing te kunnen contrasteren met de zijne. Dus dat is precies wat ik heb gedaan.
Zelfs de testpiramide is niet meer heilig!
Ik ben altijd in de veronderstelling geweest dat mijn geautomatiseerde tests een piramidevormige verhouding tot elkaar zouden moeten hebben: aan de basis enorm veel unittests, in het midden een goede hoeveelheid integratietests, en aan de top een bescheiden aantal end to end (E2E) tests. Totdat ik Learning Domain-Driven Design van Vlad Khononov las. (Een aanrader, overigens!)
Is kunstmatige intelligentie wel écht intelligent?
Kunstmatige intelligentie (ook wel artificiële intelligentie of kortweg AI genoemd) heeft de laatste jaren een enorme opmars gemaakt. AI neemt een steeds prominentere plek in in het dagelijks leven: van vertaalmachines tot gepersonaliseerde advertenties tot gerobotiseerde obers. Hoog tijd dus om filosofisch op dit fenomeen te reflecteren. Wat is AI? Kunnen computers echt denken? Wat is denken überhaupt? En wat zijn de ethische en politieke implicaties van de steeds grotere rol die AI in de samenleving speelt? Deze en andere vragen komen aan bod in Guido van der Knaaps Van Aristoteles tot algoritme: Filosofie van kunstmatige intelligentie.
Incidentanalyse zonder schuldigen
Wat doet jouw team na een productieverstoring? En wat doet jouw team als een eindgebruiker een bug meldt? - Wat bij een grote bug? Wat bij een kleine? Neem je het ter kennisgeving aan, en ga je op dezelfde weg door? Ga je met vingers wijzen en mensen uitfoeteren voor hun nalatigheid? Of kijk je naar manieren waarop je de productieverstoring of bug in de toekomst kunt voorkomen? En waar kijk je dan naar - naar het individu, of het systeem?
Nóg een reden om testgedreven te ontwikkelen
Als je mij zou vragen: waarom zou je testgedreven ontwikkelen? dan zou ik zeggen: zodat je tests hebt. Maar in The Art of Agile Development van James Shore vond ik een andere reden. Test-Driven Development dwingt je na te denken hoe het is een stuk code te gebruiken, in plaats van het te implementeren. Het vraagt je om helder te krijgen: hoe kan ik deze functionaliteit zo goed mogelijk ontsluiten, in plaats van: hoe kan ik deze functionalteit zo goed mogelijk bouwen?
Refactoren na Tolstoj
Laatst las ik een verhaal van Lev Tolstoj genaamd Uit de aantekeningen van vorst D. Nechljoedov. Luzern (1857), een verhaal gebaseerd op zijn ervaringen tijdens een reis door Zwitserland. Het is geschreven in dagboekvorm en gaat over een Russische vorst die een nacht verblijft in het Schweizerhof, een prachtig chique hotel in Luzern, Zwitserland. Mij deed het aan refactoren denken. - Ja sorry: beroepsdeformatie!
Tevreden ontwikkelaars én stakeholders dankzij speelruimte
Dit is denk ik voor veel teams een herkenbare situatie: de ene Sprint verbranden jullie achttien effort points, de volgende twintig, de keer daarop vijftien. Wat is dan de capaciteit van het team? Hoe kun je voorspellen wat jullie de volgende Sprint gaan opleveren, als de capaciteit fluctueert van keer tot keer? Het antwoord is: dat kun je niet. Maar in The Art of Agile Development van James Shore vond ik hier een oplossing voor.
De ontwikkelaar als chirurg
Working Effectively with Legacy Code van Michael Feathers staat vol met adviezen waar je cleancodershart een slag van overslaat. Vrijelijk raadt Feathers je aan encapsulatie uit het raam te smijten of onhandelbare methods zomaar tot class te promoveren. Zijn inzichten gaan lijnrecht in tegen alle richtlijnen om goede, onderhoudbare code te schrijven. Het boek is zonder twijfel een aanrader voor elke softwareontwikkelaar.