Djupstudie Code smells / Refaktorisering. Martin Larsson dt08ml5 Stefan Johansson, dt08sj7

Transkript

1 Djupstudie Code smells / Refaktorisering Martin Larsson dt08ml5 Stefan Johansson, dt08sj7 27 februari 2012

2 Innehåll 1 Inledning 1 2 Bakgrund extreme programming Programvaruutveckling i grupp Refaktorisering Code Smells Kodkonventioner Simple design Verktyg Statisk kodanalys Findbugs PMD Checkstyle Viktiga fel Findbugs upptäckte Resultat 7 6 Slutsats 9 1

3 Sammanfattning Denna artikel tar upp hur man vid parallell kodutveckling i ett team identifierar aspekter i koden som kan leda till problem med den fortsatta utvecklingen av programvaran. För att automatisera processen att hitta problemen använder vi tre verktyg Checkstyle, PMD och Findbugs som vi introducerar till utvecklingsteamet. Vi kom fram till att dessa verktyg är en bra hjälp för att hålla koden i tillräkligt bra skick för att samarbetet inte ska stagnera och inget produceras. Men att introducera dem till PVG teamen är ingen bra idé då de redan har många nya saker att lära sig som är viktigare att fokusera och lägga tid på, även om verktygen hjälper till att skapa bra förutsättningar för korrekt och lättläst kod.

4 1 Inledning Alla som har läst kursen programvaruutveckling i grupp [13] på Lunds tekniska högskola(lth) har säkert någon gång under projektdelen av kursen upplevt hur det är att arbeta med kod som har stort behov av en refaktorisering. Att refaktorisera kod kan ibland vara svårt speciellt om man själv har skrivit koden. Då är det svårt att se vad som behöver göras. För att upptäcka problemområden i koden finns det ett antal olika verktyg som detekterar code smells genom statisk analys av byteoch källkod. Dessa kan ge programmeraren indikationer till var en refaktorisering kan behövas. Syftet med vår studie var således att hjälpa elever på kursen med refaktoriseringsarbetet. Planen var att först låta projektet fortskrida i några få veckor för att sedan när refaktoriseringsbehoven blev allt större introducera det verktyg vi fann mest nyttigt av de vi undersökt för att sen möjligtvis även introducera ytterligare verktyg allteftersom. Tanken var då att mäta hur antalet varningar och fel dom olika verktygen gav på projektet utvecklades gentemot ett team som inte använde sig av verktygen. Vårat resultat blev inte riktigt som vi förväntade oss men våra erfarenheter kan ändå ge insikt i hur väl dessa verktyg lämpar sig för ett projekt liknande det i kursen. 2 Bakgrund Den miljö som vi har använt för att utvärdera de verktyg vi har testat är projektdelen av kursen programvaruutveckling i grupp på LTH. Där använder sig ett antal utvecklingsgrupper med 8-10 programmerare i varje team sig av extreme Programing (XP) metoden. 2.1 extreme programming XP är en agil utvecklingsmetod som föreslogs av Kent Beck. Här beskrivs i korthet det som beck föreslår i hans bok [1]. Metoden bryter ned arbetet från den traditionella vattenfallsmodellen och som Beck själv beskriver det "Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the farflung future, XP programmers do all of these activities, a little at a time, throughout development." Sättet detta görs på baserar sig på följande 13 praktiker: Planning game Small releases Metaphor 1

5 Simple Design Tests Refactoring Pair Programing Continuous integration Collective ownership On-site customer 40-hour weeks Open workspace Just rules En av de viktigaste praktikerna är Tests som innebär att arbetet skall drivas framåt av testdriven utveckling. Det vill säga att skriva enhetstester som testar den funktionalitet som skall implementeras innan kod skrivs. Enhetstesterna finns sedan kvar genom hela utvecklingsprocessen som en hel testsvit som kan ge feedback på att eventuella ändringar i koden en utvecklare gjort inte förstört redan befintlig kod. Detta underlättar för en annan praktik, Collective ownership som säger att alla utvecklare får gå in och ändra i alla delar av koden. En annan viktig punkt är att alltid ha kunden som en del av teamet och använda sig av planning game. Planning game innebär att kunden skapar stories som beskriver en liten funktionalitet som den vill ha implementerad, teamet estimerar sen hur mycket tid det skulle ta att implementera funktionaliteten därefter får kunden plannera in stories för nästa iteration av utveckling teamet skall göra. Tack vare att man bara planerar för en iteration i taget är metoden väldigt anpassningsbar då kunden bara behöver skriva nya stories och prioritera dom till nästa iteration för att ändra riktning på projektet. 2.2 Programvaruutveckling i grupp Kursen programvaruutveckling i grupp ges på LTH för studenter som redan läst grundläggande programmering i java. Eleverna delas in i små utvecklingsteam med ungefär 8-10 medlemmar i varje grupp. Grupperna leds i sin tur utav 1 eller 2 äldre elever som går kursen coachning av programvaruteam [2]. Teamen får sen som uppgift att implementera ett tidtagningssystem för tävlingsformen enduro med ett antal förbestämda stories. För att få in XP praktiken med kund i teamet agerar en anställd på instutionen för datorvetenskap kund. En iteration av utvecklingen pågår i en vecka och består av ett två timmar långt planneringstillfälle och en heldag av gemensam utveckling. Under planneringstillfället estimerar teamet stories som kunden sen prioriterar inför nästa heldag med 2

6 utveckling. Här delas även spikeuppgifter ut till teammedlemmarna vilket innebär att under fyra timmar ska dom läsa på och experimentera kring något som kan vara till gagn för teamet under utvecklingen. Utvecklingen sker från då teamet sitter tillsammans i en och samma datorsal och utvecklar enligt XP metoden. 3 Refaktorisering Allt eftersom ett programvaruutvecklingsprojekt växer så blir kodbasen större. Detta leder till att utvecklare får svårare att ha en överblick över hela systemet vilket kan leda till att implementation av nya funktioner i programmet utför samma eller liknande funktion som redan existerande kod, och att utvecklarna hellre än att våga skriva om existerande kod och integrera lösningen i de omskrivna metoderna löser det genom att skriva kod som lappar ihop lösningen. Men det kan finnas fler orsaker till att kod kan behöva skrivas om, ifall utvecklarna inte har ett gemensamt vokabulär, policys för hur metoder och variabel ska döpas, och en gemensam kodkonvention för hur koden ska struktureras skapar det problem i koden. Kent Beck och Martin Fowler [3] har definerat något de kallar code smells som är mönster eller egenskaper i koden som kan ge indikation på att refaktorisering behövs. Enligt Kent Beck är refaktorisering [3]: Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a diciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written. Eftersom koden blir mer strukturerad och mindre omfattande för att koden skrivs om till att innefatta alla implementerade funktioner i samma kod istället för att bygga ut funktionaliteten inkrementellt utan att göra en enhetlig lösning så minskar risken för buggar i koden när utvecklarna har lättare att förstå hur koden är uppbyggd och fungerar. Eftersom XP metoden använder sig av test-first så är det lätt att efter en refaktorisering kontrollera så att funktionaliteten fortfarande är den samma genom att köra testen för koden. Nedanför tar vi upp tre aspekter som kan användas för att bedöma om koden behöver refaktoriseras eller inte. 3.1 Code Smells Det finns 22 stycken olika code smells definerade av Kent Beck och Martin Fowler [3]. Här tar vi upp några av de viktigaste och förklarar hur de kan åtgärdas. Duplicerad kod Om det finns upprepningar av samma kod mönster i en klass så borde den brytas ut till en separat metod som anropas av de metoder som 3

7 behöver använda sig av koden. Detta för att minska mängden källkod och göra det lättare att förstår vad kodavsnittet gör med ett bra metodnamn. Långa metoder Ifall en metod har blivit stor med många rader med kod blir det svårt att se på vilket sätt den fungerar och det blir svårt att införa ändringar i metoden. Lösningen är att man delar upp koden till mindre metoder som anropas i följd med namn som tydligt visar vad koden i metoden gör. Stor klass När ett program innehåller en klass med för mycket funktionalitet och ansvar blir det lätt svårt att se vad klassen är till för och hur den utför det. När sådan design används blir ofta klassen en central komponent som länkar samman övriga klasser och sköter kommunikationen däremellan. För att åtgärda detta bör klassen brytas ned i flera klasser som delar in och isolerar den stora klassens alla ansvarsområden. Lång parameter lista Om en metod har många inparametrar så minskar läsbarheten i metoden. Metodens funktion är mer komplex ju fler parametrar den tar in. För att minska antalet parametrar till en metod kan man lägga in dem i ett objekt som innehåller parametrarna och skicka in det objektet istället. Istället för att skapa ett nytt objekt kan man skicka in den anropande klassen till metoden med användning av this, varifrån alla attribut kan läsas. Shotgun Surgery När det görs en modifikation till en klass som påverkar resten av systemet på så sätt att för att ändringen ska fungera måste flera andra klasser ändras för att logiken är utspridd på flera klasser. Anledningen kan vara att man spridit ut logik över flera klasser istället för att låta en klass ha ett eget ansvarsområde. Det är en bra idé att isolera funktionalitet i ett program till enskilda klasser för att undvika att en ändring som genomförs resulterar till att man måste in i flera olika delar av systemet. Spekulativ generalitet Om en klass eller metod är skriven så generellt som möjligt för att utvecklaren vill förbereda och göra det lättare för möjliga kommande ändringar kommer koden innehålla onödiga satser och för komplex kod för uppgiften som koden faktiskt ska lösa. Det är många som tänker Tänk om vi sedan behöver... vilket gör att kodens struktur skrivs för att förutom lösa uppgiften dessutom har potential att med vissa modifikationer få ytterligare funktionalitet. Men enligt XP ska man implementera det enklaste som får koden att fungera, och sedan skriva om koden om nya krav på den faktiskt framkommer. 3.2 Kodkonventioner Code smells innefattar inte kodkonventioner eller att utvecklarna har ett gemensamt vokabulär som gör metod och variabelnamn självförklarande och minskar risken att missförstånd sker mellan utvecklarna. Att utvecklarna har en gemensam kodkonvention är viktigt för projekt som innefattar parallellt arbete i en större 4

8 kodbas. Om alla utvecklare använder sig av samma praxis för att skriva kod så kan en utvecklare i teamet lätt ta upp att jobba med kod som någon annan har skrivit[4]. Eftersom 40-80% av kostnaden att utveckla en programvara går åt till att underhålla koden[5] och att i de flesta fallen så är det inte grundutvecklarna som underhåller koden under hela livstiden [6], så är det viktigt att någon som ska sätta sig in i ny kod och inte behöver lägga tid på att förstå intetsägande variabel och metodnamn eller en struktur på koden som komplicerar snarare än underlättar inlärningen. En kodkonvention kan innefatta namnkonventioner, kommentarer och kodningsstil/strukturellt upplägg. 3.3 Simple design Simple design är ett XP koncept som går ut på att designen är den enklaste möjliga om den uppfyller de kriterier som Kent Beck tar upp i Extreme programming explained: embrace change. De är [7]: 1. Koden klarar alla test skrivna för den. 2. Har ingen duplicerad logik i klassen eller parallella klasshirarkier. 3. Tydligt förmedlar varje aspekt till programmeraren. 4. Har så få klasser och metoder som möjligt. Koden ska vara självförklarande och utgöra en stor del av kommunikationen mellan programmerare som jobbar i den gemensamma koden. I XP så växer designen fram allteftersom mer funktionalitet implementeras och designen som används ska vara den bästa för vad koden gör just då, utan att vara förberedd på framtida ändringar. För att sedan när mer kod tillkommer skrivas om så att alla klasser och metoder uppfyller de fyra kriterierna. 4 Verktyg I vår studie har vi valt att fokusera på 3 verktyg som samtliga använder sig av statisk kodanalys för att hitta problem i javakod som behöver refaktoriseras. De använder sig av tekniker för att identifiera problem inom code smells, kodkonventioner, buggar i koden, onödig kod och nestlade satser. För området simple design finns inget verktyg som identifierar möjliga problem då det är en högst situationsanpassad och subjektiv egenskap. Verktyget PMD arbetar med att finna problem med kod som är komplicerad, död, ineffektiv och duplicerad[8]. Checkstyle används för att kontrollera så att koden rent presentationsmässigt hålls ren. Man kan själv ställa in vilka egenskaper i koden man vill att checkstyle ska rapportera vilket kan användas för att kontrollera att kodkonventionen i koden följs[12]. Findbugs används för att upptäcka programmeringsmissar i koden som tex att ett returvärde inte tas till vara på eller mönster som tyder på eventuella fel eller missförstånd som programmeraren begått. 5

9 4.1 Statisk kodanalys Statisk kodanalys är en form av analys av programvara med en statisk kod som inte körs, gentemot dynamisk testning som används när ett program körs. Koden kan antingen vara källkoden till applikationen, byte kod eller objectkod genererad av programmet. Om buggar sedan hittas i den genererade koden så refereras problem koden till källkoden för att testarna ska kunna se vilken kod som orsakar felet. 4.2 Findbugs Findbugs är ett verktyg som analyserar statisk kod för att identifiera möjliga buggar i program skrivna i Java. Det utvecklades vid University of Maryland för att hitta rena programmeringsmisstag som även funnits i produktionskod[9]. Programmet är skrivet i Java och finns både som fristående program och plugin till Eclipse. Findbugs använder sig av mönster som generellt beskriver hur kod som kan ge upphov till buggar ser ut. Sökandet efter dessa mönster görs inte på källkoden utan på den genererade byte koden. Findbugs kan identifiera ca 300 olika buggar[10], som sedan kopplas till vilken källkod som orsakade buggen och visas upp grafiskt. Av de buggar som findbugs rapporterar kan upp till 50% vara falska positiva [4], men varje projekt skiljer sig åt så man måste först urskilja vilken typ av buggar som är relevanta. 4.3 PMD PMD är ett program som finns som plugin till eclipse, det använder sig av ett set av regler för att analysera java källkod statiskt [8]. Det detekterar då möjliga buggar eller felaktig syntax i koden. Det kan även med hjälp av sin Copy/Paste Detector(CPD) detektera duplicerad kod i projektet. CPD använder sig, i senare versioner av PMD, av Karp-Rabin string matchnings algoritm. Karp-Rabin utnyttjar hash värden för stringar för att snabbt beräkna likhet. Regelsettet som programmet använder är inte låst utan användare av programmet kan både lägga till och ta bort regler själv. De problem som PMD detekterar kommer i 3 olika typer, varningar, fel och information. Varningar och fel har i sin tur en nivåindelning för att ange hur allvarligt problemet är, med en normal nivå och en högre nivå. Förkortningen PMD står inte för något bestämt utan det är upp till användaren att läsa som den vill. 4.4 Checkstyle Checkstyle använder sig av statisk kontroll av java källkod för att kontrollera om den följer en kodkonvention som defineras i dess olika moduler av regler[12]. Som standardinställning kontrollerar det om koden följer Oracles kodkonventioner. Checkstyle letar inte efter buggar i koden utan kontrollerar snarare syntaxen så den är korrekt. Däremot har även detta program stöd för att hitta duplicerad kod. Som plugin till eclipse ger checkstyle antingen information varningar eller fel. 6

10 4.5 Viktiga fel Findbugs upptäckte Medans utvecklarna i teamet jobbade med att skriva kod så kontrollerade vi koden med findbugs. (och flera?) De buggar som inte var aktuella för projektet eller hade en marginell inverkan på koden lät vi vara, men om vi hittade allvarliga buggar så sa vi till teamet. De allvarliga buggar som vi hittade i koden var. Returvärden som inte togs omhand. public String trim(string str){ return str.trim(); } Metoden är avsedd att trimma bort mellanslag före och efter strängen. Men metoden trim() påverkar inte strängen som är ett objekt men en sträng är oföränderlig efter att den skapats. Vilket gör att metoden trim måste returnera ett värde som sen får skrivas till att pekas på av variabeln str. Användning av == för att jämföra strängar istället för.equals if(str1 == str2){ do.something(); } Vid jämförelse av två strängar hittade vi jämförelsen med == istället för.equals vilket inte ger önskad funktionalitet. Vid användning av == jämförs två objekt om de har samma objekt referens men vid användning av strängar vill man jämföra textvärdet de innheåller och därför använder man.equals. 5 Resultat Våra planer att föra in Findbugs, Checkstyle och PMD till teamet för att på så sätt minska antalet buggar i koden la vi på is efter att givit två teammedlemmar som spike att ta reda på vad findbugs gör och hur det kan användas i vårt projekt, och presentera det för gruppen. Presentationen av pluginen fick inte mycket uppmärksamhet då många av medlemmarna säkert tyckte att det var något som skulle ta tid ifrån implementationen av Storys. Efter att vi coacher märkt att det inte användes bestämde oss för att det fanns viktigare saker teamet behövde fokusera på. Vi körde sen själva Findbugs och PMD på repositoriet efter varje commit för att se hur snabbt felen i koden ökade och när vi hittade något så allvarligt som tex returvärden som inte togs omhand så påpekade vi dem till teamet men lät alla mindre varningar vara. Vi har samanställt en graf över hur utvecklingen av varningar har förändrats allteftersom repositoriet uppdaterats med nya versioner. 7

11 8

12 Pikarna på slutet i framförallt findbugs tror vi beror på att teamet inte gjorde någon slutgiltig refaktorisering av projektet när det led mot sitt slut. De som återfinns i grafen med pmd-violations/kloc tror vi beror på merges av större brancher med påföljande refaktoriseringar. I denna graf råder det också stor osäkerhet på alla värden initialt då antalet rader kod är väldigt få men dessa stabiliseras senare och man kan se en smått nedåt trend då teamet blir bättre på att skriva kod. 6 Slutsats Även om verktygen inte mottogs särskilt bra i teamen av varierande orsaker anser vi ändå att dom kan vara användbara. Som coacher var det ett par gånger vi kunde poängtera ut delar av koden som innehöll buggar som programmen upptäckte, dessa var bland annat jämförelse av strängar i java med == i stället för equals metoden. Detta gör att vi gärna rekomenderar i alla fall FindBugs och till viss mån PMD till framtida coacher i liknande projekt för att användas till att få en bra överblick av koden och eventuela problemområden. Vi kan även tänka oss att själva använda programmen i framtida utvecklingsprojekt vi är del av för att hitta problem och refaktoriserings områden, men att för temmedlemmarna på PVG kursen finns det viktigare saker att lära sig inom att arbeta i grupp med programvaruutveckling. Även om de verktyg vi har testat förbättrar den gemensama kodbasen och på så sätt förbättrar utvecklingstakten och förståelse för koden i gruppen genom att koden är mer lättläslig, är det svårt att integrera användandet av verktygen om de ser det som en börda och inte som ett hjälpmedel. 9

13 Om introduktionsdelen i kursen presenterade något eller några av dessa verktyg till teamen redan innan, till exempel under en labb, och förklarade vad nyttan var och på vilket sätt de kan hjälpa utvecklarna så hade de nog varit mer villiga att se det som en del i utvecklingsarbetet. Referenser [1] Beck, K., Embracing change with extreme programming, Computer, vol.32, no.10, pp.70-77, Oct 1999,doi: / [2] Hedin, G.; Bendix, L.; Magnusson, B.;, Introducing software engineering by means of extreme programming, International Conference on Software Engineering, Proceedings. 25th, vol., no., pp , 3-10 May 2003 doi: /ICSE [3] Martin Fowler,Kent Beck, Refactoring: improving the design of existing code,addison-weasly, 1999 [4] Eva Van Emden et. al, Java Quality Assurance by Detecting Code Smells, Ninth Working Conference on Reverse Engineering, Proceedings. [5] Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003 [6] Coding_Conventions, publicerad 9 Februari 2012, [7] Kent Beck, Extreme programming explained: embrace change, Addison- Weasly, 2000 [8] sourceforge.net, PMD, publicerad 31 Januari 2012, [9] Jeffrey S. Foster, Improving Software Quality with Static Analysis, University of Maryland: College Park, MD, 2007 [10] Ayewah, N. Pugh, W. et. al, Using Static Analysis to Find Bugs, University of Maryland, 2008 [11] findbugs.sourceforge.net, Findbugs Fact sheet, , [12] sourceforge.net, publicerad 5 November 2011, [13] publicerad 24 Januari 2012,