Tag Refactoren
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.
Zonde om weg te gooien?
Laatst kwam ik tijdens het refactoren een stuk code tegen dat alleen maar werd gebruikt in unittests. Dat maakt me erg verdrietig, en om dat verdriet niet te hoeven voelen, donderde ik dat stuk code weg zodat ik er nooit meer naar om zou hoeven kijken. Een collega van me maakte bezwaar toen hij mijn pull request bekeek. En, eerlijk is eerlijk, niet helemaal onterecht. Er was veel moeite in deze feature gestopt, zei hij. Was het niet zonde om deze code zonder omzien te verwijderen?
Evolutionaire datamigratie met FluentMigrator
In het kort komt evolutionair databasedesign hier op neer. Stel, een ontwikkelaar maakt een wijziging in de code die een databasewijziging impliceert. In dat geval is het aan dezelfde ontwikkelaar om een migratiescript te schrijven die de codewijziging mogelijk maakt, en deze bij de codewijziging in te checken. De databasewijziging is onderdeel van de codewijziging, als het ware. En terecht, want zonder de databasewijziging is het niet mogelijk om de gewijzigde code te runnen.
Writer's block en programmer's block
Mensen zeggen nou nooit tegen me: “Karl, ik zou graag willen bloggen, maar ik weet niet waar ik moet beginnen.” Maar als ze dat zouden doen, dan zou ik zeggen: “Begin eens met wat je vandaag hebt gedaan.” Wat daarna volgt, zo stel ik me voor, is een stroom aan tegenwerpingen die iedereen bekend voor zou moeten komen die ooit meer dan één letter op papier heeft gezet. Die tegenwerpingen zijn uitdrukking van writer’s block.
Breek je test
In Martin Fowlers Refactoring vond ik een interessante programmeertip: breek je test. Ja, dat lees je goed.
Bevat deze code een bug?
Is een meerkeuzevraag waarbij je nul antwoorden in mag vullen van het type Multiple Choice of Multiple Response - of geen van beide?
Enums, switch statemens en SOLID - deel 6
De conclusie van onze refactorslag rondom een op een enum gebaseerd switch statement! Ik hoop de afgelopen weken aan te hebben getoond hoe het gebruik van SOLID-principes je code beter onderhoudbaar kan maken. Vandaag concluderen we met de vraag: moet je morgen meteen dit patroon uit je code base refactoren?
Enums, switch statements en SOLID - deel 5
De afgelopen weken heb ik een stuk switch statement rondom een enum gerefactord om meer in lijn te zijn met de SOLID-principes. Deze week kijken we naar de performance-impact van die wijzigingen op de code, en onderzoeken we of we die zo klein mogelijk kunnen houden. Spoiler: SOLID en performance hoeven elkaar niet te bijten!
Enums, switch statements en SOLID - deel 4
Vorige week refactorde ik een switch statement rondom een enum aan de hand van het Dependency inversion principe. Deze week zetten we onze refactorslag voort aan de hand van het de O in SOLID: het Open-closed principe. Zo voorkomen we dat we onze code hoeven te herschrijven, elke keer als we onze enum aanpassen.
Enums, switch statements en SOLID - deel 3
Vorige week refactorde ik een switch statement rondom een enum aan de hand van het Single-Responsibility principe. Deze week zetten we onze refactorslag voort aan de hand van de D in SOLID: het Dependency inversion principe. Tijd om de interfaces van stal te halen!