Kodkomplexitet i agil utveckling. Axel Nilsson Svegard, Patrick Fogwall EDA270 - Djupstudie 2 mars 2010

Transkript

1 Kodkomplexitet i agil utveckling Axel Nilsson Svegard, Patrick Fogwall EDA270 - Djupstudie 2 mars 2010

2 Sammanfattning Denna studie avser att undersöka hur uppmätning av kodkomplexitet kan användas för att förbättra utvecklingsprocessen i agila metoder. Detta genom att studera hur kodkomplexiteten förändras med tiden i ett agilt (XP) projekt. Olika mått på komplexitet tas upp samt hur dessa kan kopplas till de upplevda problem som finns i projektet. En kontinuerlig mätning av komplexitetsmått kan användas för att undvika och minska oroande trender i utvecklingen. Nyckelord Agile, Cyclomatic Complexity, Kodkomplexitet, Metrics Innehåll 1 Introduktion 3 2 Kodkomplexitet McCabes Cyclomatic Complexity CK Metrics Suite Weighted Methods per Class Depth of Inheritance Tree Number of Children Coupling Between Object Lack of Cohesion of Methods Method Lines of Code Number of Methods Nested Block Depth Verktyg för datainsamling Metrics för Eclipse State of Flow Val av verktyg Kodkomplexitet i agila metoder Simple Design Refactoring Agile Design Test Driven Development Observation av kodkomplexitet i projektet Beskrivning av projektet Datainsamling Utveckling med tiden Åtgärder Diskussion Andra team Rekommendation för coacher

3 1 Introduktion Denna artikel tar upp olika mått på kodkomplexitet och hur dessa kan användas i och påverkas av en agil process. Grunden till området kring komplexitet i mjukvaruutveckling lades av Thomas McCabe som 1976 skrev A Complexity Measure [6] som främst behandlar ett mått på kodkomplexitet kallad Cyclomatic Complexity. Detta mått är fortfarande ett av de vanligaste för att beskriva komplexiteten i kod även om det med tiden framkommit även andra mått. McCabes cyklomatiska komplexitet och andra metoder beskrivs mer utförligt i avsnitt 2. Artikeln kommer även att studera hur kodkomplexiteten i ett agilt projekt (härefter kallat projektet) för ett team av åtta utvecklare utvecklas med tiden 1. I den agila metoden finns moment avsedda för att hålla koden överskådlig och överlag enkel, något som skulle kunna bidra till en mindre komplex kodbas. Se avsnitt 5 för en detaljerad beskrivning. 2 Kodkomplexitet När McCabe introducerade sitt mått på kodkomplexitet 1976 fanns få metoder för att mäta komplexitet i skriven kod, det vill säga mått på hur lätt det är att förstå och testa koden. Dessa mått var även ytterst bristfälliga. Ett exempel som tas upp beskriver hur det fysiska antalet rader kod begränsades för att metoder inte skulle bli alltför komplexa. IBM-50 lines var en sådan metod, som begränsade till 50 rader kod. I ett sådant fall skulle det ändå kunna finnas 25 efterföljande If-Then satser, vilket kan ge upp till 33,5 miljoner möjliga flöden genom koden - vilket gör programmet ytterst svårt att testa fullständigt [6]. Detta var något som McCabe avsåg att motverka genom introduktionen av måttet Cyclomatic Complexity (CC). Chidamber och Kemerer beskrev 1994 i [3] en ny uppsättning metrics med fokus på objektorienterad utveckling - populärt benämnt the CK metrics suite. I moderna projekt, som ofta är just objektorienterade, är dessa nya mått bra för att undvika klasser och metoder som tyngs av onödig komplexitet. Måtten som ingår i sviten är Weighted Methods per Class (WMC), Depth of Inheritance Tree (DIT), Number of Children (NOC), Coupling between Objects (CBO), Lack of Cohesion of Methods (LCOM) och Response for a Class (RFC). Verktyget för uppmätning av kodkomplexitet saknade stöd för RFC, varför detta mått saknas i 5.2. Övriga mått beskrivs nedan. 2.1 McCabes Cyclomatic Complexity McCabes metod baseras på riktade grafer och beror på inblandade noder, bågar och kopplade komponenter [6]. McCabes CC beräknas genom att summera antalet bågar (E), subtrahera bort antalet noder (N) och addera dubbla antalet kopplade komponenter (P). Bågar i detta sammanhang avser flödesväg från ett tillstånd till ett annat. Noderna betecknar dessa tillstånd. Ett tillstånd kan ses som ett block i koden (visas som cirklar i grafer) eller ett boolskt villkor (visas som diamantformer). Till exempel har en If-Then-Else-sats två skilda block. Kopplade komponenter avser ett begrepp inom grafteori som beskriver 1 Projektet är ett nedskalat projekt enligt extreme Programming (XP) metodik. 3

4 hur många delgrafer hela grafen består av, t.ex. så kan ett huvudprogram anropa (sekvensiellt) två subrutiner, se figur 2. I detta fall är antalet kopplade komponenter tre. Formeln för beräkning är som följer: CC = E N + 2P. McCabes CC är ett behjälpligt mått vid testning av programvara, då det ger ett mått på hur många flödesvägar det finns genom koden. Något som kan ge en antydan om hur svårt det kan vara att testa en metod, klass eller ett program. Nedan följer några exempel med grafer och motsvarande cyklomatiska komplexitet. (a) If-sats, CC = = 2 (b) While-loop, CC = = 2 Figur 1: Två exempel på typiska logiska satser och motsvarande CC Figur 2: Ett exempel på en huvudrutin och två subrutiner, CC = CC(M) + CC(A) + CC(B) = CK Metrics Suite Weighted Methods per Class Weighted Methods per Class är en objektorienterad metod för beräkning av komplexiteten hos en klass [3]. WMC är summan av komplexiteter i en klass, vilket innebär att en klass innehållande tre raka metoder (inga villkorssatser) får WMC = 3. Begreppet komplexitet är avsiktligt vagt valt för att tillåta en generell applicering av metoden. Som exempel på komplexitetsmått kan t.ex. tidigare nämnda CC användas. 4

5 Ett högt mått på WMC kan antingen betyda att klassen består av få komplexa metoder eller ett stort antal enkla metoder, eller givetvis en kombination av de båda. Många enkla metoder behöver inte betyda att komplexiteten är låg, det kan vara svårt att följa hur metoderna interagerar, vilket kan tyda på dålig arkitektur och försvåra testning. WMC kan vara bra att använda för att visa vilka klasser som kan kräva extra mycket tid vid testning och vidareutveckling av funktionalitet. På detta sätt kan potentiella orosmoment upptäckas i ett tidigare skede. Definitionen av WMC följer nedan. W MC = Depth of Inheritance Tree Depth of Inheritance Tree är ett mått på hur långt ner i klass-hierarkin en klass befinner sig [3]. Ju fler arv det finns ovanför klassen i hierarkin, desto fler metoder finns förmodligen ärvda, vilket gör det svårare att förutsäga beteenden hos klassen. Klasser långt ner i klassträdet har större risk för återanvändna metoder och det finns även fler metoder och klasser inblandade, något som kan resultera i komplexa samband Number of Children Number of Children är ett mått relaterat till att ju fler barn en klass har, desto större blir återanvändningen av metoder på grund av arvet [3]. Ett stort antal barn kan även tyda på felaktig abstraktion av föräldern. Siffran för NOC ger också en fingervisning på vilken inverkan klassen har på den övergripande designen Coupling Between Object Coupling Between Object anger antalet klasser som den aktuella klassen är kopplade till [3]. En hög CBO kan göra klassen svårare att återanvända i ett annat område, samt göra testningen svårare [7]. I senare avsnitt då detta mäts görs skillnad på Efferent CBO och Afferent CBO, vilket omnämns i [7]. Efferent CBO anger antalet klasser inuti ett paket som beror på klasser utanför paketet. Afferent CBO anger antalet klasser utanför ett paket som beror på klasser inuti paketet Lack of Cohesion of Methods Lack of Cohesion of Methods ger ett mått på sammanhållning av en klass [3]. Sammanhållning avser i det här fallet hur väl klassen faller in under Single responsiblity principle, det vill säga att en klass bör endast ha ett skäl för förändring [5]. Det kan hända att en klass i själva verket är en abstraktion av flera saker, i sådana fall är sammanhållningen förmodligen liten, och klassen bör delas upp. LCOM beräknas i detta fall enligt den så kallade Henderson-Sellersmetoden 2. Ett lågt värde tyder på en väl sammanhållen klass och ett värde nära 2 En normerad variant på den LCOM-metod som ursprungligen formulerades som en del av CK-sviten n i=1 c i 5

6 ett på att en klass borde delas upp i ett antal andra klasser eller subklasser [7] Method Lines of Code Method Lines of Code anger som namnet säger antalet rader kod (ej kommentarer och blanka rader) för metoder [3] Number of Methods Number of Methods är som namnet beskriver en siffra på antalet metoder [3]. Ett stort antal metoder kan göra koden mer lättläslig, men samtidigt försämra prestandan på grund av många metodanrop [7] Nested Block Depth Nested Block Depth är mått som ger djupet för kodblock, så som if-satser och loopar [3]. Ett stort djup kan göra koden svårläslig och vara tecken på alltför komplexa lösningar [7]. 3 Verktyg för datainsamling Då kursprojektet 3 använde Eclipse 4 som utvecklingsmiljö, har fokus legat på att använda verktyg anpassade för detta gränssnitt. I studien ansågs verktyget Metrics 5 (version 1.3.6) ge bäst information till studien kring kodkomplexitet. Verktyget ger även data som inte är direkt relaterat till kodkomplexitet, som dock kan komma till nytta vid annan användning. De utvalda måtten till studien finns beskrivna i avsnitt 2 och gavs alla av nämnda verktyg. 3.1 Metrics för Eclipse Metrics tar fram olika mått på den insamlade datan där detta är möjligt. Dessa värden är totalvärde, medelvärde, standardavvikelse och maximalt värde. Datan är även tillgänglig på en lägre nivå - för enskilda paket, klasser och metoder. Programmet ger därmed en bra överblick för såväl hela systemet som för de mindre komponenterna. Metrics kommer även med en graf som beskriver beroendet mellan paket. Detta kan användas för att upptäcka cirkulära beroenden bland paket. Funktionen känns inte helt färdig och lämnar en del att önska, så som fler valmöjligheter och vyer inuti paket och klasser. Funktionen kan i sammanhanget mest ses som en kul grej och tillförde inte mycket till studien. En sak som kunde ha varit bättre med verktyget är möjligheterna för exportering. Det som stöds är export i XML-format, vilket kräver att formatering (eller transformering) i efterhand. Formatet är även sådant att inte alla medelvärden är givna, något som även då måste göras i efterhand. Transformering av resultatet kan göras med så kallade XSL-scheman, vilket dessvärre ligger utanför författarnas kunnande. 3 Projektdelen i kursen Programvaruutveckling i Grupp IDE för Java-utveckling med stora tilläggsmöjligheter Eclipse-plugin för metricsinsamling 6

7 3.2 State of Flow Ett annat verktyg som testades var State of Flow 6 (SOF) som även det gav värden på McCabes CC och andra komplexitetsmått för klasser. Dessvärre var datan från detta verktyg mindre överskådlig och därför svårare att tolka och använda. Inga medelvärden för paket och klasser fanns beräknade, vilket gjorde verktyget mest användbart på enskilda metoder. Noterbart är dock att värdena angivna av detta verktyg inte stämde överrens med det ovan nämnda Metrics. Detta tyder på att olike implementationer av algoritmerna använts. Till exempel fås komplexiteten för ett metodanrop med en switch-case-sats till elva för SOF och tolv för Metrics. 3.3 Val av verktyg I avsnitt 5 används värden uppmätta med hjälp av Metrics om inget annat specificerats, detta då verktyget var mer lättanvänt och ansågs strängare än SOF. Beslutet togs även tidigt i studien, varför ingen data samlats in med det senare verktyget. 4 Kodkomplexitet i agila metoder 4.1 Simple Design Agil utveckling bygger på flexibilitet och möjlighet att enkelt kunna hantera förändringar på ett smidigt sätt. För att detta skall vara möjligt måste använda Simple Design, implementera den absolut enklaste saken som kan fungera [1]. Enkel kod är enklare att förstå, förklara, testa, underhålla och förändra vilket i sin tur borde medföra lägre kodkomplexitet. 4.2 Refactoring Ett viktigt inslag i agila metoder är kontinuerlig refaktorisering, så väl efter varje enhetsimplementation som efter större integreringar. Refaktoriseringar utförs inkrementellt för att inte införa stora förändringar till den gemensamma kodbasen. En refaktorisering innebär även att koden blir mer lättläslig och att en bättre lösning på problemet införs samtidigt som funktionaliteten består [1]. Ofta har IDE:t som används funktioner som underlättar refaktorisering, något som också medför mindre risk att den mänskliga faktorn stör operationen. Genom att utföra refaktorisering regelbundet, vilket hör till XP-metodiken, bör minska kodkomplexiteten då svårförståliga metoder delas upp i mindre och mer välskrivna metoder, där syftet av var och en är klart och dess ansvarsområde mindre. 4.3 Agile Design Med användning av agila metoder utvecklas helhetsbilden av systemet allt eftersom [5]. Detta då utvecklingen sker med vad som är aktuellt i åtanke. Planering för framtida funktionalitet hör inte till denna metodik, då det tar tid från det arbete som skall utföras. Den aktuella strukturen av systemet formas Eclipse-plugin för metricsinsamling 7

8 av de många små inkrement som utförs av respektive utvecklare genom hela utvecklingsprocessen. Det finns många faktorer som påverkar huruvida ett system håller en nivå där vidareutveckling är enkelt. Martin beskriver symptom för dålig design - Bad Smells - gällande agile design. Dessa följer nedan. Rigidity - Systemet är svårändrat, då en ändring framtvingar många ändringar i andra delar av systemet. Fragility - En ändring gör att systemet fallerar i delar som inte tycks ha någon anknytning till ändringen. Immobility - Systemet är svårt att dela upp i mindre komponenter vilket gör att det blir svårt att återanvända lösningar i andra projekt. Viscosity - Det är svårare att göra saker rätt än att göra dom fel. Needless Complexity - Systemdesignens grundläggande uppbyggnad innehåller saker som inte är till någon nytta. Needless Repetition - Designen innehåller redundant kod som skulle kunna förenas genom abstraktion. Opacity - Systemet är svårt att förstå och läsa och uttrycker inte intentionerna. Martin skriver att där designen hos ett traditionellt utvecklingsteam är mer eller mindre statisk och ytterst svårförändrad, så är systemdesignen hos ett agilt team i ständig rörelse och i varje iteration är designen anpassad för den funktionalitet som för tillfället har stöd [5]. De ovanstående begreppen relaterar till kodkomplexitet, då sådan kod ofta är svårförstålig och medför ovilja att genomföra stora ändringar i koden då beteendet kan vara svårt att förutsäga. Detta kan vara ett problem i det oerfarna utvecklarteam som denna studie följt. 4.4 Test Driven Development Test Driven Development (TDD) är en viktig hörnsten för agil utveckling som tyvärr missuppfattas allt för ofta. TDD har många fördelar vilket gör det lätt att missa det primära syftet med TDD vilket är design. Två vanliga misstag är att tro att TDD är samma sak som att använda automatiserade tester och att TDD betyder att alla test skall skrivas först [4]. Automatiserade tester hjälper utvecklingen mycket men förespråkarna för TDD har alltid varit tydliga med att poängtera att TDD handlar om design, inte testning [2]. Om man skriver alla tester först och sedan implementerar för att få igenom alla testerna så missar man det ursprungliga syftet med TDD, vilket är att utveckla allting i väldigt små och snabba test-kod iterationer. Att koda i små iterationer hjälper till att skriva enkel kod då man skriver så lite kod som möjligt för att få igenom ett litet test vilket kan ha en inverkan på kodkomplexitet. Ännu en viktig fördel med TDD är att utvecklarna blir tvingade att tänka igenom designen ordentligt för att skriva testet innan implementationen påbörjas, vilket även det kan ha en inverkan på kodkomplexitet. 8

9 5 Observation av kodkomplexitet i projektet 5.1 Beskrivning av projektet I projektet, som är av XP-typ, får åtta utvecklare chansen att utveckla ett tidtagningssystem för terrängmotorcykelsporten enduro 7. Utvecklarna har under utbildningen ej läst någon liknande kurs, vilket gör att de till en början kan vara ovana vid arbetssättet. Teamet om åtta utvecklare leds av två coacher som läser en annan kurs (Coachning av Programvaruteam) och som under projektets lopp skall utöva coachnings- och ledarskapspraktiker från teoridelen i samma kurs. Projektet består av sex iterationer som i sin tur består av en långlaboration om åtta timmar, ett planeringsmöte på två timmar samt individuella så kallade spikes 8 om fyra timmar för varje utvecklare. En iteration pågår under en läsvecka med nämnda moment utspridda under denna tid. 5.2 Datainsamling I slutet av varje långlaboration har data samlats in med det Metrics plug-in nämnt i avsnitt 3. Datan har sammanställts och efter varje laboration har en kort reflektion gjorts för att observera om den insamlade datan återspeglar projektet. Frågan som skall besvaras är huruvida de insamlade måtten på komplexitetet kan kopplas till de problem som upplevs i projektet. LOC Totalt Iteration Iteration Iteration Iteration Iteration Iteration Tabell 1: Totalt antal rader kod McCabes CC Max Medel Iteration Iteration Iteration Iteration Iteration Iteration Tabell 2: Cyclomatic Complexity WMC Max Medel Totalt Iteration Iteration Iteration Iteration Iteration Iteration Tabell 3: Weighted Methods per Class DIT Max Medel Iteration Iteration Iteration Iteration Iteration Iteration Tabell 4: Depth of Inheritance Tree En mer detaljerad beskrivning av sporten 8 Utforskande hemarbete med avsikt att ge utvecklaren fördjupad kunskap inom ett för projektet angeläget område 9

10 NOC Max Medel Iteration Iteration Iteration Iteration Iteration Iteration Tabell 5: Number of Children ACBO Max Medel Iteration Iteration Iteration Iteration Iteration Iteration Tabell 6: Afferent Coupling ECBO Max Medel Iteration Iteration Iteration Iteration Iteration Iteration Tabell 7: Efferent Coupling LCOM Max Medel Iteration Iteration Iteration Iteration Iteration Iteration Tabell 8: Lack of Cohesion of Methods MLC Max Medel Totalt Iteration Iteration Iteration Iteration Iteration Iteration Tabell 9: Method Lines of Code NBD Max Medel Iteration Iteration Iteration Iteration Iteration Iteration Tabell 10: Nested Block Depth 10

11 5.3 Utveckling med tiden Då projektet snabbt växer i storlek (se tabell 1) och att det för utvecklarna upplevs som viktigt att hinna med att implementera mycket funktionalitet, görs ibland lösningar som inte alltid är så väl genomtänkta och kan bryta mot delar av den tilltänkta XP-metodiken. Dock är utvecklarna, som tidigare nämnt, ovana vid arbetssättet och faller lätt in i gamla vanor. Det kan ses att kodkomplexiteten kontinuerligt ökar tills dess att en större refaktorisering genomförs, vilken förmodligen kunde ha minskats skulle utvecklarna lagt ner mer energi på de mindre refakoriseringar som är en del av TDD och simple design. Under iteration två var den cyklomatiska komplexiteten väldigt hög, se tabell 2. Detta berodde på att i synnerhet en metod för utskrift fick väldigt mycket ansvar, istället för att bryta ut delar av koden till mindre och mer lättförståliga metoder. Anledningen till detta var troligen att många utvecklare var inblandade i samma metod med flera olika stories, och i det här skedet av projektet var utvecklarna fortfarande rädda att ändra i kod skriven av andra. Med tiden blev dock detta bättre, och i princip alla kände sig slutligen bekväma med att ändra i befintlig kod skriven av andra. Som kan ses i tabell 1 ökade projektets storlek med nästan 100 % under iteration fyra, utan att för den delen ge stor ökning av olika komplexitetsmått. Detta kan bero på att en stor refaktoriseringsspike innan iteration tre fick utvecklarna att se fördelarna med att hålla komplexiteten låg under iterationerna. Därefter sågs inga stora toppar i komplexiteten, vilket tyder på att utvecklarna drog lärdom av tidigare problem. Det som kan ses i tabellerna är att måtten på CBO steg under iteration fyra, främst på grund av att ny funktionalitet krävde mycket interaktion mellan klasser i en arkitektur som från början inte var skapad med detta i åtanke. 5.4 Åtgärder Då data samlats in och granskats efter långlaborationernas slut har ibland höga värden för olika mått stått ut. Detta har sedan påpekats vid antingen planeringsmötet eller vid långlaborationens inledning, för att göra utvecklarna medvetna om dessa riskområden. Detta då utvecklarna själva inte använder verktyg för metricsinsamling under laborationerna. Utvecklarna har verkat ta till sig informationen och lagt ner lite extra arbete för att hålla nere komplexiteten i påpekade klasser. Dessvärre kan liknande problem dyka upp på andra ställen i projektet, vilket tyder på att utvecklarna inte fullt ut tänker på att skriva kod utan hög komplexitet. Detta kan även tyda på att utvecklarna inte helt följer XP-paradigmerna om simple design och refactoring. Påpekanden om riskområden gjordes främst i inledningen av projektet, då det inte funnits speciellt stora problem de senare iterationerna. Som tidigare nämnt verkar utvecklarna ha tagit till sig den information som givits, och arbetat för att hålla nere komplexiteten på egen hand i projektets senare skede. Detta har fungerat bra trots att utvecklarna inte använt verktyg för insamling av komplexitetsdata. Något som kan betyda att utvecklarna i ett projekt på denna skala inte är i behov av ett separat verktyg så länge de är medvetna om vilka problem som kan uppstå, skulle de förbise processen. En enkel lösning för att utvecklarna mer självständigt ska upptäcka och åtgärda komplexitetsproblem bör de själva ha möjlighet att samla in metrics. 11

12 Datainsamlingen och kontroll av komplexitet och eventuella åtgärder kan till exempel införas i kraven för när en story anses vara klar. På så sätt hålls komplexiteten låg och det åläggs coacherna mindre ansvar att ständigt upplysa om enskilda punkter. Då verktygen ger en bra överblick behöver detta inte nödvändigtvis ta lång tid. Eftersom problemen upptäcks tidigt blir åtgärderna även mindre i omfattning vilket ger momentet en plats i XP-metodikens korta iterationer. 6 Diskussion Att samla in data för kodkomplexitet går både snabbt och enkelt vilket gör att man kan kontinuerligt undersöka komplexiteten för ett projekt och använda det för att förhindra problem som uppstår på grund av för komplex kod. Under studien noterades det att komplexiteten fluktuerade mycket upp och ner istället för att hålla sig på en stabil nivå. Anledningen till den ostabila komplexiteten beror nog på utvecklarnas ovana vid agila metoder och bör kunna undvikas genom att följa processen bättre med tanke på simpel design och refaktorisering. Det var tydligt att topparna i kodkomplexitet skapade problem och utvecklingen kunde stanna av totalt i flera timmar då metoder med hög komplexitet var involverade. 6.1 Andra team Då projektet utfördes parallellt med tio andra team, kan vi i efterhand göra en jämförelse med hur komplexiteten ser ut i andra team, där coacherna inte undersökt kodkomplexitet under arbetets gång. Det visade sig att författarnas team (härefter kallat Teamet) låg långt fram i avseende på antal implementerade stories, vilket gjorde jämförelse svårt i vissa fall, då antalet rader kod skiljde sig kraftigt åt. Jämförelser gjordes med tre andra team. Två av dessa hade implementerat mellan 15 och 20 stories (hädanefter kallat Team A och Team B), medan det tredje teamet (Team C) låg på samma nivå som Teamet, det vill säga dryga 30 stories. I fallet med Team A och B avspeglades det totala antalet rader kod till antalet implementerade stories, och låg på ungefär samma nivå som Teamet vid iteration tre, både gällande antal rader och antalet implementerade stories. Därför har en jämförelse gjorts, för både tidpunkten för iteration tre samt för läget vid projektets fullbordan. I fallet med Team C som implementerat ungefär lika många stories som teamet kunde endast den senare jämförelsen göras, då de låg lika långt fram i utvecklingen som Teamet. Team A och B hade överlag väldigt jämnlik kodkomplexitet jämfört med Teamets slutprodukt, trots att Teamet hade nästan dubbelt så stor kodbas. Jämfört med Teamet under iteration tre låg Team A och B generellt lite sämre till i komplexitetsmåtten, även om det oftast inte rörde sig om några större skillnader. Team C hade som bekant ungefär lika många implementerade stories som Teamet, vilket gjorde deras lilla kodbas (drygt två tusen rader kod) förvånande. En faktor är deras förhållandevis lilla andel testfallskod, som utgjorde endast 25 % jämfört med Team A, B och Teamet som hade ungefär 50 % testfallskod. Ett högt maxvärde (15) för CC uppmärksammades i en klass som även stack ut i 12

13 andra områden, bland annat var även NBD hög. Som kanske kan inses var denna klass ytterst svårläst med många nästlade block och svårföljda flödesvägar. Övriga mått i projektet var ungefär i nivå med Teamets. Totalt sett ter det sig som att Teamet hade aningen lägre kodkomplexitet än de team som jämförelser gjorts med. Något som kan ses som logiskt. Huruvida det var coachernas inblandning och uppmätning av komplexitetsdata som medfört detta är dock svårt att säga. Detta då många faktorer spelar in, så som förkunskaper hos utvecklare, hur väl processen följs, individuell motivation och stämning i teamet. Skillnaderna var dock inte enorma, vilket kan tyda på att det inte får så stort inflytande i ett projekt på den här skalan. Problem kan även uppmärksammas av utvecklarna då de delar kodbasen och är beroende av koden är lättläst och lätt att förändra. Tillfälliga komplexitetshärdar bör därför upptäckas med tiden och åtgärdas. Dessa problem bör även kunna stävjas om viljan att följa XP-metodiken är hög. 6.2 Rekommendation för coacher Uppmätning av kodkomplexitet under kursprojektet kan ge en bra bild av orosmoment i projektet innan de ställer till allt för mycket problem. Det som krävs är då ett verktyg som kan ge sådan information på ett lättläst sätt och gärna med stöd för utvecklingsmiljön, till exempel som plugin till Eclipse. Nedan följer några enkla punkter att tänka på vid insamling av komplexitetsdata. Enkelt verktyg med bra exporteringsmöjligheter. Snabbkurs alternativt spike-arbete för utvecklarna kring kodkomplexitet i projektets inledning. Överblick av coacherna efter varje långlabb för att hitta eventuella riskzoner. Kontrollera höga värden, det kan vara testfall och annat som påverkar. Huruvida stor vikt bör läggas på detta område kan dock diskuteras. Projekts omfattning är sådan att utvecklarna själva snabbt bör upptäcka problem som hindrar fortsatt utveckling allt eftersom stories tillkommer. Kodkomplexitet kan vara bra för coacher att mäta vid sidan om, för att se till att kvaliteten på projektet hålls uppe. Så länge utvecklarna använder sig av kunskaper som lärts ut i tidigare kurser och i teoridelen av PVG-kursen bör inte ett behov finnas av ett sådant verktyg. Ännu ett moment i kursen kan leda till att utvecklare tyngs ytterligare i ett projekt som redan introducerar många nya begrepp och arbetssätt. Det kan också finnas en risk att ett för stort fokus läggs vid denna uppgift och att utvecklarna kommer ifrån kursens egentliga mål. Slarv eller bristande motivation kring de delmoment som XP-metodiken medför kan ge upphov till de dåliga lukter omnämnda i 4.3, vilka kan speglas i de komplexitetsmått som kan samlas in. Det kan därför vara en idé att som coach se över komplexiteten som en del av utvärdering om processen följs. Detta kan göras som ett parallellt arbete med uppmätning av Code Coverage 9 som ofta används av coacher som mått på hur väl teamen praktiserar test first. 9 Procent av kodbasen som körs igenom vid exekvering av testfall 13

14 Referenser [1] Beck, K. Embracing change with extreme programming. IEEE Computer Vol. 32 (1999). [2] Beck, K. Aim, fire. IEEE Software Vol. 18 (2001). [3] Chidamber, S., and Kemerer, C. A metrics suite for object oriented design. IEEE Transactions on Software Engineering Vol. 20 (1994). [4] Janzen, D., and Saiedian, H. Does test-driven development really improve software design quality. IEEE Software Vol. 25 (2008). [5] Martin, R. C. Agile Software Development, Principles, Patterns, and Practices. Pearson Education, Inc., [6] McCabe, T. A complexity measure. IEEE Transactions of Software Engineering Vol. 2 (1976). [7] Oliveira, M. F. S., et al. Software quality metrics and their impact on embedded software. In 5th International Workshop on Model-based Methodologies for Pervasive and Embedded Software (MOMPES 2008) (2008). 14