Tag technische schuld

Overpeinzingen (over vakmanschap)

“Ziet u niet hoe vaklieden, hoewel zij tot op zekere hoogte bereid zijn om hun opdrachtgever tegemoet te komen, zich niet kunnen veroorloven af te wijken van de voorschriften van hun vak? Is het niet verbazingwekkend en teleurstellend tegelijk dat bij een architect en een geneesheer de grondbeginselen van hun vak meer gerespecteerd worden dan bij de rede bij de doorsneemens, terwijl het juist de rede is die hij met de goden gemeen heeft?”

Tijdreis

Ik vroeg mijn collega’s: “Wat doet dit ding precies?” - waarop ze prompt de code tevoorschijn haalden en me stap voor stap door het importproces loodsten. Het was alsof ik terug werd geslingerd naar het begin van mijn ontwikkelcarrière, toen we met z’n allen een twaalf jaar oude legacy applicatie onderhielden die alleen te doorgronden was door nauwgezet de code te doorlopen. Wat blijkt: tijdreizen bestaat - je hoeft alleen maar bij een ander team te buurten.

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.

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 leercurve van Angulartests beklimmen - deel 3

Hoe onderhoudbaar was onze testopzet? Onze services verwachtte niet één afhankelijkheid, maar wel vijf of zes of zeven - en soms zelfs meer. En die afhankelijkheden verwachtten op hun beurt ook weer vijf, zes, zeven afhankelijkheden. Het was niet ondenkbaar dat een ontwikkelaar langer bezig zou zijn met het opzetten van al die afhankelijkheden om zijn test te laten compileren, dan het daadwerkelijk verifiëren van het gedrag van het stukje code waar hij in was geïnteresseerd.

De leercurve van Angulartests beklimmen - deel 2

In een vorige blog beschreef ik de keuze van mijn team om de front end van onze Angular-applicatie te testen via end to end-tests - en waarom we daar uiteindelijk op terugkwamen. Nu we besloten hadden inderdaad te willen (nee, moeten) unit testen, doemde er een nieuwe keuze op in de beslisboom: gaan we ons in het zweet werken om Angulars steile leercurve te beklimmen, of bekijken we of er een manier is waarop we het testen voor ons kunnen vergemakkelijken?

De leercurve van Angulartests beklimmen - deel 1

Niet lang nadat we Angular als front end-framework besloten te gebruiken, maakten we de keuze de unit tests te laten voor wat het was. We waren heus wel overtuigd van het belang ervan, dat was het probleem niet, maar de stijle leercurve van Angulars tests verleidde ons daar niet naar te handelen. Toch lieten we het testen van de front end niet helemaal schieten. Onze tester had zich verdiept in end to end testframework Selenium, en het team wilde graag geloven dat dit een acceptabel alternatief was voor het schrijven van front end tests. Maar uiteindelijk dwong de werkelijkheid ons toch die beslissing te herzien.

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?

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.

Bewuste technische schuld

Is technische schuld erg? Niet per se, zolang de keuze voor technische schuld maar een bewuste is. Als het team duidelijk maakt dat de oplossingsrichting technische schuld met zich meebrengt en afdwingt dat er op middellange termijn tijd wordt vrijgemaakt om die op te ruimen, hoeft die schuld geen probleem op te leveren. Integendeel: dankzij die schuld zijn we in staat om op korte termijn - vóór de deadline - waarde te leveren.