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.
Refactoring en Hannah Arendt
Yvonne Lam stelt dat er een betere metafoor voorhanden is voor dat wat we gewoonlijk “technische schuld” noemen: huishouding (housework). Het deed me aan Hannah Arendt denken. – Beroepsdeformatie, denk ik!
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.
Semantische bugs
Voor een presentatie klooide ik wat variaties op het FizzBuzz-algoritme in elkaar. En ergens in de loop van die codeeroefening stuitte ik op een interessante bug – hoewel, ik weet niet eens zeker of het wel een bug was. Dus: wat is een bug eigenlijk?
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.
Wat zegt deze test?
“Wat zegt deze test?” – Het meest voor de hand liggende antwoord is natuurlijk: wat de code doet. Maar dat is slechts wat een test expliciet zegt, de informatie die een test inhoudelijk overbrengt. Dat is niet het enige wat het zegt – verre van.
Wat zegt deze code?
De namen in onze code – van variabelen, velden, methoden, parameters – beschrijven wat de code doet. De naam van een class beschrijft haar wezen: integer
, Url
, ResourceHelper
. Anders dan bij mensen gaat de existentie van code niet vooraf aan haar essentie. Code is bepaald, bepaald door haar functie. Wat die functie is, weet een goede programmeur in een naam te vangen.
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?"
Een goede ontwikkelaar begrijpt eerst het probleem
Een softwareontwikkelaar is niet iemand die code schrijft. Iemand die slechts dat doet, kan, ondanks al zijn inspanningen, van geen enkele toegevoegde waarde zijn. Want uiteindelijk gaat het niet om de code. Het gaat niet om de code, zelfs niet als die code precies doet wat er gevraagd wordt. – Software ontwikkelen gaat om het oplossen van problemen.
Goede code is geteste code
Goede code is geteste code. Het is testbare code, zeker – en er zijn tests die het bewijzen. Als er geen tests zijn, dan is het geen goede code. – De vraag hier is natuurlijk: wat is goede code, wat betekent “goede code”? Is het code die doet wat het moet doen? Die netjes gestructureerd is? Die er goed uitziet?