Andra metodval

Det finns många olika typer av statisk analys av programmeringskod. Halsteads komplex- itetsmått mäter endast läsbarheten. Det finns andra metoder man kan använda sig av för att analysera programmeringskod men hur skiljer sig dem? Micro benchmarks fungerar bra för att testa småskalig funktionalitet. Finns det andra verktyg man kan använda för att testa större program, till exempel Optily?

Statisk analys Cyklomatisk komplexitet är en metod för att mäta komplexitet hos en funk-

tion eller program [62]. Högre cyklomatisk komplexitet hos ett kodblock betyder att det finns fler möjliga vägar för exekveringen. Om man kan välja mellan två funktionellt identiska kod- block är det kodblock med lägst cyklomatisk komplexitet att föredra. En skillnad mellan Hal- staeds komplexitetsmått och cyklomatisk komplexitet är att Halsteads komplexitetsmått för- ändras om man inför onödiga variabler medan den cyklomatiska komplexiteten förblir den samma. Man kan tänka sig att ett översättningsverktyg inte borde förbättra programmet när det gäller cyklomatisk komplexitet men man kan också tänka sig att det finns funktionalitet i det språket man översätter till som skulle kunna minska antalet vägar som koden kan ta när den exekveras. Detta är inte något som Halsteads komplexitetsmått tar hänsyn till och något som skulle kunna vara föremål för vidare undersökning.

Benchmark metoder Istället för att analysera hur snabbt en funktion exekverar kan man

undersöka program. Det är inte rimligt att analysera Optily på samma sätt som de kodexem- pel som tagits upp i denna undersökning. För att undersöka ett komplext program kan man

C.7. Slutsatser

istället välja att undersöka till exempel CPU- eller minnesanvändning. De tester som gjordes i denna undersökning undersökte inte dessa faktorer vilket gör att man inte får en helhetsbild över skillnader. Eftersom både Java och Kotlin exekveras på JVM:en kan man tänka sig att det inte ska vara någon större skillnad i varken CPU- eller minnesanvändning, Men det kan fortfarande vara intressant för att se om det uppstår fall då det är skillnad.

C.7

Slutsatser

Översättningsverktyget fungerar bra. Läsbarheten ökar om man översätter klassexempel me- dan prestandaresultatet är jämförbart. Men fler undersökningar av mer kvalificerad kod be- hövs då detta bidrag endast undersökte enklare kodexempel.

1. Översättningsverktyget översätter enklare kodexempel korrekt I de två exempel som

behandlats översattes koden korrekt. Eftersom de två exempel var av relativt enkel natur rekommenderas det att försöka översätta mer komplicerad Javakod.

2. Prestandan är jämförbar, åtminstone i de enklare exempel som jämförts Prestandaskill-

naden mellan den ursprungliga och den översatta koden är jämförbar. Det kan finnas stöd för att viss funktionalitet kan gå snabbare genom att exekvera Kotlinkod men fler undersökning- ar behövs.

3. Läsbarheten av den översatta koden är bättre i vissa fall JetBrains var tydliga med att de

ville få bort boilerplatekod. Detta har de lyckats med, åtminstone enligt klassexemplet som undersöktes. Det visade sig tydligt att koden blev enklare att läsa när onödiga funktioner försvann.

D

Effektiv kodgranskning av

Rasmus Larsson

D.1

Introduktion

Kodgranskning är ett verktyg för att säkerställa hög kvalitet på projekt av olika storlekar, och kan utföras på flera olika sätt. Detta verktyg har funnits i sin nuvarande form åtminstone sedan 1970-talet, och många projekt använder sig av någon form av kodgranskning. Detta projekt var inget undantag; både parprogrammering och verktygsbaserad granskning utför- des under utvecklingen av Optily.

De olika metoderna för kodgranskning kan delas in i två kategorier: lättviktig kodgransk- ning, och formell kodgranskning. Vad är skillnaderna mellan dessa typer av kodgranskning, och passar de olika bra för olika typer av projekt? Denna rapport berör dessa frågor, med förhoppningen att ge mer insikt i ämnet.

D.1.1

Syfte

Syftet med den här rapporten var att undersöka två typer av kodgranskning: formell och lätt- viktig kodgranskning. Fokus lades på att ta reda på hur ett projekts storlek påverkar hur väl en granskningstyp fungerar. Även av intresse var att undersöka vilka effekter kodgranskning hade på detta projekt, och använda sig av datan samlad från det projektet och koppla med data samlad från relevanta skrifter och tidigare undersökningar.

D.1.2

Frågeställningar

Nedan presenteras de tre frågeställningar som behandlas av denna undersökning.

1. Vilka effekter hade kodgranskningen i det här projektet? Kodgranskning utfördes i

detta projekt som beskrivs i stycke D.2, och då det tog tid från projektet som kunde lagts på till exempel utveckling istället, kan det vara av intresse att undersöka effekterna kodgransk- ningen hade på detta projekt.

2. Till vilken storlek av projekt lämpar sig formell kodgranskning? Formell kodgransk- ning, som beskrivs utförligt i stycke D.3.1, är en väldigt utförlig typ av granskning. Denna typ av granskning är mycket mer utförlig än en lättviktig kodgranskning, och är därmed även dyrare att utföra. Det kan vara av intresse att se om denna typ av granskning lämpar sig olika väl beroende på ett projekts storlek. Med storlek syftas ett projekts längd i tid, och antal projektmedlemmar.

3. Till vilken storlek av projekt lämpar sig lättviktig kodgranskning? Lättviktig kod-

granskning, beskrivs utförligt i stycke D.3.2, är en kategori av mindre formella gransk- ningsmetoder. En kodgranskning av denna typ är inte lika resurskrävande som en formell kodgranskning, och innefattar till exempel parprogrammering, informella diskussioner eller verktygsbaserad kodgranskning. Likt den förra frågan, så kan det vara intressant att ta reda på om denna typ av kodgranskning lämpar sig olika väl till olika storlekar av projekt. Med storlek syftas ett projekts längd i tid, och antal projektmedlemmar.

D.2

Bakgrund

Mjukvarugranskning började användas så tidigt som 1974 av IBM. De använde sig då av Fagan inspection, en formell kodgranskning. IBM dubblade nästan antal rader levererad kod efter implementationen av denna granskningsprocess, samtidigt som antalet fel per tusen rader kod minskade med 66%. [63]

I detta projekt utfördes lättviktig kodgranskning med hjälp av verktygen Trello och Git. Även parprogrammering användes under projektets gång. Utvecklingsfasen som undersök- tes i den här rapporten varade i fem veckor sammanlagt, med en uppdelning på en vecka per sprint.

D.3

Teori

Alla varianter av kodgranskning kan kategoriseras in i någon av följande typer: lättviktig kodgranskning och formell kodgranskning. Innebörden av dessa två kategorier kommer för- klaras i denna sektion.

D.3.1

Formell kodgranskning

Formell kodgranskning är som namnet avslöjar, en formell typ av kodgranskning. Den van- ligaste formella kodgranskningen, som de flesta bygger vidare på, kallas för Fagan inspection. Denna granskningsprocess togs fram av Michael E. Fagan, och publicerades år 1976 [64].

Utvecklingsprocessen som Fagan applicerar granskningsprocessen på illustreras i fi- gur D.1. I denna utvecklingsprocess finns även ett antal inspektioner utplacerade, I0till I2

och IT1till IT2. Inspektionerna IT1och IT2syftar till att öka robustheten hos testningen; vil-

ket i sin tur leder till en mer robust slutprodukt. Detta görs i två faser enligt Fagan: IT1är den

första. Under denna inspektion är det testplanen som ligger i fokus, och framförallt funktio- nell täckning av de skrivna testerna. Den nästkommande inspektionen IT2har som syfte att

D.3. Teori Design Level 0 Level 2 Level 1 Level 3 Level 4 Process operations Output Identifiable level of function

Origin of test level objectives Statement of objects Architecture Internal specification External specification Logic specification - I0 Inspection

- I1 Design complete inspection

Code Level 5 Coding/implementation - I2 Code inspection Unit test T est Level 6 Level 7 Level 8 Function test Component test System test Component Component Function Module Logic Logic Function + Component + Component + Ship Test plan Test cases IT1 IT2

Figur D.1: Programmerings-process enligt Michael E. Fagan

Inspektionen I0utförs redan innan kod har skrivits. Inspektionerna I1och I2räknas däre-

mot som kodgranskningar. Samtliga inspektioner I0- I2har som syfte att vid ett tidigt skede

mäta och påverka inneboende kvalitetsfaktorer. Kostnaden att åtgärda fel så nära startpunk- ten som I0 - I2 ligger är 10 till 100 gånger mindre jämfört med om felet skulle korrigeras

halvvägs in i processen eller senare. Inspektionerna I1och I2består av de fem steg som listas

i tabell D.1.

Tabell D.1: Steg i inspektionerna I1och I2

Processoperation Rader kod bearbetade per timme Mål med processoperation Design I1 Code I2

1 - Översikt 500 Ej nödvändig Kommunikation och utbildning

2 - Förberedelser 100 125 Utbildning

3 - Inspektion 130 150 Hitta defekter

4 - Omarbetning 20 16 Omarbeta och arbeta bort defek-

ter hittade av inspektionen

5 - Uppföljning - - Verifiera att de defekter och pro-

blem som upphittats under in- spektion har blivit bortarbetade

Tiden som behöver spenderas på varje processoperation räknas ut med hjälp av kolumnen ”Rader kod bearbetade per timme”. Om ett projekt till exempel skulle bestå av 1500 rader kod

så skulle det tredje steget ”Inspektion” ta 10 timmar sammanlagt under alla möten kopplade till I2.

D.3.2

Lättviktig kodgranskning

Lättviktig kodgranskning innefattar en uppsjö olika granskningsmetoder. Parprogramme- ring är en av dessa, och denna har använts i detta projekt. Denna lättviktiga kodgransknings- metod går ut på att en utvecklare skriver kod samtidigt som en annan ser över allt som skrivs. De två utvecklarna kan med fördel diskutera problemformuleringar och planerade lösningar. Syftet med detta är att personen som skriver koden kan fokusera på mindre uppgifter medan granskaren håller kvar helhetstänket på projektet.

En annan typ av lättviktig granskning är verktygsbaserad granskning. Även denna granskningsmetod har använts av i detta projekt, och nedan kommer granskningsprocessen genom verktyget Trello att presenteras så som det fungerat i detta projekt.

I figur D.2 illustreras en aktivitets livscykel genom granskningsprocessen som använts i detta projekt. Information om hur molnet i figuren (Aktiviteter från Scrum) fungerade i det här projektet hittas under stycke 4.2.4. Varje ofärgad ruta motsvarar en så kallad miniprocess. Den övre raden motsvarar titeln på en sådan miniprocess, medan den nedre raden indikerar vem som får utföra vilken miniprocess. Om det står A|B så får både person A och B utföra miniprocessen, tillsammans med den andra personen eller ensam. Varje miniprocess och dess möjliga utfall beskrivs nedan.

Utveckla Person A Granska Person B Merge Person A | B Revidera Person A | B Verifiera Person B | A Trello Git Klar Aktiviteter från Scrum

Figur D.2: Granskningsprocessen i detta projekt

Utveckla En aktivitet plockas av en utvecklare som benämns A i figuren. När utvecklare

A anser att uppgiften angiven i aktiviteten är färdigställd, markerar denne aktiviteten som ”Redo för granskning” i Trello. Aktiviteten förflyttar sig då till miniprocessen Granska.

Granska Nu kan en annan utvecklare, B, ta över aktiviteten och granska de ändringar eller

tillägg som gjorts av utvecklare A. Granskningen utfördes på designen och implementatio- nen av lösningen, men även på mindre detaljer som variabelnamn och dokumentation av funktioner. Om granskare B anser att lösningen är tillräckligt bra så kan denna person flytta aktiviteten till miniprocessen Merge. Om granskaren däremot anser att lösningen har brister så förflyttas aktiviteten till miniprocessen Revidera tillsammans med en beskrivande text av vilka brister granskaren syftar på.

Revidera Syftet med den här miniprocessen är att korrigera defekter i lösningen. Dessa kor-

D.4. Metod

eller enskilt. Efter dessa korrigeringar utförts förflyttar sig aktiviteten till miniprocessen Veri- fiera.

Verifiera Denna miniprocess är väldigt lik Granska, skillnaden är att granskningen nu istäl-

let sker på korrigeringarna från revideringen som utförts. Denna verifiering kan likt minipro- cessen Revidera utföras i samarbete mellan A och B, eller av en person. Observera att samma person som utfört ändringarna i revideringen inte får verifiera att korrigeringarna är tillräck- liga enskilt. Tabell D.2 illustrerar de tillåtna kombinationerna av fördelning av ansvar, som använts i detta projekt. Denna miniprocess är iterativ med miniprocessen Revidera, fram till det att lösningen anses vara tillräckligt bra. När detta inträffar förflyttas aktiviteten till mini- processen Merge.

Tabell D.2: Tillåtna ansvarsfördelningar i granskningsprocessen som utförts i detta projekt

Ansvarsområde Kombination 1 Kombination 2 Kombination 3

Utveckling Person A Person A Person A

Granskning Person B Person B Person B

Revidering Person A Person B Person A och B

Verifiering Person B Person A Person A och B

Merge Denna miniprocess är det sista steget innan aktiviteten anser vara klar, och det enda

som ska göras här är att sammanfoga de kodändringar och tillägg med resterande projekt. Sammanfogningen utförs av någon av de personer som varit inblandade i utvecklingen eller granskningen.

D.4

Metod

Den här undersökningen grundar sig dels på information som hämtats ur projektet som ut- förts, och dels från tidigare utförda undersökningar. Rådata från projektet hämtades från verktyget Trello, där kodgranskning dokumenteras. Med hjälp av denna rådata undersöktes utfallen av de utförda kodgranskningarna.

Utöver denna typ av data så används även resultaten från en enkät som gavs ut till pro- jektmedlemmarna. Enkäten var tänkt att svara på frågor som ej kunde fångas upp från rå- datan som gavs av Trello, så som hur projektmedlemmar tyckte att denna typ av granskning har fungerat. Följande punkter undersöktes med hjälp av enkäten:

• Uppskattad tid spenderad på granskning och parprogrammering • Upplevd effekt av granskning och parprogrammering

• Uppskattning av hur en formell granskningsmetod hade fungerat i projektet, med av- seende på effekt, tidsåtgång och schemaläggning

Utöver detta lämnas plats för fritextsvar i enkäten, för att fånga andra tankar.

För att bredda perspektivet och kunna jämföra formell- och lättviktig kodgranskning an- vändes vetenskapliga artiklar, då båda typerna av kodgranskning ej utförts i detta projekt. Dessa artiklar användes även för att försöka göra kopplingar mellan storlek av projekt och typ av kodgranskning.

D.5

Resultat

Nedan följer resultaten som erhållits av datainsamling från det använda verktyget Trello, enkäten som medlemmar av detta projekt fyllt i, och de litteraturstudier som utförts. Denna sektion är uppdelad för att spegla frågeställningarna.