Cult of Code Quality

Transkript

1 Jakob Schyberg (d00jsc) Coaching av Programvaruteam Josef Granqvist (d00jgr) LTH Institutionen för Datavetenskap Cult of Code Quality Vad kan en coach göra? Denna djupstudie handlar om kodkvalitet. Vad det är, varför det är bra och sist men inte minst hur man kan åstadkomma vad vi kallar en Cult of Code Quality i ett programvaruteam. Djupstudien är skriven i samband med ett Extreme Programming-projekt i kursen Coaching av Programvaruteam, och innehåller erfarenheter och resultat från våra experimentella försök i projektet. 1

2 Cult of Code Quality Inledning Vad och varför? Vad är kodkvalitet? Varför högkvalitativ kod? Varför inte? Snygg kod kostar funktionalitet Stilkrockar Lathet Hur får man ett team att skapa högkvalitativ kod? Cult of Code Quality Gruppens Motivation Coaching Practices Samla ambitionerna Diskutera tidigt Motivera Berätta historier Sprid medvetenheten Redovisa JCC Redovisa Simple Design Redovisa arkitektur Växla mitt i Refaktorisera smart Refaktorisera varandras kod Refaktorisera mellan iterationer Kulten kräver offer Resultat och slutsatser Effektivitet Cult of Code Quality? Medvetenhet och ambitioner Referenser

3 1 Inledning Syftet med denna djupstudie är att finna dels betydelsen av högkvalitativ kod i ett programvaruprojekt och dels hur man främjar sådan kod inom Extreme Programming (XP). Studien består av en teoretisk och en praktisk del. I det teoretiska avsnittet ämnar vi utreda vad högkvalitativ kod är och vad det innebär i ett XP-projekt. Det praktiska avsnittet innefattar dokumentering av våra erfarenheter och slutsatser från ett experiment att skapa en så kallad Cult of Code Quality. Vi har vid ett tillfälle använt frågeformulär för att samla in erfarenheter och åsikter om vad en coach kan göra för kodkvaliteten i teamet. Det har varit intressant att mellan coacher och utvecklare jämföra uppfattningar om problem och insatser. 2 Vad och varför? Vi börjar med att reda ut vad kodkvalitet är och varför det är viktigt i ett XP-team. 2.1 Vad är kodkvalitet? Vi bör förtydliga att vi skiljer på kodkvalitet och programvarukvalitet. I denna studie pratar vi till exempel inte om arkitektur, design, stabilitet eller testbarhet, som vanligtvis förknippas med en högkvalitativ programvara. Istället ser vi på koden som en separat företeelse - vi intresserar oss för vad den har för egenskaper när man försöker förstå den, när man utnyttjar den som dokumentation och när man vidareutvecklar den. Vi intresserar oss för hur en människa tolkar den, inte hur en dator tolkar den. Från början hade vi en egen uppfattning om vad kodkvalitet var, utan att kunna sätta fingret på den exakta definitionen. Vi sökte efter en allmän definition och fann snabbt att det som skrivits av andra bekräftade vår egen uppfattning. Här följer ett försök att beskriva vad den allmänna uppfattningen innebär, sammanfattat från både våra egna och andras tankar. Kod med hög kvalitet är: 1 Läsbar: o tillgänglig att förstå både snabbt och grundligt o namn som är läsbara och ger information om det namngivna Snygg och ren : o rätt indenterad o enhetlig och likformig o tydlig Överskådlig: o välstrukturerad o välavgränsad o rätt paketerad 1 Styrkt av [2]. 3

4 Nu när begreppet kodkvalitet är definierat för denna studie, kan vi gå vidare med att utreda varför det behövs och vad dess roll är i programmeringsteamet. 2.2 Varför högkvalitativ kod? Utseendet på den källkod som en programvara består av spelar en avgörande roll för hur begriplig den är för en människa att förstå. Dåligt skriven kod är inte bara svårtolkad för andra personer utan även för författaren själv, exempelvis när minnet sviker. Därför bör man fundera på om man tänker utnyttja eller förändra källkoden i framtiden. I så fall bör man skriva kod av hög kvalitet. En mycket stor del av den mjukvara som utvecklas inom industrin idag, designas av grupper i varierande storlek. Detta innebär att projektet inte kan vara beroende av en viss person. Arbetet som var och en har uträttat måste kunna återupptas av en ersättare, eftersom gruppmedlemmar kan bli sjuka, bli omplacerade eller sluta arbeta på företaget. Detta kräver högkvalitativ kod eftersom ersättaren måste kunna sätta sig in i arbetet som den ersatte har presterat. När en mjukvara har kommit ut på marknaden är den långt ifrån färdig. Enligt Sun Microsystems återstår då fortfarande 80 % av mjukvarans slutgiltiga totalkostnad 2. Denna kostnad går exempelvis åt till underhåll i form av säkerhetsuppdateringar, nya efterfrågade funktioner och rättning av buggar. Högkvalitativ kod kan dock sänka denna kostnad ordentligt, här är två exempel: 3 Högkvalitativ kod innebär att fler buggar kan hindras att komma med i en release. Högkvalitativ kod innebär att underhåll blir lättare att genomföra, tack vare att det blir lättare att förstå och ändra koden. I Extreme Programming ska hela teamet ha möjlighet förstå all kod, hela tiden, då Collective Code Ownership 4 tillämpas. Ska utvecklarna kunna ändra i de delar av koden som de inte skrivit själva, förutsätts att all kod är högkvalitativ hela tiden. Arbete för att hålla koden ren måste utföras kontinuerligt under hela projektets gång. Vana programmerare vet att ju mer programmet växer under projektets gång och ju mer rader det består av, desto större blir behovet av kodkvalitet. Om inte arbetskraft avsätts för att hålla koden på en begriplig nivå är det troligt att teamet så småningom kommer att gå vilse i djungeln av duplicerade funktioner, missvisande variabelnamn, oanvända kodstycken, inaktuella kommentarer, med mera. En fördel som kommer på köpet när man håller kodkvaliteten hög är att det blir betydligt lättare att se hur implementeringen av en ny story 5 kommer att påverka koden. Detta eftersom programmets struktur blir mer tydlig, det blir lättare att veta var förändringarna behöver göras och veta vad som kan gå fel. Tack vare detta blir det också lättare att estimera hur lång tid det kommer att ta att integrera denna nya story i systemet. Hög kodkvalitet underlättar alltså även trackingarbetet. 2 Exempel taget från [2]. 3 Ibid. 4 XP, [1]. 5 Ibid. 4

5 2.3 Varför inte? Trots att allt kan verka hur bra som helst när man tittar på ovanstående argument så finns det fortfarande många motkrafter i ett arbetslag när det gäller att lägga ner arbete på kodkvalitet. Den absolut hetaste frågan är nog: kan man lägga ner arbete på kodkvalitet utan bekostnad av funktionalitet?. Här följer några motkrafter som man ofta möter i en arbetsmiljö där man sysslar med programvaruutveckling Snygg kod kostar funktionalitet Att skriva snygg kod är bara slöseri med tid, man förlorar stories. Den typiska kunden ser oftast inte några direkta fördelar med högkvalitativ kod, varför då betala för det? Kunden bryr ju sig trots allt först och främst om att få med alla funktioner han vill ha till ett så lågt pris som möjligt, och vad kan då vara bättre än att implementera alla features rakt upp och ner, så fort som möjligt? Den här kunden är alltså inte tillräckligt insatt i utvecklingsprocessen för att förstå att de fördelar vi tittat på tidigare gör utvecklingen pålitligare i längden. Här gäller det att sätta tillräckliga gränser gentemot kunden för att kunna ge tid åt det underhåll koden kräver för en effektiv och hållbar programutveckling. Även en utvecklare kan ha denna attityd. Ofta beror det på att de ser det som ett besvär att till exempel refaktorisera 7, och att det inte är en lika tillfredsställande arbetsuppgift som det är att implementera en ny funktion. En utvecklare med denna åsikt inser förhoppningsvis snart hur kvalitativ kod hjälper till med programmets utveckling. Förslag och erfarenheter på om hur man kan bekämpa denna negativa inställning kommer vi att diskutera i avsnitt Stilkrockar Alla har olika standarder utom jag. Ett team som är fullt upplyst med kodkvalitetens fördelar kan fortfarande stöta på problem. Folk kan vara fullt medvetna om att de måste tänka på kodens utseende, men ha alltför olika uppfattning om vad snygg kod egentligen är. Sättet att programmera på kan vara djupt präglat i en persons sätt att arbeta. Att få denne att ändra sig för att uppnå enighet med övriga utvecklare kan vara mycket svårt. Det kan till exempel röra sig om: Olika sätt att sätta parenteser, mellanslag och radbrytningar. Olika synpunkter på hur metod- och variabelnamn ska väljas. Olika sätt att kommentera och dokumentera. Olika uppfattning om mjukvarudesign, om vad som är bra objektorientering, fula lösningar etc. 6 Dessa motkrafter följer av våra erfarenheter från många programvaruprojekt, bland annat kurserna Programvaruutveckling i Grupp och Coaching av Programvaruteam. 7 Från XP:s practice Refactoring, [1]. 5

6 Att arbeta i ett team innebär att man måste anpassa sig. Denna inställning måste alla teammedlemmar visa att de har tagit till sig för att kunna platsa i laget. I våra undersökningar av olika team under projektens gång framgick märkbara problem med personliga stilar, anpassningar till konventioner samt svårigheter att förstå varandras kod. Mer om hur man löser problem av denna typ berättar vi längre fram i denna djupstudie Lathet Äsch, jag diskar senare. Det nämndes tidigare att ett XP-projekt ofta är i behov av kontinuerligt underhåll av kodens kvalitet. En tydlig kraft som uppdagar sig här är inställningen att det är okej att skjuta upp förbättrandet av kodens kvalitet till ett senare tillfälle. Det kan jämföras med att diska: Man vet att om man diskar direkt efter maten så kommer det aldrig att bli särskilt mycket disk som ligger i vägen i köket. Det är dessutom mycket lättare att diska när det inte är fullt på diskbänken. Ändå sparar man ofta arbetet till senare med resultatet att det blir svårare att laga mat nästa gång. I ett programvaruprojekt läggs det ner mycket jobb på att städa upp denna röra. Om man skjuter arbetet på hög framför sig blir det större än om man delar upp det och tar hand om det i mindre delar kontinuerligt under utvecklingen. Vi har i våra undersökningar märkt att de flesta utvecklare tidigt inser vikten av att följa de practices som ingår i XP. Samtidigt intygar deras coacher ändå att många practices inte följs. Vi ska längre fram ge förslag på hur man motiverar ett kontinuerligt arbete för god kodkvalitet. 3 Hur får man ett team att skapa högkvalitativ kod? Nu har vi räknat upp några krafter för och emot kvalitet i koden. Nästa steg är att reda ut vad man kan göra för att styra processen åt det positiva hållet. 3.1 Cult of Code Quality De berömda coacherna DeMarco & Lister beskriver ett fenomen de kallar Cult of Quality. Med detta menas ett teams överenskommelse att endast det bästa duger. Något som är förödande för en grupps lagkänsla är nämligen att kämpa efter ett mål tillsammans, för att sedan konstatera att det bara nästan uppnåddes. Det är också viktigt att teammedlemmarna strävar efter samma mål, och att alla i gruppen arbetar för att uppnå det. Den som känner sig ensam i sina ansträngningar att alltid göra sitt bästa kommer förmodligen snart att sluta anstränga sig också. 8 Ovan nämnda fenomen känner vi igen från det oändliga arbetet med att hålla koden snygg. En lösning på detta skulle alltså vara att aldrig nöja sig med något sämre än perfekt. Genom inspiration av konceptet Cult of Quality finner vi ett intressant angreppssätt på problemet att utvecklare sällan mäktar att hålla koden snygg i längden: Om vi från start försöker skapa en Cult of Code Quality borde förutsättningarna för att hålla koden ren bli mycket bättre. Med begreppet Cult of Code Quality menar vi följaktligen att gruppen har en överenskommelse om att huvudmålet är att skriva snygg och högkvalitativ kod efter 8 DeMarco & Lister, [5]. 6

7 konstens alla regler. Här nöjer man sig aldrig med någon sämre än det bästa, för det är det enda sättet man vill ha det på. Motiveringarna för detta är inte svåra att inse och kommer att tas upp under avsnittet Samla ambitionerna. 3.2 Gruppens Motivation Coaching Practices Det viktigaste för att uppnå ett visst mål inom teamet är att individerna tar till sig detta mål som sitt eget. Detta kan nog vara lika svårt att få att hända som det är effektivt när det väl händer. Hur förklarar man för en grupp utvecklare att de måste lägga ner tid på kodkvalitet? Hur får man dem att bli motiverade att arbeta med att göra koden enkel och lättbegriplig, istället för att se det som ett hinder för att fortsätta implementera ny funktionalitet? Genomgående för vad man kan göra för kodkvaliteten är att allting handlar om gruppen som helhet. Kodkvaliteten är inte en fristående enhet, utan något som genomsyrar alla områden av projektet. Collective Code Ownership och andra Extreme Programmingpractices gör att teamet måste agera som ett team på den här punkten, annars motarbetar det sig självt. Det är svårt att utse en kodkvalitetsexpert i gruppen som sköter frågor om kodkvalitet utan att övriga behöver tänka på det. Istället måste alla utvecklare sköta om kodkvaliteten, hela tiden. Därför är vi intresserade av några sätt att samla ambitionen i teamet. Inte heller blir resultatet tillfredsställande om de olika utvecklarna har olika syn på vad kodkvalitet är, eller hur man uppnår det. För minsta möjliga friktion och största möjliga kvalitet krävs det föga överraskande en stor gemensam medvetenhet i teamet för att nå detta gemensamma mål. Detta kan man eftersträva på olika sätt. Slutligen finns det en practice som är ytterst vital för kodkvaliteten. XP:s practice Refactoring 9 innebär att snygga upp koden utan att ändra dess externa funktionalitet. Exakt hur man gör det är oftast specifikt för varje tillfälle, men vi har tagit vara på några ganska allmänna refaktoriseringstrategier som en coach kan införa i teamet. I de följande tre avsnitten tänker vi redogöra för metoder vi experimenterat med i vårt team och sammanfatta våra erfarenheter från det. 3.3 Samla ambitionerna Oavsett vad det är för mål teamet strävar efter är det riktigt effektivt med en samlad ambition för att nå dit. Om vi vill skapa en Cult of Code Quality med målet att producera kod av hög kvalitet något som verkligen ska omfatta alla delar av både teamet och projektet är ambitionerna för detta det första vi måste ta itu med. Att samla ambitionen är av erfarenhet något som verkligen äter tid under mötena i allmänhet och under det första planeringsmötet i synnerhet. I våra experiment med detta som coacher för ett utvecklingsteam såg vi till att ta god tid på oss och därmed visa att detta är något vi tycker är värt teamets tid och uppmärksamhet. Inkörningsperioden var ganska trög och det märktes att det stora fokus vi lade på kodkvalitet var oväntat för teammedlemmarna. När teamet hade accepterat att vi satte värde på kodkvaliteten började 9 XP, [1]. Vi kallar detta för refaktorisering på svenska. 7

8 de emellertid själva göra det. Detta visade sig i form av att de uttryckte sina egna viljor angående ämnet, men också genom att försöka tillfredställa andras. Något att tänka på här är att inte klistra fast en hög ambition på teamet. Om man ska kunna upprätta en samlad ambition är det viktigt att den inte är påtvingad. Individerna måste själva känna att de har gjort detta val frivilligt. En coach har emellertid goda möjligheter att obemärkt styra teamet mot särskilt utvalda mål eller ambitioner. Från svaren på våra frågeformulär har vi kunnat skönja ett mönster av att utvecklarna inte fäster någon större uppmärksamhet vid att coacherna försöker påverka dem. Coacherna själva anser dock att de aktivt försöker påverka teamets mål gällande kodkvalitet. Detta fenomen kan tolkas som att arbetet med att hålla koden ren inte känns särskilt konkret eller uppmärksammat. Kanske har coacherna i dessa team fått arbetet med kodkvaliteten att kännas som ett självklart inslag i projektet. En annan tolkning av fenomenet kan vara att teammedlemmar i allmänhet omedvetet accepterar de mål som coacherna sätter upp. Det behöver då inte nödvändigtvis vara kodkvalitetsrelaterade practices. Man kan i så fall fråga sig var gränsen går för vad som är acceptabelt för teamet att samla sin ambition kring. När den samlade ambitionen väl är upprättad inför ett mål (högt eller lågt) som hela teamet tagit till sig, är den svår att störta Diskutera tidigt Bjud upp till diskussion om ämnet tidigt i projektet. Om man vill att teamet ska acceptera ett gemensamt mål är det viktigt att de känner sig delaktiga från början, att de har möjlighet att påverka. Red ut personliga tolkningar och gemensamma ambitioner. Låt alla komma till tals Motivera Sprid tankesättet att god kod lönar sig i längden. Motivera varför kvalitativ kod i längden underlättar på andra områden som exempelvis strävan efter funktionalitet och resultat: Förklara varför kvalitet effektiviserar: Visst kan det vara skönt att slippa tänka på just nu, men det skapar bättre förutsättningar för effektivt arbete i längden. Förklara varför kvalitet befriar: Du kan lättare underhålla andras kod utan deras hjälp och på samma vis binder du inte upp dig själv till att handha din egen kod utan kan dela med dig av arbetet Berätta historier Berätta historier om både bra och dåliga personliga erfarenheter inom ämnet. Detta ger utvecklarna en greppbar bild av vad de strävar efter eller undviker. Att be om underhållningsbar kod är bra. Att berätta en fasansfull historia om att bli uppringd för att få bakläxa på en bugg man var delaktig i för flera år sedan är mycket bättre. 8

9 3.4 Sprid medvetenheten Precis som att det krävs en samlad ambition och motivation för att vinna ett gemensamt mål, krävs det också en samlad medvetenhet om vad man håller på med inom projektet just nu. En genomgripande kraft mot att sprida kunskap och insyn inom olika områden är den naturliga metoden att tilldela en uppgift till den som bäst löser den. Detta märks tydligt i ett team när man fördelar stories. De som känner sig insatta i ett område angriper gärna problem inom sitt område hellre än utanför. Inget större fel med det, bara man inte låter det stagnera där. Problemen kommer att uppstå när alla snöat in sig på varsin del av projektet och inte förstår sig på varandras delar. Då är det långt till Collective Code Ownership och nära till att börja motarbeta varandra. Trots viss motvilja har vi gjort vårt bästa för att låta gruppmedlemmarna lära upp varandra, vilket vi ser som det enda sättet att i förlängningen upprätthålla både Cult of Code Quality, Simple Design 10 och Collective Code Ownership Redovisa JCC Låt någon av gruppmedlemmarna hålla en kort redovisning om Java Code Conventions på ett morgonmöte. Denna gruppmedlem får då en djupare kunskap inom ämnet när föredraget förbereds, samtidigt som hela gruppen får något att tänka på när de sedan sätter igång och arbetar. Det är mycket troligt att teamet kommer att framställa mycket mer kvalitativ kod denna dag Redovisa Simple Design Fortsätt enligt samma princip och låt någon annan gruppmedlem hålla en redovisning om Simple Design Redovisa arkitektur Är man speciellt ute efter att förbättra gruppmedlemmarnas kunskap om hela programvaran är det ett effektivt sätt att låta någon noga studera systemets arkitektur. Denna person kan sedan redovisa för gruppen för att på så sätt sprida kunskapen vidare. I XP är det lätt att då och då tappa greppet om hur programmets olika delar hänger ihop, eftersom alla har rätt att ändra överallt, och det är en god idé att återge dem denna kunskap Växla mitt i Växla paren när de är mitt uppe i något detta tvingar fram ömsesidig inlärning. Den person som arbetade med problemet innan kan lära den nyinbytte om hur denna del av programmet hänger ihop, för att han eller hon ska kunna få ett grepp om det aktuella problemet som ska lösas. Den nyinbytte i sin tur kommer med en ny fräsch syn på hur problemet ska lösas, och kan på så sätt lära den invande att tänka i andra banor, som dessutom kan ge erfarenhet inför framtida problemlösning. (Naturligtvis kan en coach hitta anledningar att inte växla par mitt i, till exempel om paret har väldigt bra flyt i arbetet.) 10 XP, [1]. 9

10 3.5 Refaktorisera smart Refaktorisering kan anses vara den i särklass mest betydelsefulla arbetsmetoden för att framställa högkvalitativ kod. Man kan se refaktorisering som det samlade namnet för att i efterhand snygga till kod som redan är skriven. Saken är alltså klar, vi ska refaktorisera. Några frågor som kvarstår för oss är: När ska vi refaktorisera? Vem ska genomföra refaktoriseringen? Hur mycket tid ska vi avsätta till refaktorisering? Om vi börjar med att titta tillbaka på metaforen att förbättra kod är som att diska, ser vi att vi vill refaktorisera i små iterationer, hellre för ofta än för sällan, för att undvika stora mängder arbete vid ett och samma tillfälle. På något sätt vill vi alltså integrera refaktoriseringen kontinuerligt med den övriga utvecklingen. Vi har också talat om att vi vill öka gruppens medvetenhet så mycket det går. Vi vill att alla i gruppen ska ha kunskap om programmets olika delar. Refaktoriseringen öppnar här en ypperlig möjlighet för teammedlemmar att sätta sig in i en del av koden som de inte tidigare känner till så väl. Dessutom är det bra att denna del granskas av en person som inte varit med och skrivit den, för att få en granskning från en ny synvinkel. Ingen kan säga exakt hur mycket tid man ska använda till refaktorisering, eftersom detta naturligtvis beror på en mängd faktorer, exempelvis programmets komplexitet, utvecklarnas skicklighet och erfarenhet vad gäller just refaktorisering eller hur mycket utvecklarna tänker på att skriva bra kod när de implementerar funktioner. Det vi däremot kan säga är att man bör avsätta en bestämd andel tid för refaktorisering. Denna andel bör anpassas för det aktuella projektet och för det aktuella teamet. Sedan bör man hitta ett sätt att effektivt utnyttja denna avsatta tid till just refaktorisering Refaktorisera varandras kod Växla par före refaktorisering. Byt ut en av utvecklarna i ett par till någon i teamet som aldrig sett den aktuella koden förut. Genom att refaktorisera varandras kod uppnår man direkt två stora mål: Dels blir den nya koden genast granskad, dels tvingas en tredje utvecklare att lära sig den nya koden Refaktorisera mellan iterationer Efter en iteration brukar det finnas mycket refaktorisering att göra som har känts svår att utföra under iterationen, på grund av att den berör hela projektet. I rädsla för att sabotera arbete för varandra brukar utvecklarna vänta med refaktoriseringen och samtidigt ängslas över refaktoriseringsskulden, som växer sig större alltmedan systemet växer. Låt därför utvecklarna också refaktorisera mellan iterationerna, som en spike 12. Ta hand om så mycket som möjligt av arbetet under iterationerna, gör sedan det som blir över mellan dem. Denna practice handlar alltså inte om att refaktorisera mellan iterationerna istället, utan att göra det då också. Undvik därför att planera refaktoriseringar mellan iterationerna, de är till för att arbeta undan det som oundvikligt blivit kvar efter iterationens slut. 11 Inspiration om refaktorisering hämtat från [3] och [4]. 12 XP, [1]. 10

11 3.5.3 Kulten kräver offer En utvecklare bryr sig om sin tidsplan. Innan varje iteration estimeras den tid man tror det kommer att ta för att implementera en story, och utvecklaren vill ofta visa att det klarades av på den tiden. Detta kan leda till att när en storys funktionalitet är klar och tiden är slut, skyndar utvecklaren vidare till nästa story. I vårt team uppskattades tiden en story skulle ta att implementera i enheten gummibjörnar. En sådan motsvarade till en början en arbetstimme för ett par, men så småningom skulle den komma att motsvara mer eller mindre tid, beroende på hur många gummibjörnar som hanns med under en iteration. Eftersom vi ville att utvecklarna trots tidsbrist ändå skulle dröja kvar och ägna lite omsorg och eftertanke åt den nyskrivna koden, offrade vi helt enkelt gummibjörnar till refaktorisering vid estimeringen för varje story, för att få med detta i tidsschemat. Vi skrev även upp denna nya refaktoriseringssiffra vid estimeringssiffran för hela storyn. På så sätt kunde utvecklaren fortfarande få kämpa för att hålla sin tidsplan för storyns funktionalitet, och sedan räkna refaktoriseringen av den nya koden som en ny tävling. 4 Resultat och slutsatser Som avslutning är vi nu redo att besvara några frågor vi ställt tidigare. Vi undrade tidigare om man kan lägga ner arbete på kodkvalitet utan bekostnad av funktionalitet. Hur gick det med funktionaliteten i vårt projekt? Lyckades vi med uppgiften att få gruppen fokuserad kring kodkvalitet? Kan vi säga att vårt team uppnådde en Cult of Code Quality? 4.1 Effektivitet Tyvärr är kursprojektet för kort för att se några giltiga resultat från att under en längre och mer verklig tidsrymd kämpa för en hög kodkvalitet. I skrivande stund ligger vårt team inte sämre till än något annat när det gäller antal implementerade stories. Men våra teammedlemmar anser att teamets kod är av högre kvalitet än de andra teamens. Med detta som underlag kan vi enligt våra teorier dra slutsatsen att projektet skulle ha en god chans vid en långsiktig vidareutveckling. 4.2 Cult of Code Quality? Utvecklarnas uppfattning om sin egen kods höga kvalitet är ett tydligt tecken på att de har tagit till sig kodkvaliteten som ett gemensamt mål. Vår studie gav tyvärr inte utrymme för att i efterhand utvärdera resultatet av deras ansträngningar. I skrivande stund vet utvecklarna inte någonting över huvud taget om våra explicita planer om Cult of Code Quality. Vi kan ändå konstatera att de metoder vi presenterat i denna studie lyckades väcka ett intresse för ämnet kodkvalitet, som faktiskt var större än vi förväntat oss till en början. Vi märke att utvecklarnas öga för snygg kod växte och vi tror och hoppas att vårt inflytande har med saken att göra. 11

12 4.3 Medvetenhet och ambitioner En slutsats från frågeformulären är att det inte finns några märkbara problem med att få utvecklarna i dessa team att inse vikten av XP:s practices. Inte heller är någon osäker på nyttan med hög kodkvalitet. Vi har ändå konstaterat problem med tillämpningarna av dessa practices. Detta beror förmodligen inte lika mycket på omedvetenhet som på ovilja och brist på motivation. Sviktande ambitioner är säkert ett beständigt problem i både studie- och arbetsmiljöer. Som coach för ett team kan man göra något åt det! Med hjälp av våra metoder har vi lyckats att höja ambitionsnivån när det gäller kodkvalitet. Tyvärr har vi lika stora problem som andra team när det gäller ambitioner att tillämpa flera andra practices som behövs inom teamet. 12

13 5 Referenser [1] Ron Jeffries. Extreme Programming Installed. Pearson Education Corporate Sales Division. New Jersey. [2] Sun Microsystems. Java Code Conventions. [3] Erik Norberg och Joakim Puusaari. Djupstudie: Refaktorisering i ett XP-projekt. [4] Aron Kornhall. Djupstudie: Refaktorisering i praktiken. [5] De Marco, Tom, Lister, Timothy, Peopleware. Productive Projects and Teams. 2 nd ed. Dorset House Publishing Co. New York. 13