Tag software ontwikkelen
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?"
Grote refactorslagen ondermijnen vertrouwen
Wat een stakeholder betreft is een grote refactorslag een enorme kostenpost zonder aantoonbaar resultaat. Een team dat erop staat niet verder te kunnen werken zonder eerst een hele tijd heel veel geld uit te geven – nota bene zonder daar iets voor terug te geven! –, ondermijnt het vertrouwen dat de stakeholder hen daarmee geeft.
Functioneel denken: een praktijkvoorbeeld
Onlangs hielp ik een collega een moeilijk volgbare berg code te reduceren tot enkele eenvoudig leesbare regels. Door onze oorspronkelijke, imperatieve redeneertrant van ons af te werpen, en deze te vervangen door een declaratieve stijl, reduceerden we het netelige origineel tot een elegante functionele oplossing. – Het was een schoolvoorbeeld van de kracht van functioneel denken.