Geen requirements, geen tests?
Ontwikkelaars zeggen soms dingen als: “Ik heb geen tests geschreven want de requirements zijn nog onduidelijk.” Of: “Het heeft geen zin om tests te schrijven want de requirements veranderen toch nog.” Dit is, denk ik, een redenering die grenst aan de waanzin – met potentieel desastreuze gevolgen bovendien. Maar het loont zich om erover te filosoferen wat ontwikkelaars ertoe drijft dit soort uitspraken te doen.
Over de boekenclub
Voor de vuist weg heb ik eens geroepen: “We zouden eigenlijk elke nieuwe werknemer een boek mee moeten geven als ‘ie begint. Met als (impliciete?) boodschap: we verwachten dat je dit leest. We verwachten dat je tijd vrijmaakt voor zelfstudie.” – Erop terugkijkend, was dat het prille begin van de boekenclub die ik maanden later oprichtte.
Een kleine stap voor de code...
Toen een collega van me laatst vastliep op het omschrijven van wat authenticatielogica, sprong ik graag bij. Ik wist immers wat de juiste weg voorwaarts was: heel veel heel kleine stapjes. Maar zo simpel bleek het toch niet te zijn…
Wat houdt ons tegen continu te leveren?
CI/CD houdt meer in dan het alleen inrichten van een buildserver: het is een heel andere manier van werken. Het verlangt van je dat je je werkt anders opdeelt, dat je in kleine stapjes werkt, dat alle code die je schrijft continu van hoge kwaliteit is. Continuous delivery vraagt van ontwikkelaars bepaalde gewoontes – gewoontes waar ze zich goed bij voelen – te herzien.
Softwareontwikkeling is een popcultuur (maar hoeft dat niet te zijn)
Het Agile manifest belooft betere manieren van softwareontwikkeling mogelijk te maken door de nadruk te leggen op “individuals and interactions” boven “processes and tools”. Maar wat is Agile ontwikkeling verworden, ruim twintig jaar na het schrijven van dat manifest? – Scrum + Jira. Oftewel: een process en een tool.
Testen jullie private methods?
Er zit een verborgen veronderstelling in je vraag. Namelijk: dat een stuk code alleen wordt getest als deze direct wordt aangeroepen. Maar er is een verschil tussen de code die wordt aangeroepen door een test, en de code die erdoor getest wordt.
Teveel tegelijk
“We zijn met teveel dingen tegelijk bezig,” constateert een ontwikkelaar tijdens de Retrospective. Die is met dit bezig, die met dat; hij met zus en zij met zo. Er is geen eenheid, iedereen werkt op zijn eigen eiland. – Het is een terugkerend thema. Waar ligt dat aan?
Drielagencargocult
Goede abstracties worden niet bedacht. Goede abstracties worden ontdekt. Ze vinden pas het levenslicht als reactie op een concrete vraag van de codebase. Softwareontwikkeling is in wezen een empirische aangelegenheid.
Wat betekent het tests te schrijven?
Het is een terugkerend thema in onze Retrospectives: testcapaciteit – en dan natuurlijk vooral het gebrek eraan. Het komt regelmatig voor dat verschillende pull requests een tijd lang open blijven staan, wachtend op iemand die de testautomatiseringsscripts aan de codewijziging toevoegt.
Enkele gedachten over code reviews
De praktijk van pull requests is een vertragingstactiek. Dat is een teken dat er niet op vertrouwd kan worden dat de kwaliteit van nieuwe code structureel aan de gewenste kwaliteitsstandaarden voldoet. Zo bezien, zijn PR’s een pleister op een wond die veel intensievere behandeling behoeft.