De vraag achter de vraag ontdekken
Requirements engineering is… moeilijk. Heel moeilijk. Het achterhalen van de systeemvereisten vraagt een enorme inspanning van requirementsanalisten. Het op te lossen probleem is immers altijd vager, minder gedefinieerd dan de absolute precisie die software verlangt. Analisten moeten belanghebbenden de juiste vragen weten te stellen om een vertaalslag te kunnen maken van business naar IT. Gelukkig hoeven ze dat niet alleen te doen. Handboek requirements van Nicole de Swart is een onmisbare gids in dit proces.
Wij van TDD-eend...
Het is waar: uit het feit dat er tests zijn, valt niet te concluderen dat het systeem functioneert zoals verwacht - preciezer: zoals de eindgebruiker verwacht. Er valt hooguit uit te concluderen dat het systeem functioneert zoals de schrijver van de tests verwachtte. En als de schrijver van de tests tevens de ontwikkelaar van de code is, dan vormen de tests niet meer dan een verslaglegging van de aannames die de ontwikkelaar had tijdens de implementatie. En tóch geloof ik dat TDD het probleem van mijn collega - mijn feature voldoet niet aan de (impliciete?) requirements - had kunnen verhelpen.
Zet leren centraal in vijf stappen
Het is belangrijk om continu nieuwe dingen te blijven leren. Nu ben ik de laatste die zal beweren daar een expert in te zijn, maar op overmoedige momenten heb ik wel het gevoel dat ik het niet onaardig doe. Vandaar: dit zijn vijf stappen die je kunt zetten om leren een centrale plek te geven in je carrière als softwareontwikkelaar.
Testen met productiedata
Laatst kwam ik een test tegen die checkte of een bepaald object 48 keer voorkwam in een lijst. Het was een hartstikke valide test, daar niet van. Maar hij riep wel de vraag op: waarom 48 keer?
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?