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?
Wat maakt een senior senior?
Laat ik de vraag zo stellen: waar is een junior, medior en senior verantwoordelijk voor? Ik hanteer de volgende vuistregel: een junior is ervoor verantwoordelijk zichzelf te verbeteren, een medior om het product te verbeteren, een senior om z’n omgeving te verbeteren.
Wie is er bang voor adapterfuncties?
Adapters zijn een bekend ontwerppatroon in de softwareontwikkeling. Toch kwam deze oplossingsrichting niet onmiddellijk bij me op toen ik een stuk code in onze zoekindex begon te refactoren (om van de oorspronkelijke schrijver nog maar te zwijgen!). In plaats daarvan gaven onze eerste pogingen er blijk van koste wat kost te willen blijven werken met de “standaard”-functies. – Waarom?
De bouwmetafoor
Softwareontwikkeling is geen constructieproces. Het bouwen (lees: “bouwen” – bouwen is een metafoor) van een applicatie is iets fundamenteel anders dan het bouwen van een huis.
Het ontologische argument
Onlangs pairde ik met een nieuwe collega. We hadden een refactortaak opgepakt om wat ondoorgrondelijke code rondom onze zoekindex te versimpelen. Ergens halverwege die refactorslag zei hij iets wat mijn aandacht trok.
Twee sonnetten
De grenzen van Java, kerel, / zijn de grenzen van mijn wereld. / Daarom kan ik leven met null. // Maar ‘n JavaScript-ontwikkelaar / z’n wereldje vind ik maar naar. / Want undefined, da’s flauwekul.
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…