Tag refactoren
Waarom ik die method dupliceer
Een collega keek over mijn schouder mee. Ik was zojuist bezig met een bugfix, dus ik schreef een test, zag ’m falen en navigeerde naar de plek waar ik mijn aanpassing meende te moeten doen. Ik hernoemde de method, plakte er de suffix _old achteraan. Daarna dupliceerde ik het geval, en bracht mijn wijziging aan in het duplicaat. Mijn collega vroeg me: “Wacht, waarom doe je dat?” Nou…
Refactoren als context switch
Context switching heeft een slechte naam in softwareontwikkelland en dat is niet helemaal onterecht. Het is enorm vervelend als je nét lekker aan het programmeren bent – om vervolgens weggeroepen te worden voor een snelle vraag of ellenlange vergadering (die ook een e-mail had kunnen zijn). Op dat moment raak je alle informatie kwijt die je in je hoofd hebt opgebouwd om een probleem te kunnen tackelen, en mag je opnieuw beginnen. Maar dat is maar de helft van het verhaal.
Waar doe je het voor?
Een luie programmeur grijpt alles aan om zijn eigen werk makkelijker te maken (met uitzondering van het besparen op kwaliteit - daar is een andere term voor: een slechte programmeur). En makkelijker maken betekent meestal: automatiseren. Want waarom zou je zelf het werk doen, als een machine het ook voor je kan doen?
Tests als vangnet
Tests zijn een vangnet. Elke keer dat je code aanraakt - en dat doe je continu -, dan speel je een balanceeract. Als je code blijft functioneren zoals bedoeld, blijf je op het koord. Zo niet, dan val je. En als je valt, heb je een keus: te pletter vallen, of opgevangen worden door een vangnet. Tests zijn je vangnet, je afgrond is - ontevreden ontwikkelaars, stakeholders, eindgebruikers.
Over afwas en software
Afwassen is net als software ontwikkelen. Althans, ik probeer mijn afwas net zo aan te pakken zoals ik mijn software het liefst ontwikkel. Het fundamentele idee wordt kernachtig verwoord door Kent Beck in de volgende quote: “For each desired change, make the change easy (warning: this may be hard), then make the easy change.”
Twee stijlen van refactoren
Het was een tijd terug 40 graden en dat leek me, om redenen die ik achteraf niet kan bevatten, geen reden om het geairconditioneerde pand van mijn werkgever te bezoeken. In plaats daarvan bleef ik met de gordijnen dicht op mijn snikhete kantoortje zitten en begon aan een grootscheepse refactorslag. Of liever: twee refactorslagen - de ene met een gestaag toenemende hoeveelheid koortsig zweet op mijn voorhoofd, en de ander met een stabiele hoeveelheid normalehittezweet. De ene refactorslag was een ramp, de ander een succes. In beide gevallen moest ik het kantoor nadien goed luchten - dat wel.
Scheid data ophalen van data manipuleren
Het aantal refactoravonturen (met goede of slechte afloop) dat ik heb beleefd is, inmiddels al lang niet meer op één hand te tellen. In de loop der tijd is een terugkerend fenomeen me opgevallen: code waarin het ophalen van data niet wordt gescheiden van het manipuleren ervan. Laten we dat eens wat nader bekijken.
Het probleem met technische schuld op je backlog
Zo gaat mijn team om met het monitoren van technische schuld: we prikken elke Sprint een moment waarop we er met elkaar over praten, en als we het belangrijk genoeg vinden om er wat aan te doen, dan voeren we een Product Backlog Item op om die schuld weg te werken. Die aanpak werkt goed - goed genoeg, in elk geval. De technische schuld van onze huidige applicatie blijft grotendeels binnen de perken. En bovendien - dat is nog veel belangrijker - is iedereen in het team op de hoogte van het feit dat sommige plekken verbetering behoeven, en welke plekken dat zijn. Maar toch zit iets me niet helemaal lekker in die aanpak.
Testen via de voordeur
Het ideaal van Test-Driven Development is dit: al coderend breid je je testsuite uit, zonder ooit één test te hoeven herschrijven. Het toevoegen van nieuwe functionaliteit gebeurt op zijn best binnen de kaders van een bestaande API. Op zijn slechtst leidt het tot uitbreidingen daarvan - meer niet. Er is, denk ik, een manier om dichter bij dat ideaal te komen. Dat ideaal bereik je door te testen via de voordeur. Dat houdt kort gezegd in dat je je logica idealiter test via dezelfde route als een gebruiker van je code.
Mijn eerste testgedreven stapjes
Na niet één, niet twee, niet drie, niet vier, maar vijf blogs over Test-Driven Development had ik ervoor nodig, voordat ik het aandurfde. Maar nu is het dan eindelijk zover: onlangs heb ik de eerste testgedreven stapjes gezet in mijn professionele carrière. Een mijlpaal!