Tag mentaal model
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?
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.
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.
Bind, Map en Match
Ik schrijf al twee jaar op dit blog over functioneel programmeren in C#, dus je zou denken dat ik de basis inmiddels wel een beetje zou moeten beheersen – en toch overkomt het me nog regelmatig dat ik uitroep: och, zit het zo! Zo had ik onlangs – na een hoop gepiel (en een beetje hulp van Scott Wlaschin) – een openbaring met betrekking tot de Map- en Bind-functies.
De ontologie van immutability
Het gebruik van immutable datastructuren maak je code veiliger, eenvoudiger en beter onderhoudbaar. Toch voelt het voor de meesten van ons vreemd, een totaal nieuw object te instantiëren wanneer één property wijzigt. – Waarom?
YAGNI veronderstelt tests
Er zijn twee soorten ontwikkelaars: ontwikkelaars die roepen: “You ain’t gonna need it”, en ontwikkelaars die mompelen: “Ja ja, dat roep je wel, maar ik bouw het voor de zekerheid toch maar in.” Ik behoor tot het eerste kamp; enkele van mijn collega’s tot het tweede. – Maar waarom?
Schone interfaces, simpele implementaties
Het dilemma was als volgt: ofwel de deadline missen met een “goede” oplossing (dat wil zeggen: een oplossing die de REST-standaard volgt), ofwel de deadline halen met een slechte (die een uitzondering introduceert in de opzet van onze API). Maar: dat is een vals dilemma.
Objectgeoriënteerd programmeren draait niet om objecten
Van Anjana Vakil leerde ik een interessante les: objectgeoriënteerd programmeren draait niet om objecten, het draait om het uitwisselen van informatie.
Wat is jouw mentale model?
Eerder schreef ik erover waarom het zo belangrijk is om code die data ophaalt te scheiden van code die data manipuleert. Ik kan me voorstellen dat ik lezers heb die denken: joh, dit zijn toch allemaal open deuren? Misschien hebben die lezers gelijk. Maar aan de andere kant: het aantal keren dat ik code heb kunnen verbeteren door het ophalen en manipuleren van data te scheiden, vertelt een ander verhaal. Wellicht loont het zich om daarom kort te reflecteren op een aantal redenen waarom deze goede gewoonte niet stevig verankerd is in het hoofd van elke ontwikkelaar.