I retspsykologien anvender man geografisk profilering til at indsnævre det område, hvor gerningsmanden formentlig holder til. Ifølge Adam Tornhill, softwareudvikler med en universitetsgrad i psykologi, kan man anvende samme princip for at lokalisere de områder i koden, hvor man har størst chance for at finde de skyldige, når der opstår fejl. ”Treat you code as a crime scene” er hans tilgang, og første skridt er at udpege ”hot spots” i koden forstået som ”kompliceret kode, som vi ofte skal arbejde med”.
Ved hjælp af egenudviklede værktøjer har Adam Tornhill skabt 2D-visualiseringer af kode som byer – ”code cities” – hvor hver pakke eller name space bliver en ”city block”, og hvert modul eller klasse bliver en bygning. Størrelse er rent faktisk lig kompleksitet, så de højeste bygninger i code city er den mest komplekse del af kodebasen. Men at identificere hot spots i koden er ikke nok.
– I versionskontrolsystemerne har vi masser af data til rådighed om udviklernes adfærdsmønstre i forhold til koden. Ved at kombinere hot spots med disse mønstre får man et klart billede af, hvor der er mest aktivitet, og hvor man derfor skal have særlig fokus i sin test, forklarer Adam Tornhill.
Han tager udgangspunkt i flere store case studies, hvor et af dem eksempelvis afslørede, at syv ud af de otte mest fejlbehæftede områder rent faktisk var hot spots, og at fire procent af koden stod for 72 procent af fejlene.
Afdæk udviklerkommunikationen
Data mining på versionskontrolsystemerne kan også anvendes til at afdække og visualisere kommunikationsmønstrene mellem udviklerteams i forhold til koden. Man ved, at jo flere udvikler der har bidraget til et modul, jo større risiko er der for, at der opstår fejl. Så hvis visualiseringen viser, at udviklere fra forskellige teams ofte arbejder med koden fra andre teams, har man potentielt et problem. Så konklusionen er klar ifølge Adam Tornhill.
– Ved at koble retspsykologiske principper, data mining af versionskontrolsystemerne og visualiseringer får vi en rigtig god mulighed for at identificere den kode, som er svær at vedligeholde, og som er den mest sandsynlige kilde til fejl. Derudover får vi et grundlag for at diskutere organisationen omkring koden ved at se på kommunikationsmønstrene mellem udviklerteams.
Se Adam Tornhills oplæg her: goo.gl/hyMZ5K
