Detektivarbejde kan afsløre programmeringsfejlenes gerningssteder

GOTO 2015: Ved at se på, hvilke dele af koden der opdateres hvornår og af hvem, kan man få et fingerpeg om, hvor der er størst risiko for fejl.

GOTO Copenhagen 2015: Langt det meste kode skrives i dag af grupper af udviklere, som holder styr på det hele ved hjælp af versionsstyringsværktøjer som Github. Og dataene herfra kan hjælpe med at give et indblik i, hvilke dele af koden der er i størst fare for at blive ramt af fejl.

»Som programmører tilbringer vi ikke det meste af vores tid med at skrive ny kode, men derimod med at lave ændringer i eksisterende kode – og især forstå hvad den kode, vi kigger på, gør,« sagde programmør Adam Tornhill i sin præsentation på GOTO Copenhagen 2015.

Ud over at være programmør har han også en baggrund inden for psykologien, og han har derfor udviklet et sæt open source-værktøjer til at analysere metadata fra Github til at forstå, hvor det går galt i softwareprojekter.

Tidligere har man forsøgt at finde frem til problematiske områder i programkoden ved hjælp af forskellige målemetoder, som kunne give et tal for kodens kompleksitet. I praksis viser det sig dog ofte, at metoderne stort set ikke er mere præcise, end hvis man blot gik ud fra antallet af kodelinjer.

»Ligesom FBI bruger geografisk profilering til at finde frem til en gerningsmand, så kan vi indsnævre tusindvis af kodelinjer til nogle få hotspots,« forklarede Adam Tornhill.

Ændringer i softwarekode registreres

Versionsstyringsværktøjer registrerer, hvem der laver hvilke ændringer hvornår. Dermed kan man eksempelvis finde frem til dele af koden, som over tid bliver ændret oftere end andre og af flere forskellige udviklere. Det kan give et fingerpeg om, at det dels er kode, som er vigtig for den samlede applikation, samt at der er tale om kompleks kode, der kræver mange rettelser.

Mange rettelser er samtidig en risikofaktor, hvis mange forskellige udviklere skal sætte sig ind i den samme kode og forstå, om en ændring vil have negativ indvirkning på andre dele af koden, som de ikke selv arbejder på.

I et eksempel fra den virkelige verden med 400.000 linjers kode, 89 udviklere og mere end 18.000 'commits' i løbet af et 18 måneders projektforløb, udgjorde sådanne hotspots syv ud af otte 'fejlklumper' – områder i koden, hvor de fleste af fejlene var koncentreret.

»Generelt er vi gode til at skrive programkode. Så den første version af koden ser rigtig god ud. Men så begynder de små ulykker at indtræffe. Der bliver tilføjet en ny feature, så rettes der et par fejl, så ændres scope for projektet – og så ændres det tilbage igen,« sagde Adam Tornhill.

Her kan man også bruge hotspots til at opfange tidlige faresignaler ved at kombinere hotspots med analyser af kodekompleksiteten. Da versionsstyringssoftwaren giver mulighed for at følge udviklingen over tid, så kan man holde øje med, om der er meget aktive områder af koden, hvor kompleksiteten stiger over tid.

Versionsstyringssystemet kan også bruges til at få en idé om, hvorvidt man er i færd med noget risikabelt i forhold til, hvilke udviklere der arbejder med hvilke dele af koden.

Kommunikation mellem udviklere afgørende

I et større udviklingsprojekt vil man ofte opdele systemet og overlade det til forskellige hold af udviklere. Der vil imidlertid altid være dele af koden, som flere af holdene har brug for, men hvor de enkelte hold ikke nødvendigvis er klar over de andre holds behov.

Derfor kan det være en god idé at se på, om udviklerne primært foretager ændringer i hinandens kode inden for deres eget team, eller om de laver mange ændringer i andre holds kode. Hvis der ikke er tilstrækkelige kommunikationsveje mellem udviklerne, som retter i den samme kode, så kan det føre til fejl, fordi de ikke har nært kendskab til, hvad koden bruges til af kollegerne.

»Så er du nødt til enten af ændre din systemarkitektur eller din organisation. Men din kode vil takke dig for det,« sagde Adam Tornhill.

Et sted, sådan en fejl kan opstå, kan være når man forsøger at nå en deadline ved at sætte flere udviklere på opgaven, men derfor vælger at lave en opdeling i flere teams, som måske ser fin ud i forhold til arkitekturen, men ikke nødvendigvis passer med koden i virkeligheden.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Stephan Ryer

"Et sted, sådan en fejl kan opstå, kan være når man forsøger at nå en deadline ved at sætte flere udviklere på opgaven, men derfor vælger at lave en opdeling i flere teams, som måske ser fin ud i forhold til arkitekturen, men ikke nødvendigvis passer med koden i virkeligheden."

Spot on!!

Ulrik Suhr

Hvis en kode del er meget berørt og har mange konsekvenser så skal der laves en test suite omkring det berørte.
dvs. at selv om man ændre meget lidt vil indvirkningen være på meget kode.
Den store mængde kode skal så testes igen. Derved opnår man muligheden for at fange fejlen i de yderste led selv når man indsætter valid kode.
Dette er vel egentlig også det princip Test Driven Development stiler efter.

Det er også som ovenstående skriver velkendt viden at flere udviklere sidst i projektet ikke løser problemet hurtigere.
Tror faktisk kun det er management eller ledelse uden egentlig viden på området der laver disse fejl.

Peter Stricker

Hvis en kode del er meget berørt og har mange konsekvenser så skal der laves en test suite omkring det berørte.
dvs. at selv om man ændre meget lidt vil indvirkningen være på meget kode.
Den store mængde kode skal så testes igen. Derved opnår man muligheden for at fange fejlen i de yderste led selv når man indsætter valid kode.
Dette er vel egentlig også det princip Test Driven Development stiler efter.


Njah, jeg synes egentlig, at du vender udviklingen om ovenfor. Du skriver om at lave test til en eksisterende kodebase, hvortil der endnu ikke eksisterer en testsuite.

TDD drejer sig snarere om at skrive ny kode, der implementerer features, som en nylig skrevet test har afdækket, at den eksisterende kode mangler. Det vil altså sige, at man implementerer en ny feature request ved at lave en ny test, der ville gå igennem, såfremt den testede kode implementerer featuren korrekt. Hvis den nye test mod forventning ikke fejler, så er der ingen grund til at ændre i den testede kodebase. Hvis testen derimod fejler, så ændrer man den testede kode indtil testen, samt de eksisterende tests, ikke længere fejler.

Metoden, som du beskriver ovenfor, er en fantastisk måde at opnå ro i maven på, inden man begynder at foretage ændringer i en eksisterende kodebase. Der er en del metodikker til dette arbejde, der er beskrevet rigtig godt i Michael Feathers' Working Effectively with Legacy Code.

Log ind eller Opret konto for at kommentere