I Version2's artikel-serie om modernisering kontra nyudvikling har vi ofte brugt begrebet 'teknisk gæld' uden at have en klar definition af, hvad teknisk gæld er, og hvordan man egentlig kan opgøre mængden af teknisk gæld i et system.
Bevares, vi har henvist til både Howard Cunninghams og Martin Fowlers beskrivelse af begrebet, men hvordan finder man ud af, hvor stor den tekniske gæld er i et givent system?
Principper for god kode
Hos Kombit har man siden december 2018 været i gang med at finde svaret på det spørgsmål.
Kommunernes it-fællesskab anvender nemlig et system, der analyserer kodekvaliteten i it-systemer.
Hvis kvaliteten af koden er lav, vil den tekniske gæld være stor.
Det er Software Improvement Groups Sigrid-platform, som Kombit de seneste otte måneder har anvendt til at måle softwarekvaliteten i 14 systemer udviklet af leverandører til Kombit.
»Vi indkøber store it-systemer til anvendelse i kommunerne, og sommetider kan der være problemer med softwarekvaliteten. Vi ønskede et værktøj, der kunne give os et indblik i, hvad det er, leverandørerne leverer,« fortæller Jan Dynnesen, it-arkitekt hos Kombit.
Sigrid analyserer et systems kildekode ud fra otte faktorer, som baserer sig på veletablerede principper for god kode. Nedenstående 10 principper er taget fra bogen ’Building maintainable code’. Her anvendes Java-terminologi, men principperne gælder også for andre programmeringssprog. Eksempelvis vil metoder svare til functions i Javascript og C. 1 - Skriv korte metoder – Begræns længden af en metode til 15 linjer 2 - Skriv simple metoder – Begræns antallet af forgreninger i metoder til 4 (forgreninger i Java: if, case, ?, &&, ||, while, for, catch) 3 - Skriv koden én gang – Kopier ikke kode 4 - Skriv korte metodesignaturer – Begræns antallet af parametre i metoder til højst 4 5 - Opdel i veldefinerede klasser – Anvend klasser med klart defineret funktionalitet 6 - Anvend løs kobling mellem arkitekturkomponenter – Et systems top-komponenter bør have få bindinger 7 - Arkitekturkomponenter skal være afbalancerede – Antallet af komponenter bør være tæt på 9 (mellem 6 og 12), og de bør have nogenlunde samme størrelse. 8 - Hold den samlede kodemængde så lille som muligt 9 - Automatiser udviklingsprocessen og tests – skriv automatiserede tests, og anvend et test framework som JUnit 10 - Skriv ren kode Software Improvement Group måler vedligeholdelse baseret på de 8 første metrikkerGode koderåd for nemt vedligehold
Metoder/funktioner bør eksempelvis ikke være længere end 15 linjer, metoder/funktioner bør ikke være for komplekse, og softwarearkitekturen bør bestå af løst koblede komponenter (se boksen ’Gode koderåd’ for en liste over principper for god softwarekvalitet).
På baggrund af kodeanalysen udregnes en score, og systemets overordnede kodekvalitet tildeles en stjernemarkering, hvor 1 stjerne tildeles systemer med lavest kodekvalitet, og 5 stjerner systemer med den bedste kvalitet i koden.
Transparens og dialog
Jan Dynnesen understreger, at kvalitetsmålingerne ikke skal bruges til at slå leverandørerne i hovedet, men skal være med til at skabe en dialog om projekternes fremdrift og prioritering.
»Kvalitetsscoren bliver brugt som udgangspunkt for en konstruktiv dialog og en måde at få mere transparens om softwarekvalitet på. Det kan bruges sammen med leverandøren til at prioritere udviklingen. Hvis en leverandør leverer dårlig softwarekvalitet, er det ikke nødvendigvis leverandørens skyld,« siger Dynnesen og fortsætter:
»Vi kan måske have en masse ændringskrav, processer, der forhindrer leverandøren i at levere det optimale, meget rigide dokumentationskrav og andet, der begrænser udviklernes produktivitet. Det er vigtigt for os at vide, så vi kan adressere eventuelle problemer vi har hos os selv.«
Modtagelsen af kvalitetsmålingerne blandt leverandørerne har været blandet.
»Nogle leverandører har været meget positive, andre har været negative, og nogle har været neutrale – de anvender ofte selv lignende værktøjer til at måle softwarekvalitet,« siger Jan Dynnesen.
Kan softwarekvalitet måles?
Nogle af leverandørernes udviklere har stillet spørgsmål til, om alt vedrørende softwarekvalitet kan måles, og om kriterierne for god kode også er rimelige.
»De fleste godtager kriterierne, men nogle brokker sig eksempelvis over, hvor mange linjer en metode højst bør have. Der er også dem, der siger, at softwarekvalitet består af andre ting end dem, vi måler. Det kan være korrekt brug af design patterns, den rigtige anvendelse af en given teknologi og lignende. Det er sandt, men vi har brug for en objektiv måde at måle på, og det her er den bedste, vi har,« siger Jan Dynnesen.
En konsistent kodeevaluering
En veldefineret og konsistent måling af softwarekvaliteten er vigtig for Kombit.
»Vi har prøvet at have en tredjepart inde og vurdere kodekvalitet, men det var en subjektiv evaluering, så det kunne altid diskuteres. Hvis en tredjeparts-kodeekspert vurderede, at koden ikke var af høj kvalitet, så kunne leverandøren argumentere for det modsatte. Med de otte objektive kriterier er der ingen diskussion. Du får altid den samme score for den samme kildekode. Du kan selvfølgelig altid diskutere, om kriterierne er retfærdige, men da de er baseret på veletablerede principper for god kode, så er det svært at argumentere for, at en lav score betyder, at din kode har en høj kvalitet,« forklarer Jan Dynnesen.
De 14 systemer, der for tiden monitoreres, er skrevet i C#, Java og en enkelt i ABAP, som er sproget i SAP-løsninger.
Over 4.000 systemer som reference
Det giver kvalitets-scoren pondus, at scoren sammenholdes med en benchmark, der er etableret på baggrund af kodeanalyser for kørende systemer verden over.
Senior Management Consultant hos Software Improvement Group Nordic Rasmus Petersen forklarer:
»Vi har indsamlet data fra over 4.000 systemer verden over. og vi bruger en delmængde af dem til at etablere en benchmark.«
Software Improvement Group inddrager kun data til benchmarken fra systemer, der stadig er i drift.
5 procent af systemerne rangeres lavest med 1 stjerne, mens 5 procent får den bedste rangering med 5 stjerner. De resterende rangeringer med 2, 3, og 4 stjerner udgør hver især 30 procent. Software Improvement Group har rødder i det hollandske universitets- og forskningsmiljø indenfor datalogi og har i samarbejde med det tyske certificeringsorgan TÜV udarbejdet Evaluation Criteria for Trusted Product Maintainability, der udregner, hvor vedligeholdelsesvenlig kildekode er.Software Improvement Group
Ifølge Software Improvement Group er det dobbelt så hurtigt at lave ændringer og udvidelser i systemer med en firestjernet kodekvalitet som i systemer med en tostjernet kvalitet.
Hvert år bliver benchmarken justeret efter de seneste målinger, og der sker som regel en lille forbedring.
I bogen ’Building Maintainable Software’ af Joost Visser fra Software Improvement Group hedder det om de årlige benchmarkændringer: »Det er ikke de store ændringer. Overordnet set er det en tiendedel af en stjerne per år.«
Den lille kvalitetsstigning betyder, at kravene til stjernemarkeringerne også langsomt strammes, så det eksempelvis bliver lidt sværere at opnå et 4-stjernet kvalitetsstempel.
Softwarekvalitet verden over
Benchmark-målingerne kan ses som en indikator for softwarekvaliteten globalt set, dog mest i store organisationer og virksomheder, da det oftest er den type virksomheder, der anvender Software Improvement Groups kodeanalyse.
I bogen ’Building Maintainable Software’ fra 2015 hedder det om softwarekvalitet:
»Hos SIG (Software Improvement Group, red.) har vi set systemer, som basalt set ikke er til at vedligeholde. I de systemer bliver bugs ikke rettet og funktionaliteten ikke ændret eller udvidet, fordi det tager for meget tid og er for risikabelt. Desværre er det noget, som ses alt for tit i dagens it-industri, men det behøves ikke at være sådan.«
Hvis der kun sker små gradvise ændringer er det vel også tilfældet i dag?
»Ja, jeg er ked af at sige det, men situationen er stadig den samme. Dog er høj softwarekvalitet begyndt at blive et successkriterium, som softwarekøbere lægger vægt på, og i fremtiden vil højkvalitetssoftware med lave vedligeholdelsesomkostninger blive en nøglekonkurrenceparameter,« vurderer Rasmus Petersen.
Hvad koster vedligehold fremover?
Software Improvement Groups værktøjer kan estimere de totale vedligeholdelsesomkostninger fremover på baggrund af systemets kodetilstand sammenlignet med virksomhedens benchmark fra andre projekter.
Der udregnes en Total Cost of Ownership (TCO) med konkrete tal på, hvad det vil koste at refaktorere og vedligeholde et eksisterende system. På den baggrund kan man vurdere, om der skal bygges nyt, eller om man skal videreudvikle det gamle system.
Hverken Kombit eller Software Improvement Group ønsker at udtale sig om nuværende eller tidligere projekters kodekvalitet, men Version2 har før berettet om, hvordan Software Improvement Group betegnede Domstolsstyrelsens Juridiske Fagsystemer som et meget komplekst system, der ikke burde sættes i drift grundet forventede store TCO-omkostninger..
Når projekter ikke lytter
Version2 har også tidligere rapporteret om Software Improvement Groups kvalitetstjek af koden til Skats skandaleramte EFI-system. Et kvalitetstjek, som blev ignoreret: Software Improvement Group har evalueret omkring 4.000 it-systemer. Mere end 25 milliarder kodelinjer er analyseret i alt, og der analyseres mere end 110 millioner linjers kode ugentligt. Her er kriterierne for klassificeringen for nogle af de 8 metrikker, som Software Improvement Group anvender til at bestemme kodekvalitet. For at få 4 stjerner i vedligehold skal følgende gælde for kodelængden af metoder: Units med flere linjer end 15 må højst udgøre 42 pct. af koden Units med flere linjer end 30 må højst udgøre 19,1 pct. af koden Units med flere linjer end 60 må højst udgøre 5,6 pct. af koden For at blive tildelt 4 stjerner for kodekompleksitet skal følgende gælde for McCabe-kompleksiteten: Units med McCabe-kompleksitet større end 5 må højst udgøre 21,1 pct. af koden Units med McCabe-kompleksitet større end 10 må højst udgøre 7,7 pct. af koden Units med McCabe-kompleksitet større end 25 må højst udgøre 0,8 pct. af kodenKlassificering af kodekvalitet
»Kvalitetssikring af koden har ingen effekt. SIG, som på ugentlig basis maskinelt kvalitetssikrer den udarbejdede programmeringskode med rapportering til leverandørerne, melder om et voksende antal brud på retningslinjerne for programmering foretaget af KMD og CSC. Men begge leverandører har gennem længere tid ignoreret de ugentlige rapporter fra SIG, som blot kasseres uden læsning,« som Version2 kunne fortælle i 2016 på baggrund af en aktindsigt i en rapport fra PA Consulting.
Skat accepterede, at leverandørerne skulle ignorere kvalitetstjekket af koden. Af rapporten fremgik det videre:
»CSC og deres underleverandører er principielt uenige med SIG omkring anvendeligheden af SIG's værktøjer og analyser, hvorfor dialogen parterne imellem er ophørt, og CSC har fra Skat fået accept af dette.«
Proaktivt vedligehold
I de seneste tre-fire år har Kombit anvendt Software Improvement Group og andre uafhængige eksperter til enkeltstående reviews af projekter, men det er først de seneste otte måneder, at Kombit er begyndt at anvende kvalitetstjekket mere proaktivt, idet Jan Dynnesen og hans kollegaer sammen med leverandørerne løbende kan følge med i kodekvalitetens udvikling.
»Her er det mere proaktivt, da vi monitorerer koden fra uge til uge og identificerer trends, så hvis et projekt af en eller anden årsag begynder at få dårlig kodekvalitet, så kan vi gøre noget ved det, inden det bliver et problem,« siger Jan Dynnesen.
Igen understreger han, at leverandørerne ikke skal se monitoreringen af kodekvalitet som noget negativt:
»Vi holder kurser for leverandørerne, hvor de bliver undervist i, hvordan de kan bruge Sigrid-platformen i deres dialog med os. De kan dokumentere en korrekt leverance, høj kodekvalitet og dokumentere, at de arbejder på ting, som vi har bedt dem om. Hvis vi eksempelvis har bedt om en ændring, der bliver dyrere, end vi havde regnet med, så kan de dokumentere, at koden, som skulle ændres, måske var meget kompleks og derfor tog ekstra lang tid at ændre,« siger Jan Dynnesen.
Udviklerproduktivitet og TCO
Systemet giver også mulighed for at estimere udviklerproduktivitet, ligesom det giver mulighed for Kombit at prioritere ressourcer på tværs af projekter i Kombits portefølje.
»Vi har et råt estimat for, hvor mange kodelinjer en udvikler kan skrive om dagen, baseret på data fra flere tusinde projekter. Det kan bruges til at udregne udviklingstiden for et system i mandår. Vi kan sammenligne systemerne med hinanden og prioritere udviklingen af systemerne,« siger Dynnesen og fortsætter:
»Projektejerne kan lave budgetestimering baseret på TCO for et projekt samt for hele projektporteføljen for de næste ti år. Det er en god ting ved projektudbud.«
...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.
