Tag leermoment
Wat is een monad?
Wat is een monad, vraag je? Simpel: monaden zijn de meest fundamentele zijnden in het universum - ondeelbaar, onafhankelijk, zowel geestelijk als lichamelijk - de bouwblokken van de werkelijkheid, die tezamen een door God geschapen harmonieus geheel vormen - overigens zonder elkaar te beïnvloeden; het zijn perfect op elkaar afgestemde atomen die in autonoom opereren maar in hun zijn het voltallige universum spiegelen. Althans, dat is wat Gottfried Wilhelm Leibniz onder “monaden” verstond. Maar dit is nu eenmaal een blog over softwareontwikkeling, dus je zal wel dat functionele spul bedoelen.
Test het systeem, niet de class
Het is belangrijk om vast te stellen dat er een bug in het systeem was geslopen, ondanks dat de functionaliteit die de bug veroorzaakte ogenschijnlijk gedekt was door tests. Waarom “ogenschijnlijk”? De class die de serialisatie voor zijn rekening nam, werd wel getest, maar alleen in isolatie en niet in de context van het systeem. - Vraag je af wat de implicatie daarvan is. Het betekent dat onze tests bewezen dat een class naar behoren werkt. Of het systeem als geheel naar behoren werkt, dat kunnen we op basis van de tests niet concluderen. Terwijl dat juist is waar het om gaat!
De fix die productie om zeep hielp
“De fix staat op productie,” meldden we trots. “Het bleek te liggen aan wat validatielogica die in dit specifieke scenario wat te streng bleek - enfin, een technisch verhaal, dat hoef je niet te weten. Het enige wat je hoeft te weten is: we hebben weer eens geweldig werk geleverd, bedankjes worden gewaardeerd maar zijn niet noodzakelijk.” En we leefden nog lang en gelukkig. Een halfuur lang. Want toen kregen we een berichtje: “Help! Ik kan nu geen enkel item meer inzien!”
Horizontale en verticale architectuur
Als we onze applicatie verticaal op zouden hakken, dan zouden we af kunnen komen van onze ongemakkelijke naamgevingsconventies. Elke slice zou zijn eigen project krijgen, en elk project zijn eigen model. Of het nu over items in isolatie gaat, of items in een toets, of items in een itembank - we zouden in de code altijd over Item
kunnen spreken - net als de gebruiker.
Wat is een functor?
Wat is een functor, vraag je? Lang verhaal kort: functors zijn typen die een Map
-functie implementeren. Wat is een Map
-functie, vraag je? Lang verhaal kort: ken je LINQ? - heb je wel eens Select
gebruikt? - nou, dat dus. Maar misschien loont het zich er nét iets langer bij stil te staan.
Spelen met Options
Options vormen de brug tussen totale en gedeeltelijke functies. Het is een type dat de eigenlijke return value van een functie wrapt. In het geval dat de mapping zinvol is, dan geeft de functie een Option terug met daarin de gezochte waarde. En als de mapping dat niet is, dan geeft deze een Option terug zónder die waarde. Wat het resultaat dus ook is, één ding weet je zeker: je krijgt een Option terug. De functie is altijd eerlijk.
De Grote Successenretro was een groot succes
Onze Scrummaster was er niet, en dus kwam het organiseren van de Sprint Retrospective op mijn bordje terecht. Omdat ik iets spannenders wilde organiseren dan een wat-ging-er-goed-en-wat-kon-er-beter-Retro (dat is de officiële term, toch?), nam ik een middag de tijd om verschillende vormen te bekijken. Voor de uiteindelijke opzet, putte ik inspiratie uit de cursus begeleidend coachen die ik de afgelopen maanden heb gevolgd. Eén van de belangrijkste lessen die ik heb getrokken uit die cursus, is de waarde van het focussen op successen. Wie oog heeft voor zijn eigen successen (of de successen van zijn/haar team), wie zijn eigen successen erkent en viert, opent de weg naar meer succes.
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!)
De ontdekking van strategische subdomeinen
Ik schreef één keer eerder over Domain-Driven Design - en in die blog gaf ik onmiddellijk toe niks van het onderwerp te weten. Precies daarom nam ik me voor om Learning Domain-Driven Design van Vlad Khononov op te pakken. En met succes, want al meteen in het eerste hoofdstuk leerde ik iets nieuws: het bestaan van strategische subdomeinen.
Het probleem met technische schuld op je backlog
Zo gaat mijn team om met het monitoren van technische schuld: we prikken elke Sprint een moment waarop we er met elkaar over praten, en als we het belangrijk genoeg vinden om er wat aan te doen, dan voeren we een Product Backlog Item op om die schuld weg te werken. Die aanpak werkt goed - goed genoeg, in elk geval. De technische schuld van onze huidige applicatie blijft grotendeels binnen de perken. En bovendien - dat is nog veel belangrijker - is iedereen in het team op de hoogte van het feit dat sommige plekken verbetering behoeven, en welke plekken dat zijn. Maar toch zit iets me niet helemaal lekker in die aanpak.