Tag Refactoren
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!
Wat is de O in SOLID nog waard?
Een ontwikkelaar die eens code schrijft en deze nooit meer aan denkt te hoeven passen, is een ontwikkelaar die rot in zijn applicatie verwelkomt. Een al te strikte naleving van het Open-closed principe (OCP) getuigt van een ronduit onverantwoorde houding - in elk geval binnen de context van Agile ontwikkeling. Waar komt de aantrekkingskracht van het OCP dan vandaan?
Refactoren na Tolstoj
Laatst las ik een verhaal van Lev Tolstoj genaamd Uit de aantekeningen van vorst D. Nechljoedov. Luzern (1857), een verhaal gebaseerd op zijn ervaringen tijdens een reis door Zwitserland. Het is geschreven in dagboekvorm en gaat over een Russische vorst die een nacht verblijft in het Schweizerhof, een prachtig chique hotel in Luzern, Zwitserland. Mij deed het aan refactoren denken. - Ja sorry: beroepsdeformatie!
De ontwikkelaar als chirurg
Working Effectively with Legacy Code van Michael Feathers staat vol met adviezen waar je cleancodershart een slag van overslaat. Vrijelijk raadt Feathers je aan encapsulatie uit het raam te smijten of onhandelbare methods zomaar tot class te promoveren. Zijn inzichten gaan lijnrecht in tegen alle richtlijnen om goede, onderhoudbare code te schrijven. Het boek is zonder twijfel een aanrader voor elke softwareontwikkelaar.
De standaard versus de business
Onze business volgt de QTI-standaard, maar ze gebruiken niet alles. Zo bestaat er - op dit moment - nog geen behoefte om Items te construeren die uit meerdere rijen bestaan. Bij het modelleren van ons domein werden we voor een keus gesteld: volgen we de QTI-standaard bij het uitschrijven van ons model? Of leggen we alleen vast wat de business nodig heeft, en laten we ons eigen model daarmee afwijken van de standaard? Concreet: ondersteunen we meerdere rijen of niet?
Agile en Test-Driven Development
De meeste ontwikkelaars (waaronder ondergetekende!) schrijven als volgt code. Ze bekijken de specificaties en beginnen vervolgens te klungelen. Dat duurt een tijd, totdat ze iets hebben wat werkt. Of dat zo is, verifiëren ze middels handmatige tests. Pas als de code werkt als bedoeld, schrijft men - als het goed is! - een reeks geautomatiseerde tests. Het is een hardnekkig misverstand dat TDD deze praktijk van software schrijven omdraait: eerst de geautomatiseerde tests (meervoud!) schrijven, en dan pas de productiecode. De werkelijkheid ligt wat genuanceerder.
Enums, switch statements en SOLID - deel 7
Een eeuwigheid geleden - april vorig jaar - schreef ik een reeks blogs over wat logica die rondom een Enum gebouwd was. Bijna een jaar na dato stel ik de vraag: wat probeerde ik nu eigenlijk te bereiken? - Eigenlijk was mijn use case betrekkelijk eenvoudig. Ik wilde wat logica kunnen koppelen aan een Enum-waarde, dat is alles. Sterker nog, die wens is niet alleen eenvoudig, hij is ook ontzettend generiek. Dat is een significante observatie. Gezien de generieke aard van het codeerprobleem, is er eigenlijk geen enkele reden waarom ik code zou moeten schrijven het probleem op te lossen.
De noodzaak van refactoren
Ons team heeft een stakeholder wiens gezicht vertrekt, elke keer als we tijdens een Sprint Review aangeven tijd te hebben gestoken in het refactoren van onze applicatie. In zijn beleving is refactoren een verspilling van je tijd. Als we meer tijd hadden genomen om de wensen van onze gebruikers grondig te analyseren, redeneert hij, dan had zo’n dure, inefficiënte refactorslag kunnen worden voorkomen. Als ik iemand zo hoor redeneren, dan vertrekt míjn gezicht.