Tag refactoren
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.
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.
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.
Imperatieve Options?
Ik gebruik Options graag, ze voorkomen een hoop foutmeldingen. Maar, belangrijker nog, ze maken mijn code expressiever en eleganter. Of liever: ze hebben de potentie dat te doen. Laatst kwam ik tijdens een codereview een functie tegen, waarop mijn primaire reactie was: dit moet anders. – Maar waarom?
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.
Technieken vs trucjes
Een goede programmeur is een luie programmeur – dat is een bekende wijsheid in softwareontwikkelland. Want: een luie programmeur automatiseert oninteressante, repetitieve taken, en creëert op die manier de ruimte om zich bezig te houden met interessante, afwisselende taken. – Althans, dat is één opvatting van wat het betekent om een luie programmeur te zijn. Maar er zijn nog veel meer manieren om lui te zijn. Vandaag wil ik het hebben over zo’n andere manier. Vandaag wil ik het hebben over de wens, behoefte of neiging om een techniek te reduceren tot een trucje.