Tag legacy code
Zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Ik hoorde een boel nieuwe ideeën, werd gesterkt in enkele van mijn al bestaande overtuigingen, en uitgedaagd sommige ingesleten gewoonten te herzien. Uit mijn stapel aantekeningen destilleer ik zes inzichten die ik alleen al de eerste dag opdeed.
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.
Wat je aanpakt weegt licht
De vloek van een goed functionerend team is dat de organisatie daarvan vindt: die kunnen dit en dat best erbij hebben. De zegening van een goed team is dat de organisatie daarin meestal wel een punt heeft. Dat gezegd hebbende, mijn team was niet blij toen we de opdracht in onze mik geschoven kregen om een bedrijfskritische legacy applicatie door te lichten. We hebben ons werk voor die applicatie lange tijd zo ver mogelijk naar achteren geschoven. Maar enkele Sprints terug was het dan toch zo ver. En eerlijk gezegd: het viel alleszins mee.
Legacy code en Test-Driven Development
TDD gaat over het toevoegen van nieuwe features - per definitie. Immers, wie tests toevoegt voor bestaande code is niet test-driven aan het developen. Maar de meeste ontwikkelaars werken helemaal niet aan greenfield-applicaties. Ze slepen zich dag na dag, week na week door het moeras dat we legacy code noemen. TDD lijkt te zijn weggelegd voor de lucky few onder ons die nieuwe applicaties mogen ontwikkelen. De rest van ons mag ploeteren in bestaande drek. Maar die conclusie gaat toch niet helemaal op.
Blijven we dit ondersteunen?
Onze legacy-applicatie focust zich op de constructie van toetsen, niet op de afname. Om de afnameomgeving te kunnen bekijken, heeft de applicatie een integratiepunt met een externe tool. Maar de laatste tijd levert die functionaliteit vooral veel frustratie op. Problemen met de externe tool worden op onze applicatie geschoven, en het gedrag met de geïntegreerde versie is bij een grote load inconsistent met die van de externe tool. De klachten over de integratie vreten tijd van het ontwikkelteam, en zorgen bovendien voor frustraties over en weer naar de stakeholders.