Tag software ontwikkelen
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.
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…
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.
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?
De wet van Postel
Het is niet de verantwoordelijkheid van de aanroepende partij om de input van een functie te schiften opdat er valide waarden worden meegegeven. Een functie moet zo eerlijk mogelijk zijn in wat het accepteert – maar daar waar er speelruimte bestaat is het de verantwoordelijkheid van de functie zelf om de inputs te valideren.
Ik loste het op met een monad
Een soort van monad. Denk ik.
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.
Gedrag versus structuur
Een systeem dat niet precies doet wat het moet doen, maar wel eenvoudig aan te passen is, is meer waard dan een systeem dat precies doet wat het moet doen maar slechts met grote moeite gewijzigd kan worden. Want het gedrag van een systeem zal veranderen, hoe dan ook. De wereld verandert, en daarmee de wensen van onze gebruikers en stakeholders. Het is onze taak als softwareontwikkelaars om daarop voorbereid te zijn, en een systeem te ontwikkelen dat daarop voorbereid is.
Refactoring als communicatiemiddel
We refactoren niet alleen om het makkelijker te maken de code te wijzigen, we refactoren ook om de code zo helder mogelijk te laten communiceren. En code die helder communiceert is op zijn beurt weer makkelijker om te wijzigen.
Fragment (uit een discussie over AI coding assistants en privacy)
Hij, apodictisch: “Als we onze code delen met AI coding assistants, zodat zij daarop kunnen trainen, dan geven we onze concurrenten toegang tot onze code, en daarmee een marktvoordeel.” – Ik, grijnzend: “Ben ik heel cynisch als ik suggereer dat we onze concurrenten in dat geval misschien juist een nadeel bezorgen?"