Hvordan du bruger hot spots til at prioritere jeres tekniske gæld

I denne blog vil jeg beskrive en tilgang til at prioritere teknisk gæld i en enterprise applikation, som er under fortsat udvikling. Og hvorfor skal man så det?

Lad mig starte med at forklare lidt om teknisk gæld. Teknisk gæld bliver opbygget over tid og kan af omfang være langt større end man forestiller sig. Måske er gælden forårsaget af en kodepraksis, som rammer lidt ved siden af. Det kan eksempelvis være en switch case over en enum, hvor man ikke har en default, eller brug af X509Certificate2 (.Net System.Security.Cryptography.X509Certificates) uden at kalde Reset metoden bagefter. Du kan som produktejer, eller anden interessent, pludselig blive gjort opmærksom på den tekniske gæld. Det kan fx være på bagrund af en transition fra 'convention' (aftaler om, hvordan man koder) til 'structure' (tilføjelse af statisk kode-analyseværktøj, som Resharper eller SonarQube).

Det er nødvendigt at prioritere teknisk gæld, fordi man sjældent har tid til at håndtere al gælden på én gang. Selv hvis man havde tiden, er det relevant at tage stilling til, om ens mål er helt at udrydde alt gælden eller ej - måske vurderer man at tiden alligevel er bedre brugt på at videreudvikle selve applikationen.

Lad mig introducere en eksempel-applikation. Den har mange hundredtusind kodelinjer og er udviklet over adskillige år af en stor gruppe dygtige udviklere, der har arbejdet test driven, med gode kodeprincipper og code review ('convention'). Ved at lade SonarQube lave statisk kodeanalyse, blev der pludselig sat fokus på teknisk gæld. Der blev identificeret 31.000 issues og de var fordelt sådan her på severity (alvorlighed):

Tidsdimensionen

Først skal vi ha' kigget på tidsdimensionen. I det følgende er 'gammel kode' defineret som kode, der ikke er redigeret længe og samtidig har været i produktion hos kunder i lang tid. 'Ny kode' er defineret som kode, der er skrevet eller redigeret for nylig og som aldrig, eller først for nyligt, er kommet i produktion hos kunder. Et 'rigtigt problem' er defineret som et issue oplevet af brugeren af applikationen.

'Gammel kode' kan have teknisk gæld med høj severity, mens 'ny kode' kan teknisk gæld med lavere severity. Det sidste er vigtigst at adressere, da et 'rigtigt problem' i 'gammel kode' ville være rapporteret tilbage til dig fra en (retfærdigvis utilfreds) bruger.

Ved at analysere commit-historie i dit kode repository (for eksempel GIT), er det muligt at identificere 'gammel kode' og 'ny kode'. Analysen er lavet trinvis. Først på (kode-)projekt niveau. Så på fil-niveau og man kan endda også analysere på linje-niveau.

Fordelingen af 'commits over tid' mellem to releases opdelt per projekt, i eksempel-applikationen er fx fordelt sådan her:

Analysen vil ignorere 'gammel kode', som er til højre i grafen. I stedet er næste skridt at gå i dybden med de projekter, der har flest commits - det er projekterne i det røde rektangel. Nu findes så de filer med flest commits.

I eksempel-applikationen herunder har filerne i det røde rektangel flest redigeringer, i projekterne med flest commits. De er derfor vores identificerede hot spots.

Den menneskelige dimension

Dernæst må vi kigge på den menneskelige dimension. Forestil dig to teams, 'Team Rock Solid' og 'Team Rookies'. Team Rock Solid består af erfarne og dygtige udviklere, mens Team Rookies består af mindre erfarne udviklere, hvoraf nogle er udskiftet over tid.

Ved at analysere commit-historie - igen - er det muligt at identificere hvilke teams, der har lavet flest ændringer i et projekt og i en fil.

I eksempel-applikationen har otte teams committet kode til de tre projekter med flest commits, siden sidste release. Sådan er fordelingen af commits per team:

På billedet herunder kan vi se at Projekt A har en masse commits af Team Rookies. Det er en potentiel risiko og derfor et hot spot. Projekt B ser bedre ud da Team Rock Solid har klart flest commits i denne del af koden, men det er et potentielt hot spot, fordi der er så mange forskellige teams der har ændret kode her. Projekt C har commits fra meget få teams og er ikke et hot spot.

Sammensæt tid, den menneskelige dimension og statisk kodeanalyse

Med tidsdimensionen og den menneskelige dimension i baghovedet, er det lettere at prioritere. Vælg et hot spot og afskaf teknisk gæld i den pågældende kode. Du bliver nødt til at kende din kode, din historie og dine udviklere godt nok, for at udvælge de vigtigste hot spots først. Inden for det enkelte hot spot løses problemerne i severity rækkefølge.

I eksempel-applikationen var fordelingen af teknisk gæld for et valgt hot spot således (Som gjorde det mere overskueligt at håndtere).

En hot spot analyse kan bruges til andet end at prioritere teknisk gæld

Metoden med at finde hot spots kan også bruges til andre analyser.

Et eksempel er at finde hot spots, der har brug for refaktorering. Det kan være tilfældet, hvis et projekt kontinuerligt bliver redigeret af adskillige teams. Det kan være et symptom på, at man ikke har fulgt 'Domain Driven Design' principperne. (Domain Driven Design er et koncept hvor strukturen af kode opdeles efter forretningsdomæne. En legoklods har eksempelvis et serienummer og en vægt i produktionshallen, men i børneværelset er den beskrevet ved facon og farve).

Et andet eksempel er, at finde hot spots med teknisk gæld, hvor der er et enkelt team, der har lavet det meste 'nye kode'. Det kan være værd at overveje, at styrke det team med uddannelse eller en erfaren udvikler.

Hvordan kommer du og dit team i gang?

Du tænker måske at din organisation har styr på den tekniske gæld, - og hvis I har, er det jo helt fantastisk! Men for at vide jer sikre så begynd med at lave en statisk kode-analyse på en enkelt applikation og bliv derigennem opmærksom på omfanget af jeres tekniske gæld. Jeg ville vælge den største og/eller ældste applikation I har, at begynde med. Her er der størst chance for at se gælden.

Efter de foregående steps, kan I automatisere den statiske kodeanalyse, så den kører ved hvert commit eller som minimum én gang i døgnet.

Lav samtidig en tydelig baseline og aftal, at der ikke må introduceres ny teknisk gæld fra nu af.

Det er også en god idé at udbrede den statiske kodeanalyse til andre nyere og mindre applikationer, for at forhindre teknisk gæld, før den bliver uoverskuelig. Det er bedre at kende den tekniske gæld og kunne tage beslutninger på et oplyst grundlag, end at leve i blinde.

Derfor: Tag fat på den tekniske gæld FØR den bliver et kritisk problem for jeres applikation og for jeres forretning. I dag kunne fx være et godt tidspunkt at starte - og jeg kan kun anbefale den beskrevede angrebsmetode til at prioritere gælden, så du 1) får overblikket og 2) får identificeret og fjernet den mest risikable del af den tekniske gæld først.

Rigtig god fornøjelse!