Hvad fortæller måleværktøjerne om teknisk gæld?

Måleværktøjer kvantificerer noget teknisk gæld – lyder det forvirrende? Har du brug for en indflyvning til begrebet teknisk gæld, så læs det første blogindlæg. Her bliver begrebet gennemgået samt de fordele og ulemper, der er ved at introducere teknisk gæld. Dette blogindlæg fokuserer på den del af den tekniske gæld, som vi nemt kan måle på. Det er den del, der typisk bliver kategoriseret som kode gæld. Teknisk gæld består af mere end kode gæld, som vi også tidligere har skrevet om. Er du nysgerrig på forskellig kategoriseringer af teknisk gæld så læs her i det andet blogindlæg. 

Hvorfor har vi et behov for at måle teknisk gæld?

Teknisk gæld er et lidt diffust og uhåndgribeligt fænomen, så derfor er det belejligt, når måleværktøjer giver mulighed for at opgøre (dele af) den tekniske gæld. Værktøjerne tilbyder en score, som ofte bliver brugt til at give et indblik i it-systemets tilstand (og herunder mængden af teknisk gæld). Scoren bruges som en kvalitetsstandard, så man kan udarbejde tilstandsrapporter og lade dem indgå f.eks. i organisationens porteføljestyring. Omvendt kan en opgørelse af teknisk gæld også bruges til at få synliggjort denne og koordineret en samlet indsats om at afvikle gælden. Derudover bruges måleværktøjer også som en rettesnor til udviklerne, så de overholder fælles standarder for kodekvalitet.

Hvad er et teknisk gæld måleværktøj? Hvad kan det?

De fleste måleværktøjer laver en statisk kodeanalyse, som giver et øjebliksbillede af kodebasens tilstand. Når man gentager målingerne og sætter disse billeder sammen, giver de et indblik i udviklingen af kodebasen. Der findes mindst 20 måleværktøjer, som enten tilbyder en måling af kodens tekniske gæld eller dens ‘maintainability’ (hvor nem koden er at vedligeholde). Hvert værktøj bygger på en tilgang for god kodeskik, som igen baserer sig på en ISO standard (se nedenstående tabel). 

Kilde: Luka Pavlic, Tilen Hliš, Marjan Hericko, and Tina Beranic (2022)

Altså indeholder et måleværktøj et sæt regler, som koden skal overholde (dette kan sammenlignes med grammatiske regler). Værktøjet synliggør, når der er noget kode, som i større eller mindre grad overtræder disse regler. Det tilbyder typisk flere scorer og grafer baseret på forskellige parametre og en overordnet vurdering af kodens tilstand. 

Hvad er formålet med et måleværktøj?

Der er forskellige behov, der gør, at man tager et måleværktøj i brug. Det samme måleværktøj understøtter sjældent alle behov. Derfor er det vigtigt at være opmærksom på, hvilket behov man har, og hvilket formål man forventer, at måleværktøjet kan indfri. 

Porteføljeledelsen

Porteføljeledelsen kan benytte et måleværktøj til at understøtte porteføljestyringen. En organisation har typisk en overordnet kvalitetsstandard, som alle projekter bliver vurderet ud fra (ikke funktionelle krav). Her kan organisationen stille krav om en score ved brug af et bestemt måleværktøj. Dette indblik kan være særligt brugbart for mindre tekniske profiler (f.eks. programledere), der har en mere ledende rolle og ikke selv sidder med koden. På den måde kan mindre tekniske profiler håndhæve ‘god’ kodekvalitet, og sikre, at kodekvalitet er del af prioriteringen af organisationens udviklingsressourcer og krav til leverandører.

Teamet

Projekt- (eller vedligeholdelse-) teamet kan bruge et måleværktøj til at øge fokus på helbredsmåling (kvaliteten) af koden under udviklingen. Ved at monitorere udvikling af kodekvaliteten, kan teamet tydeligere se, hvornår afvikling af teknisk gæld skal prioriteres ind i backloggen sammen med anden udvikling. Måleværktøjet giver udviklerne et redskab til at sætte fokus på teknisk gæld. Benytter man et Scrum-setup, vil det være oplagt at inddrage måleværktøjets kodeanalyse ved sprintafslutningen og tænke eventuelle forbedringer eller refaktorering ind ved næste sprint-planlægning. 

Sigrid og Cast AIP er begge gode værktøjer til at præsentere ledelsen, hvad end det er i organisationen eller projektet, for en status på applikationerne der forvaltes. 

Softwareudvikleren

Et måleværktøj kan agere som et hjælpeværktøj til softwareudvikleren i det daglige arbejde. Måleværktøjet skal gerne fungere så tæt på workflowet som muligt, så det er integreret i de værktøjer, som udviklerne bruger. Her kan måleværktøjet bistå med at påpege problemer eller opmærksomhedspunkter i koden. Det kan sammenlignes med hjælpefunktionerne i Word, såsom grammatik og stavekontrol. Når man skriver en tekst, værdsætter man et værktøj, der spotter grammatik- og stavefejl. De nære måleværktøjer giver typisk feedback hver gang udvikleren tjekker sin kode ind. Eksempelvis ved at udføre målinger, der præsenteres i forbindelse med et pull request. SonarQube er et eksempel på et sådant værktøj og som har en developer first tilgang.

Rapporter

De fleste værktøjer kan også generere rapporter, der opbevares ved siden af kodebasen. Rapporten over det udførte arbejde kan bruges i eksempelvis review. Derudover kan opmærksomhedspunkterne, som værktøjet påpeger, give anledning til en sund diskussion i teamet om kodekvalitet.

Hvad er ‘god’ kodekvalitet?

Implementering af måleværktøjer kan enten ske top-down eller down-up. Altså at organisationen beslutter, hvilket værktøj udviklerne skal benytte, således at de kan få et benchmark for den tekniske tilstand. Alternativet er, at udviklerne finder et måleværktøj, der understøtter deres behov undervejs i udviklingsprocessen. Dermed kan værktøjet til udviklerne bidrage til at skabe rammerne for at diskutere kodekvalitet og kodeskik. 

Hvad der så bliver defineret som ‘god’ kodekvalitet, beror på det udvalgte måleværktøj, ligesom at reglerne varierer fra måleværktøj til måleværktøj – selvom reglerne er skabt på baggrund af den samme metode (SIG, CAST eller SQALE). Nogle måleværktøjer tillader, at man tilpasser reglerne. Denne funktionalitet er ret vigtig for måleværktøjer, der benyttes som hjælpeværktøj af udviklere. Et måleværktøj, der ikke tillader tilpasninger, og som teamet ikke opfatter som brugbart eller hjælpsomt, bliver nemt opfattet som en belastning, de er tvunget til at forholde sig til og bruge tid på. For at opnå god kodekvalitet er det essentielt, at teamet tager måleværktøjet til sig og opfatter det som en hjælp.

Man skal være opmærksom på, at beregningsmetoden for scoren af ‘god’ kodekvalitet er forskellig og afhænger af måleværktøjet. Eksempelvis giver SIG ikke en absolut score, men en relativ score i forhold til andre systemer, som de måler på. Dermed bliver scoren et ‘moving target’, hvor det gælder om at være bedre end sin nabo. Derfor er det vigtigt, at man som team diskuterer og definerer god kodekvalitet, ligesom man også gør ved ‘definition of done’. God kodekvalitet er noget, som man løbende skal arbejde med i takt med, at systemet bliver (videre-)udviklet, og behovene og omverdenen ændrer sig. 

Hvilke faldgruber skal man være opmærksom på ved at benytte et måleværktøj? 

Der er ingen tvivl om, at måleværktøjer kan være rigtig brugbare, men man er nødt til at gøre sig nogle overvejelser omkring brugen af værktøjerne. Det er vigtigt at bemærke, at de færreste værktøjer understøtter både porteføljeledelsens behov og udviklernes behov. Derfor kan det være relevant at benytte forskellige måleværktøjer.

Der findes adskillige tilgængelige værktøjer, som alle definerer teknisk gæld eller maintainability forskelligt. Det kan gøre det uoverskueligt at vælge et værktøj, der passer til ens behov, og som stemmer overens med ens egen opfattelse af maintainability eller teknisk gæld. Ved en stor del af værktøjerne, kan man ikke gennemskue, hvordan de præcis når frem til deres score. Dette er lidt problematisk, eftersom mange af værktøjerne heller ikke klart definerer ‘maintainability’ eller ‘teknisk gæld’. Derfor er der også en risiko for, at resultaterne bliver fejltolket.

Bruges scoren som et ikke-funktionelt krav, skal man huske, at scoren kun informerer om en del af systemets tilstand (dokumentation m.m. er sjældent inkluderet). Nogle af de største udfordringer med at videreudvikle i et system er fejlagtige abstraktioner, der er lavet undervejs, og dette kan disse værktøjer ikke give en score på. 

Der er risiko for, at man stoler ‘for meget’ på måleværktøjerne og glemmer, at de kun måler på koden på et lavt niveau. Dermed risikerer man at glemme den tekniske gæld, der eksisterer uden for kildekode (f.eks. gæld indenfor dokumentation, test mv.). Værktøjernes resultater kan være fejlbehæftet og påpege, at noget kode skal slettes, men som er væsentligt for, at systemet fungerer. Altså kan man ikke stole blindt på værktøjerne. 

Det er vigtigt at holde sig for øje, hvad værktøjerne måler, fordi to forskellige værktøjer, der undersøger den samme kode, kan komme frem til ret forskellige resultater. Tilmed er disse resultater igen forskellige fra, hvad udviklerne identificerer af teknisk gæld-opgaver. Følger man alle måleværktøjets regler, er der ingen garanti for, at kodebasen egentlig bliver forbedret. Det kan sammenlignes med, at en tekst kan være grammatisk korrekt, uden at indholdet giver mening. En god score på f.eks. test coverage betyder ikke, at testen er brugbar, bare at den er der. Der er en fare for, at man ‘gamer’ systemet, så man opnår høj score, men det betyder ikke nødvendigvis, at det er nemt at navigere i kodebasen. 

Opsummering og anbefaling

Et måleværktøj kan ikke alene sikre god kodekvalitet og minimere den tekniske gæld. I stedet skal man anvende det som et redskab til at få indblik i kodekvaliteten, og som man derefter kan handle på baggrund af.  

Man bør orientere sig i, hvad måleværktøjerne måler (se evt på deres definitioner) og deres begrænsninger. Brug både et måleværktøj og få udviklerne til at notere den tekniske gæld, der skabes eller identificeres undervejs. Det er vigtigt at være konsistent i valget af måleværktøj, men vær opmærksom på, at det samme værktøj sjældent understøtter forskelligartede formål. Derfor bør man overveje, hvilket formål måleværktøjet skal understøtte og hvordan det skal anvendes sammen med øvrige værktøjer i arbejdet med teknisk gæld. Måleværktøjerne hjælper både den enkelte udvikler og organisationen med at sætte fokus på teknisk gæld relateret til kode. Men værktøjerne i sig selv er ikke en silver bullet, der kan sikre fokus på og afvikling af den tekniske gæld.

Kilder

Pfeiffer, R. H., & Lungu, M. (2022). Technical Debt and Maintainability: How do tools measure it?. arXiv preprint arXiv:2202.13464.

Pavlič, L., Hliš, T., Heričko, M., & Beranič, T. (2022). The Gap between the Admitted and the Measured Technical Debt: An Empirical Study. Applied Sciences, 12(15), 7482.

Haki, K., Rieder, A., Buchmann, L., & W. Schneider, A. (2022). Digital nudging for technical debt management at Credit Suisse. European Journal of Information Systems, 1-17.

Vejledning til model for porteføljestyring af statslige it-systemer. Manual, Digitaliseringsstyrelsen, Copenhagen, DK (2019). https://digst.dk/media/21352/vejledning-til-model-for-portefoeljestyring-af-statslige-it-systemer1-kopi.pdf