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.
Borrelpraat
“Proost!” – en toen begon iemand over de uitvinding van het getal 0, en hoe bizar het is dat er ooit een tijd is geweest dat er geen nul was. Dit is de ultieme borrelpraatvraag: is 0 ontdekt of uitgevonden?
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.