»Det er muligt at kvantificere teknisk gæld med statisk kodeanalyse. Det kan være en interessant, ofte deprimerende, øvelse, men det er ikke nemt at handle på, hvad du finder.«
Ordene kommer fra Adam Tornhill, der i et lille årti har beskæftiget sig med kodekvalitet, teknisk gæld, og hvordan virksomheder bedst kan fokusere på at holde en stadigt voksende og kompleks kodebase under kontrol.
Statiske kodeanalyseværktøjer kan hjælpe en organisation, men ikke meget, mener Adam Tornhill, der ikke anbefaler virksomheder og udviklere at kaste sig hovedkulds ud i en mammutopgave med at komme af med al teknisk gæld. Adam Tornhill udviklede kommandolinjeværktøjet Code Maat, som supplerer teknikkerne, han beskriver i sin bog 'Code as a Crime Scene'. Adam Tornhill har siden givet Code Maat en grafisk brugergrænseflade i det cloudbaserede codescene.io og tilføjet en række nye features, som ikke eksisterer i Code Maat, ligesom han har skrevet en ny bog, 'Software Design X-Rays'. »Code Maat var en god start til at popularisere analyserne, men jeg vil helt sikkert anbefale CodeScene til professionel brug,« siger Adam Tornhill. Du kan logge ind på codescene.io med din Github-konto og begynde at analysere dine kodeprojekter.Værktøjer til at prioritere teknisk gæld
Tusindvis af issues
»Faren ved kvantificering af teknisk gæld er, at du får en masse information om tusindvis af potentielle problemer i kodebasen. Jeg har set eksempler på statisk kodeanalyse, der identificerer 6.000-7.000 væsentlige issues,« siger Adam Tornhill, der præsenterede på Goto-konferencen i København i slutningen af forrige år.
»Nogle organisationer siger så: 'Lad os investere tre måneder på at nedbringe antallet af issues til 5.000'. Jeg fraråder altid den tilgang. Det er lidt som at springe ud fra 5. sal i stedet for 7. sal.«
Problemet med den tilgang er, at man ikke nødvendigvis får gjort noget ved de problemer, som virkelig betyder noget for forretningen, påpeger han.
»Udviklere vælger at gøre noget ved de problemer, som de kender, de områder af kodebasen, som de føler sig hjemme i.«
Det er ikke nødvendigvis de områder af koden, som er den væsentligste for forretningen.
Projekter med samme mønstre
I stedet anbefaler Adam Tornhill, at man fokuserer på kompleks kode med teknisk gæld, som ændres ofte.
»Kodekompleksitet i sig selv behøver ikke at være et problem, men vi kan bruge det til at identificere kode og så finde ud af, om vi behøver at gøre noget ved koden. Hvis der samtidig er mange ændringer i koden, kan det indikere, at der er tale om et hotspot,« siger Adam Tornhill.
Han har analyseret kildekoden bag en række store softwareprojekter som Erlang, Ruby on Rails og Microsofts Roslyn ved hjælp af sine værktøjer (se boksen ‘Værktøjer til at prioritere teknisk gæld’).
Det viser sig, at de alle har samme mønster, når det gælder hyppigheden af ændringer per fil. Langt de fleste kodeændringer sker i en relativt lille andel af det samlede antal filer i et projekt.
»Jeg har set det mønster i 250-300 kodebaser,« siger Adam Tornhill.
De filer, hvor der ofte foretages ændringer, er dem, der skal fokuseres på, mens filer, der sjældent røres, kan ignoreres – også selvom koden er kompleks.
»Gammel kode er ofte god og stabil kode, da den er blevet hærdet og gennemprøvet,« siger Adam Tornhill og tilføjer med et smil:
»Gammel kode, der aldrig ændres, kan selvfølgelig være død kode; det er den bedste kode.«
Han understreger, at død kode selvfølgelig skal fjernes.
Teknisk gæld i Android
Adam Tornhill anbefaler, at bruge information fra versionsstyringssystemer og koderepositories til at finde frem til de komplekse metoder og moduler, som ændres ofte.
Som eksempel anvender han information fra Git om Android-kodebasen, specifikt Platform Frameworks Base, som består af 3 millioner linjers kode og har omkring 2.000 udviklere. I Services-komponenten viser ActivityManagerService.java sig at være et hotspot, kode med kompleksitet og mange jævnlige opdateringer.
Vil det være en god ide at refaktorere koden i den fil, spørger Adam Tornhill retorisk og svarer selv nej.
ActivityManagerService.java er på næsten 20.000 kodelinjer og er over de seneste tre måneder blevet ændret af 74 udviklere, hvilket gør refaktorering af en så stor kodebase besværlig. Det vil tage for lang tid at refaktorere det hele og koordinere opdateringer med udviklerne.
I stedet zoomer han ind på de enkelte metoder og finder frem til nogle mere overskuelige potentielle refaktoreringsmål.
Det gør han ved at se nærmere på de enkelte metoder/funktioner, og hvor ofte metoden/funktionen ændres samt den cyclomatiske kompleksitet
Personafhængig kode i ASP.NET
Adam Tornhill anvender også sine værktøjer til at identificere kode, som er afhængig af enkelte udviklere.
Hvis en udvikler vælger at forlade en virksomhed, vil det medføre videnstab om koden og dermed gøre det svært at vedligeholde og videreudvikle koden.
Det gælder ikke kun i mindre organisationer.
Adam Tornhill har eksempelvis analyseret Microsofts ASP.NET MVC Core, som er open source. Koden består af 350.000 linjers C#-kode og har omkring 180 udviklere.
»Jeg simulerer, hvad det betyder for viden om kode, hvis en enkelt kerneudvikler stopper,« siger Adam Tornhill og viser, at eksempelvis IntegrationTests har en personafhængighed til en enkelt udvikler.
»Jeg ser det samme mønster i mange andre organisationer. Hvis en nøgleudvikler stopper, vil det have en stor betydning for viden om kodebasen,« siger Adam Tornhill, der med sine værktøjer giver mulighed for at udviklingsorganisationer kan være proaktive og identificere områder af kodebasen, som er meget afhængig af enkeltpersoners viden.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
