Twee kinderrijmpjes
De wekker van de hacker ging om zes uur. / Het mannetje had ‘n plannetje, // hij hackte de ef-bi-aai, heel fraai / met geen phishingmail teveel…
Aantekeningen over requirements - deel 2
Het opstellen van de juiste requirements is één van de moeilijkste onderdelen van softwareontwikkeling. In een eerdere blog beschreef ik de eerste acht lessen die Karl Wiegers of dit onderwerp formuleerde in Software Development Pearls. In deze blog volgen de tweede acht.
ForEach, Aggregate en Select
ForEach gebruik je alleen als je een Action - zonder return value! - uit wil voeren voor elke lijstwaarde. Select gebruik je als je een resultaat verwacht. En Aggregate gebruik je als je het verschil tussen beide uit wil leggen. Of - vooruit - als je wil aggregeren.
Aantekeningen over requirements - deel 1
Het moeilijkste onderdeel van softwareontwikkelen is niet het juist bouwen, maar het juiste bouwen. Vaak zwoegen programmeurs dagenlang op hun code en worstelen testers zich door het resultaat heen, om er pas helemaal op het eind van de ontwikkelcyclus achter te komen dat er iets is gebouwd waar eindgebruikers niet helemaal (of: helemaal niet!) op zaten te wachten. Het scheppen van een juist beeld van wat er gemaakt moet worden is misschien wel de belangrijkste stap in het ontwikkelen van software - en niet zelden de minst ontwikkelde.
Waarom DRY? Waarom DAMP?
Productiecode optimaliseer je voor onderhoudbaarheid; testcode voor leesbaarheid. Waarom? Omdat de context van productiecode en testcode verschilt. Beide dienen een ander doel, wat verschillende eisen aan de code stelt. Ze opereren in verschillende sferen, zogezegd.
Gedachten over modelaanpassingen
Wanneer er modelwijzigingen in het spel zijn, dan is een wijziging van de code alléén niet voldoende. Je zult ook moeten zorgen voor een migratie die de oude data omzet naar het nieuwe model. Zo’n migratie kan verschillende vormen aannemen - big bang of stapje voor stapje -, maar dat ‘ie er moet komen, staat vast. De vraag waar ik me op wil richten is: wannéér moet die migratie er komen?
De programmeur, de filosoof
We kunnen als softwareontwikkelaars veel leren van Socrates' filosofische houding. “Ik weet dat ik niets weet” betekent: ik neem niets aan, ik luister alleen goed naar wat de ander zegt en probeer diens standpunt zo helder mogelijk te krijgen. Ik hoor aan, parafraseer en controleer of die parafrase klopt. Voorzichtig trek ik conclusies - niet om de ander onderuit te halen, maar om te kijken of ik op de juiste weg ben, de ander begrijp. En ook: of het verhaal van de ander klopt - wat dat dan ook moge betekenen.
Waarom documentatie belangrijk is
Er is behoefte aan documentatie. Documentatie voorziet nieuwe ontwikkelaars van een kader, een context waarbinnen ze de code kunnen begrijpen. Het alternatief is: hen zelf een context laten ontwikkelen op basis van de code. Dat is niet alleen veel tijdrovender, het brengt ook het risico met zich mee dat ze zich een onjuist begrip van de code vormen.
Met atomic habits het nieuwe jaar in
Het was geen goed voornemen van me, maar op 1 januari begon ik wel met een goede nieuwe gewoonte. Twee nieuwe gewoontes, eigenlijk. Het overkoepelende thema van die gewoontes is: maak de investering klein - en maak deze daarna nóg kleiner.
Eerlijke domeinmodellen
Options en Eithers vormen nog maar de eerste aanzetten voor het idee van eerlijke functies. Het zijn constructen die, op het oog althans, redelijk beperkt blijven tot het technische domein. Maar het idee van eerlijke functies past ook uitstekend bij de praktijk van het modelleren van een domein, zoals gebruikelijk in Domain-Driven Design. Dat is een les die ik leerde van Scott Wlaschin op DevTernity.