Tag refactoren
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.
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?