För mig verkar det som att kodgranskningsprocessen alltid ligger långt efter de verktyg som vi använder. När jag började som konsult på Ericsson 2004 var det fortfarande kutym att kodgranskning gjordes genom att det i slutet av utvecklingen, vattenfallsprocess, kallades till ett granskningsmöte. Alla skrev ut koden på papper och gjorde anteckningar varefter man samlades ett 10-tal personer några timmar och gick igenom koden.
Problemet med det var att det var allt för sent eftersom koden redan var på plats och det fanns väldigt lite tid kvar att ändra. Samtidigt hade personen som blev granskat arbetat i flera månader med koden, och om det var strukturella problem så kunde en stor del av arbetet faktiskt vara bortkastat. Oavsett så var det tvunget att leverera, därför genomfördes vanligtvis endast mindre ändringar.
Hålkortens tid.
Jag har ofta funderat på varför det gjordes kodgranskning på det sättet. Var kom denna processen från? Jag tänker tillbaka på min sommarpraktik på Kockums, och sedan min första kurs på LTH i programmering 1982.
Det där med egen dator fanns inte på den tiden, och det fanns ännu för få terminaler för att alla nya studenter skulle ha möjlighet att koppla upp sig via dessa mot servern som fanns.
Häromdagen hittade jag en bunt hålkort med den programmeringsuppgift vi fick. Det är snart 35 år sedan vi gick den kursen men jag minns fortfarande processen. Man skissade på sina program med papper och penna. Diskuterade med sina kompisar om olika lösningar och gick sedan för att boka en tid i stansrummet där det fanns ett antal hålkortstansar, stora som ett större skrivbord, där man sedan skrev in sin programkod, rad för rad. Det gällde att inte tappa korten därefter och behöva sortera dem i rätt ordning igen.
Minns även att på Kockums fanns det ett rum där ett 20-tal personer satt och stansade hålkort, troligen med data för löner etc, som sedan matades in i någon dator för att skapa order till banken. Någon gång i veckan körde jag dessa band med data till SEB och lämnade dem.
Efter att jag stansat alla hålkorten med en rad på varje så var det dags att köra dem. Vi hade tur för vi kunde själv lägga dem i kortläsaren och starta inläsningen medan tidigare studenter lämnade in högen till datacentralen som sedan körde programmet under natten varefter resultatet kom på papper som kunde hämtas dagen efter.
Ofta har jag tänkt på att Ericsson måste ha levt kvar med de tankar om kodgranskning som togs fram under 70-talet och som speglar helt andra möjligheter än vad vi har idag. Hade jag otur när jag körde min trave hålkort så var det ett syntaxfel så att kompilatorn klagade, och då var det bara att försöka få några minuter vid en hålkortstans igen för att skriva ut ett eller flera kort till.
Under sådana förutsättningar var det självklart att man bad om hjälp av kompisarna för att först granska koden som man skrivit ner på papper och sedan be dem titta igenom hålkorten.
Samtidigt var inte projekten månader långa utan det var oftast begränsat med kod som skulle granskas. Hållkortstravarna blev ganska otympliga om det blev mer än några 100 rader kod. Vattenfallstänket fungerade bra för det var sällan längre än någon vecka som man skrev koden.
Gerrit och andra verktyg
Som en svar från utvecklarna kom efterhand verktyg som Gerrit, Code Collaborator osv. Istället för att skriva ut papper och hålla möten kunde granskningen ske i datorn, dessutom var det förstår lättare att se vilka ändringar som gjorts sedan förra granskningen. I början var dessa verktyg konstruerade så att granskningen i princip gick till på samma sätt som när papper skrevs ut etc. Granskningen distribueras, granskarna kommenterar, ansvarig uppdaterar koden och sedan uppdateras granskningen. Sedan har Gerrit tagit ett nytt steg och låter både granskarna och ansvarig att redigera koden direkt i Gerrit. Det gör att mindre justeringar kan läggas in både direkt och som förslag, som kan accepteras utan att man gör en ny runda. Detta borde generellt sätt förkorta processen och spara tid.
Parprogrammering
Att kunna redigera i granskningen är egentligen ett steg mot parprogrammering som i och för sig kom innan Gerrit fanns. Vid parprogrammering så granskas koden kontinuerligt av den icke körande personen. Det uppfattas ibland som slöseri med tid men vid en analys om den totala tidsåtgången för att programmera på traditionellt sätt så finns det för mig indikationer på att det i många sammanhang tar mindre tid. Två scenarier som kan beaktas är först att man inte gör någon kodgranskning all,s och dels om man gör kodgranskning när allt är färdigt enligt utvecklaren. “Allt” kan vara en liten bit kod på några få rader eller betydligt mer men jag anser att samma resonemang håller i båda fallen.
Om ingen kodgranskning görs så går vi fortare från kod till integrationstester. Vad som sedan händer beror mycket på programmerarens erfarenhet mm, men risken att fel hittas senare i processen är förstås större och dessa fel skall hittas, rapporteras, följas upp, rättas, testas om osv. Här kan förstås den tiden som sparas in i stället för parprogrammeringen snabbt ätas upp. Värst är det förstås om det dels kommer ut allvarliga fel till kunderna, plus att koden mer eller mindre måste skrivas om till stora delar för att man missförstått kraven eller att designen inte fungerar osv.
I fallet med att kodgranskningen görs så blir det mycket tid att administrera granskningen. Dels måste granskarna sätta sig in i kraven, förstå designen och sedan utvärdera och förstå koden. Sedan kommuniceras dess synpunkter via textmeddelande till ansvarig person som sedan skall tolka detta och ta ställning till vad som skall göras. Personen kanske inte alls förstår och det kallas till möte eller så görs ändringar som sedan måste itereras en gång till. Många gånger får jag känslan av att dessa iterationer tar mycket tid. och dessutom måste de inblandade göra granskningen och rättningarna mellan andra uppgifter. Detta kostar tid och energi eftersom man måste byta fokus och försöka komma ihåg var man nu var någonstans. Vid parprogrammering är det istället fullt fokus på en sak i taget.
Nästa steg är att alla programmerar tillsammans.
Online parprogrammering där alla i teamet ser varandras kod kontinuerligt och man kan välja att uppdatera i vilken editor som helst. Båda kan köra hela tiden i och med att var och en har sitt tangentbord. Jag skulle föredra att detta tog plats i samma lokal men med dagens verktyg för videokonferenser via datorn borde det även gå att programmera tillsammans på distans.
Det blir som parprogrammering men att alla kan skriva samtidigt. Jag bedömer det som att det kan bli bättre flyt i parprogrammeringen då den som “granskar” kan justera koden utan att den som kör behöver slita sig från sina tankar och rätta ett litet fel i tidigare inmatad kod.
Vad är nästa steg?
Hur tror ni att detta kommer att fungera? Vilket är nästa steg i den tekniska utveckling som gör att vi måste tänka om avseende hur vi utvecklar kod? Att man på 60-talet tänkte vattenfall har jag full förståelse för. Det som är problemet, anser jag, är att processerna i företagen inte följer med den tekniska utvecklingen. Ett missat semikolon på korthålstiden medförde att jag blev försenad ett dygn med min uppgift. Idag finns det edtiorer som hjälper till att lägga till allt detta och koden kompileras kontinuerligt för att se till att det inte finns syntaxfel. Självklart måste processerna förändras när förutsättningarna ändras, men på vilket sätt kommer detta att ske i framtiden?
Glöm inte att justera era processer efter de verktyg som används och analysera varje steg i ert arbete och se om det tillför något.