Feedback om refaktorering var ofta just förslag som gavs för att sprida och väcka tankar om hur koden kunde förbättras.
Kodexempel D.3: Exempel på ett JavaScript-relaterat fel.
// FIXME: Don’t use ’’ around object keys.
var fileChangeEvent = new CustomEvent(’fileChange’, {’detail’: data});
Kategorin JavaScript fångade upp fel relaterade till stil och syntax för JavaScript men som var så pass generella att de inte föll inom kategorierna kodstandard eller arkitektur.
Kodexempel D.4: Exempel på feedback gällande kodstandard.
//FIXME: Use camelCase for function names. function expand_collapse_graph(graph)
Feedback inom kategoring kodstandard gavs vid brott mot de kodstandarder som användes i projektet. Vilka dessa var redovisas i 5.3.
Kodexempel D.5: Exempel på ett arkitekturellt fel.
<body>
<!--FIXME: Put all style settings in CSS files. -->
<div id="crypto-graph-container" style="width:800px; height:400px;"></div>
Feedback om arkitekturella fel påvisades då koden stred mot den arkitekturplan som fram- tagits för projektet.
Kodexempel D.6: Exempel på ett presentationsfel.
{
trigramText: "TER", frequency: 0.70 //FIXME: displays as "0.7" in the table }
Till kategorin presentationsfel hörde kod som inte hade något fel i sig självt, men som ledde till fel i presentationen av slutprodukten under användning.
Kodexempel D.7: Exempel på ett semantiskt fel.
else if (language === "en") {
plotLanguageGraph(english_stats, english_graph_data); if (typeof crypto_text != "undefined") {
/* FIXME: Wrong language, use getText[...]Eng() */ crypto_stats = getTextLetterFrequencySwe(crypto_text);
Kategorin semantiska fel rörde kod som var syntaktiskt korrekt enligt alla regler men som gav fel beteende i produkten.
D.4.2
Enkätundersökning
För att samla in gruppmedlemmarnas åsikter och tankar om parprogrammering och kod- granskning utfördes en anonym enkätundersökning där varje gruppmedlem, mig exklud- erad, fick besvara ett antal frågor. Enkäten redovisas i bilagedel 5.1.
D.5
Resultat
D.5. Resultat 42 20 19 9 6 5 5 Refaktoreringsförslag Kodstandard Kommentering JavaScript Arkitekturella fel Presentationsfel Semantiska fel 0 10 20 30 40 Antal förekomster
Figur D.1: Sammanställning av feedback från projektets samtliga granskningar.
D.5.1
Analys av gransknings-commits
I figur D.1 visas en sammanställning över antalet förekomster av de olika kategorierna på feedback som gavs under projektet.
I figur D.2 visas antalet kommentarer per review. En trendlinje är dragen för att ge en uppfattning av hur utvecklingen har skett över tiden.
I figur D.3 visas hur feedback givits per commit under projektet. Varje commit är presenterad med git commit id och datum. Medianvärdet för antalet “FIXME”-kommentarer per granskn- ing var 5 med ett genomsnittsvärde på 4,6. Kategorierna Presentationsfel, Arkitekturella fel och Semantiska fel har slagits samman till kategorin Övrigt.
D.5.2
Enkätundersökning
Åtta personer deltog i undersökningen. I bilagedel 5.2 redovisas svaren från enkätens fritextfrågor. Parprogrammering hade enligt enkätresultatet många positiva effekter på samarbetet, bland annat bidrog det till öppenhet i gruppen och att gruppmedlemmarna lärde känna varandra bättre. De negativa effekterna var färre, men den vanligaste åsikten var att det var problematiskt att hitta gemensamma tider då båda parter kunde arbeta. De positiva effekterna av samarbetet från kodgranskningen var spridda men fyra svar angränsar till ökad interaktion mellan berörda parter, bland annat att kodgranskning har lett till fler diskussioner och bättre kommunikation.
Parprogrammering och kodgranskning anses av fyra respektive sex av de svarande ge bättre kod. Den vanligaste nackdelen för båda metoderna var att de var tidskrävande.
D.5. Resultat ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● 5 10
mar 01 mar 15 apr 01 apr 15 maj 01
Datum
Antal k
ommentarer
Figur D.2: Antal granskningskommentarer över tiden.
0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 c9c04be 2016−02−24 879a8bc 2016−02−26 205dc6f 2016−03−03 b536a4a 2016−03−08 99bb620 2016−03−10 098e15a 2016−03−10 fa3ccee 2016−03−19 9723627 2016−03−28 67b7686 2016−04−04 e0ef284 2016−04−13 5a98aef 2016−04−13 92cbfac 2016−04−13 65f98c3 2016−04−14 37ba671 2016−04−14 8309869 2016−04−14 26a5d2b 2016−04−15 a53a437 2016−04−18 5c794a7 2016−04−22 60fd341 2016−04−22 403ddf1 2016−04−28 0ee2943 2016−05−01 df9be39 2016−05−02 7421356 2016−05−02 Git commit Antal f örek omster Typer av feedback
Kodstandard Kommentering Refaktorering JavaScript Övrigt
D.5. Resultat 0 2 4 6 Mycket negativ
Negativ Neutral Positiv Mycket
positiv
Antal
Metod Parprogrammering Kodgranskning
Figur D.4: Gruppmedlemmarnas inställning till parprogrammering och kodgranskning.
I figur D.4 visas en fördelning över gruppmedlemmarnas inställning till parprogrammering och kodgranskning.
I tabell D.1 visas hur stor del av gruppmedlemmarnas utvecklingstid som har ägnats åt parprogrammering. Tabell D.2 visar hur många kodgranskningar varje gruppmedlem utfört under projektet.
Tabell D.1: Andel utvecklingstid ägnad åt parprogrammering.
Parprogrammerad utvecklingstid (%) Antal
0-20 % 2
21-40 % 2
41-60 % 2
61-80 % 1
81-100 % 1
Tabell D.2: Antal kodgranskningar utförda.
Antal kodgranskningar Antal
0 1 1 0 2 2 3 1 4 2 5 1 10+ 1
Figur D.5 visar vilken av metoderna parprogrammering och kodgranskning som gruppmedlemmarna skulle välja till ett kommande projekt.
D.6. Diskussion
37.5%
37.5%
25.0%
Metod
Parprogrammering
Kodgranskning
Vet ej/Kan inte välja
Figur D.5: Gruppmedlemmarnas föredragna metod till ett framtida projekt.
D.6
Diskussion
Detta avsnitt diskuterar särskilt intressanta iakttagelser från resultatet och lyfter fram nackde- lar med den valda metoden. Slutligen förs ett resonemang kring det här projektets metoder för parprogrammering och kodgranskning och hur dessa skiljer sig från mer väletablerade metoder inom mjukvaruindustrin.
D.6.1
Resultat
Analys av gransknings-commits
I sammanställningen i figur D.1 kan man se att refaktoreringsförslag är den överlägset mest populära kategorin av feedback, mer än dubbelt så vanligt som de näst mest pop- ulära kategorierna kodstandard och kommentering. Arkitekturella fel har varit sällsynta och gruppmedlemmarna verkar ha haft bättre koll på arkitekturen än kodstandarden. Få semantiska fel och presentationsfel har uppmärksammats i granskningsstadiet. Detta kan bero på att utvecklaren själv har testat koden och beteendet av produkten innan granskning eller att granskaren haft mest fokus på själva koden och inte produkten.
I figur D.2 kan man se en antydan till en nedåtgående trend. Efter att en utvecklare har arbetat med ett och samma projekt under en längre tid borde rutiner för kodstandard och kommentering bli en naturlig del i arbetet. Det är dock oklart om någon sådan trend kan ses i figur D.3. En annan förklaring till en minskning i antalet granskningskommentarer över tiden är att de features som utvecklades blev mindre omfattande under projektets gång.
Enkätundersökning
Figur D.4 visar att majoriteten av gruppmedlemmarna är positiva till både parprogram- mering och kodgranskning. Kodgranskning är marginellt mer polariserande. I resultatet över vilken metod som är föredragen, figur D.5, är det så gott som jämnt fördelat mellan svarsalternativen.
I bilagedel 5.2 kan flera trender ses. Generellt kan sägas att för parprogrammering fanns fler positiva effekter och fördelar listade jämfört med negativa effekter och nackdelar. För kod- granskning var det en jämnare fördelningen mellan positiva effekter/fördelar och negativa
D.6. Diskussion
effekter/nackdelar.
En fördel med parprogrammering som endast nämnts av en svarande är “Bättre liv”. Även om det är sällsynt får parprogrammering ändå ses som en metod som kan ge positiva effekter av hög magnitud.
D.6.2
Metod
Analysen av granskningskommentarer har varit fullständigt beroende av att dessa har dokumenterats som “FIXME”-kommentarer via Git. Denna metod fångar inte upp de fall där feedback har skett via andra kommunikationskanaler (Slack, muntligt etc.) eller där granskaren inte lyckats hitta några felaktigheter i koden. Den tar heller inte hänsyn till olika granskares egenskaper, till exempel att vissa granskare tenderar att ge fler refaktorerings- förslag medan andra är mer engagerade i kommentering.
Metoden särskiljer inte granskningar som gjorts på parprogrammerad kod från granskningar som gjorts på kod utvecklad av en ensam utvecklare.
Trots att utvecklingen i projektet skulle om möjligt ske genom parprogrammering har en stor del av utvecklingen skett genom soloprogrammering. Om parprogrammering hade varit ett hårt krav hade förmodligen också resultaten från enkäten förändrats. Valfriheten kan ha gjort att gruppmedlemmarna har valt att använda parprogrammering när det passat dem och därmed fått en mer positiv upplevelse utifrån det. Kodgranskning å andra sidan var i princip ett krav för att en utvecklare skulle få integrera sin kod till projektets kodbas. Om båda metoderna hade varit påtvingade hade en mer rättvis jämförelse kunnat göras.
Storleken på projektet och antalet deltagare i undersökningen hade med fördel kunnat vara större. Med en grupp på åtta personer har enskilda individer fått en stor inverkan på up- plevelsen av de två metoderna. Hade projektet pågått under en längre tid hade förmodligen processerna förfinats och förbättrats för en mer positiv upplevlse.
D.6.3
Arbetet i ett vidare sammanhang
Parprogrammering är en metod som etablerades under början av 2000-talet och som har dokumenterats flitigt. I McConnell [47] listas olika faktorer för att lyckas med parprogram- mering. Bland annat nämns “Make sure both partners can see the monitor” vilket kan ses som en trivial självklarhet. Denna punkt har dock relevans då parprogrammeringen under projektet i huvudsak skedde på bärbara datorer. Dessa har generella egenskaper som liten skärmstorlek, låg skärmupplösning och låg ljusstyrka jämfört med en separat bild- skärm. Detta kan ha lett till ett mindre aktivt deltagande hos den observerande parten i paret. Hade parprogrammeringen skett under bättre ergonomiska förhållanden hade förmodligen också upplevelsen blivit mer behaglig.
Kodgranskning är ett utbrett koncept inom mjukvaruindustrin och används i flera större projekt och företag. För att göra granskningsprocessen praktiskt genomförbar i stor skala har specifika granskningsverktyg utvecklats, till exempel använder Android-projektet verktyget Gerrit [48] och Opera Software använder verktyget Critic [49].
I det här projektet har en enkel granskningsprocess med hjälp av tillgänglig funktionalitet i Slack, Git och WebStorm använts vilket haft fördelen av att ha en låg inlärningströskel men där nackdelen varit brist på skalbarhet som lett till strul under granskningsprocessen. I