Tag Leermoment
Wat is refactoring (volgens Hannah Arendt)?
Wat kunnen Hannah Arendts filosofische overpeinzingen ons leren over refactoring? Nou, bijvoorbeeld waarom de metafoor van technische schuld een misleidende is. Maar als refactoring niet het afbetalen van technische schuld is, wat is het dan wel? En wat betekent dat voor de rol die refactoring in onze dagelijkse werkzaamheden in mag (of moet?) nemen?
De bouwmetafoor gaat niet eens op voor de bouw
De bouw anno nu heeft veel ideeën uit agile en lean geïncorporeerd en heeft daarom tegenwoordig – grappig genoeg – meer weg van softwareontwikkeling dan je zou verwachten. Dus niet alleen softwareontwikkeling is niet als het bouwen van een huis – zelfs het bouwen van een huis blijkt niet als het bouwen van een huis!
Sabotage!
Onlangs volgde ik een training Deep Democracy – en werd ik bewust gemaakt van enkele valkuilen en disfunctionele patronen in samenwerking. Eén van de interessantste inzichten die ik opdeed hadden te maken met sabotage: het ondermijnen van (een deel van) de groep. Dat kan op allerlei manieren gebeuren, van het maken van (sarcastische) grappen tot roddelen tot tegenwerken of zelfs staken. Het zijn allemaal voorbeelden van “ja zeggen maar nee doen.”
Feature branches belemmeren een beter begrip van koppeling
Laatst brak een kleine wijziging aan de back-end – die we zo snel mogelijk richting de testomgeving hadden gebracht – functionaliteit aan de front-end. Voor mijn collega was het een ideale gelegenheid om zijn bias voor Gitflow bevestigd te zien. “Dit zou nooit gebeurd zijn als we van feature branches gebruik hadden gemaakt!” concludeerde hij. – En niet onterecht, want het apart houden van de wijziging in kwestie zou de functionaliteit op testomgeving inderdaad intact hebben gehouden.
Hoge cohesie, losse koppeling
Het mag gerust een cliché heten: bij het ontwerpen van software streven we naar hoge cohesie (high cohesion) en losse koppeling (loose coupling). Met andere woorden: de modules die we ontwerpen moeten inhoudelijk één geheel vormen, en niet onlosmakelijk verbonden zijn met andere modules; wijzigingen in de ene hoek zouden minimale gevolgen moeten hebben voor andere hoeken van het systeem. Systemen met hoge cohesie en losse koppeling worden ook wel modulair genoemd.
Gecompliceerd vs. complex
“Wat maakt code complex?” – Nee: “Wat maakt code nodeloos (of accidenteel) complex?” Dat is de vraag die centraal staat in Vlad Khononovs Balancing Coupling in Software Design. Wat de vraag oproept: wat is complexiteit precies?
Testen: Een filosofisch retrospectief
Eerst programmeren de programmeurs, dan testen de testers: het komt niet vaak voor dat zo’n voor de hand liggend idee zoveel misvattingen herbergt. Welk aannames liggen ten grondslag aan dat idee? En wat gebeurt er wanneer we die aannames kritisch tegen het licht houden?
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…
Waar zit de fout?
Mijn collega bracht een argument in dat vaak wordt genoemd als ik mensen vertel over testen via de voordeur: maar door de code direct aan te roepen, geven mijn tests onmiddellijk feedback over waar de fout zit. Als deze tests beginnen te falen, dan weet ik zeker dat daar de fout zit. En dat scheelt tijd in het debuggen van de code. – Maar dat laat de volgende vraag onverlet: is een unittest (waarbij “unit” wordt opgevat als “eenheid van code”) het beste middel om erachter te komen waar de fout zit?