Tag intentie van code
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.
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?
Blog #250!
Jeetje, ik blog alweer een tijdje! Er zijn 767 dagen voorbij gegaan sinds ik mijn honderdste blog schreef. Dus: feest! Vandaag blik ik terug op de laatste 150 blogs.
Tests vertellen verhalen
Op een dag schoot me het idee te binnen: een test vertelt een verhaal. In een test gebeurt er – iets. Een test kent een (a) subject dat (b) in een bepaalde situatie (c) een bepaalde handeling verricht met (d) een bepaalde uitkomst. (– Ik heb nooit gezegd: een test vertelt een goed verhaal.)
Meer over refactoren
Waarom wil je refactoren? – dat is de eigenlijke vraag, natuurlijk. Je wil refactoren omdat de code iets moet kunnen wat het nu nog niet kan, en omdat de structuur van de code moet worden voorbereid op dat wat straks moet kunnen. Je wil refactoren omdat je met je code wil werken, of in – maar in elk geval niet tegen.
Symmetrische en asymmetrische overerving
Code heeft niet alleen esthetische kwaliteiten. Het communiceert ook een intentie, een bedoeling. Code vertelt een verhaal. Zoals de manier waarop een personage wordt geïntroduceerd in een roman, ons iets vertelt over de rol en het karakter van dat personage, zo vertelt de manier waarop we bepaalde concepten in onze codebase vastleggen hoe we deze moeten “lezen”. – Code heeft, net als onze natuurlijke taal, een betekenis.
Overerving, compositie en dependency injection
Mijn collega had overerving toegepast om de nieuwe functionaliteit een plek te kunnen geven. De afgelopen maanden had ik gemerkt dat dit voor hem, en veel van mijn andere teamgenoten, een go to-oplossing vormt om code te kunnen hergebruiken. Maar ik was niet helemaal tevreden met het resultaat van die strategie. Ik voelde meer voor een oplossing die gebruik maakt van compositie. Het leek me een mooie gelegenheid om wat ideeën over deze concepten op papier te zetten.