Verktyget FindBugs. Djupstudie i kursen EDA 270 Coachning av programvaruteam. Christofer Bach dt05cb6 Daniel Nilsson dt05dn4. Lunds Tekniska Högskola

Transkript

1 Verktyget FindBugs Djupstudie i kursen EDA 270 Coachning av programvaruteam Christofer Bach dt05cb6 Daniel Nilsson dt05dn4 Lunds Tekniska Högskola 15 feb 08

2 1. Sammanfattning Denna djupstudie kommer att handla om hjälpverktyget FindBugs. Vi har valt att diskutera dess användningsområde, hur man bör integrera det i ett projekt och vad för funktioner som man kan hitta i programmet. Vi har haft möjligheten att testa programmet på en grupp utvecklare, som fick hjälpa oss att svara på några frågor. Vi kommer att dra några mindre slutsatser om huruvida FindBugs verkligen hjälper till, samt några allmänna tips som berör programmet, användningsområden och integration. 2

3 Innehållsförteckning 1. Sammanfattning Inledning Bakgrund Frågeställning Findbugs Utgivare Allmänt om FindBugs Funktionalitet i Findbugs Findbugs i Projekt Varför ska man använda det? Hur/När ska man FindBugs användas, och av vem? Hur ska man hantera resultatet? Hur får man ett team att börja använda det? Utvärdering av Findbugs Frågor vi ställde till programvaruteamet Svar på frågeställning Egna uppfattningar under projektets gång Diskussion Slutsats Litteraturförteckning

4 2. Inledning Denna djupstudie kommer att handla om programmet Findbugs och hur det fungerar i anslutning till XP 1 programmering. Detta verktyg är ett statiskt kodanalysverktyg som används för att hitta buggar i javaprogram. Vi har till vår hjälp ett programvaruteam som kommer att testa att köra Findbugs i kombination med ett projekt som följer XP metodiken. Våra resultat är hämtade från ett frågeformulär som programvaruteamet fick svara på och att vi själva som observerat hur det gått för dem. 3. Bakgrund Anledningen till att vi valde att fördjupa oss i FindBugs var att vi hade testat det snabbt på ett tidigare projekt, och på så sätt öppnat upp ögonen för det. Vi visste inte riktigt hur bra det var eller hur mycket som egentligen var felrapporteringar, så detta ville vi ta reda på. Vi ville nu få ett svar och se om ett projekt verkligen kunde få användning av verktyget och om det kunde vara lämpligt att jobba med det i framtiden. Så huvudsyftet med rapporten blev att se om programmet var i vägen för utvecklarna eller om det hjälpte dem att skriva bättre kod, samt hitta fel i programmet. På så sätt kan vi dra en mindre slutsats om huruvida vi anser man bör använda programmet vid framtida programmeringsprojekt. 4. Frågeställning Hur fungerar FindBugs som komplement till XP s testning? Är TDD 2 tillräckligt för att bli av med mestadels av buggarna, eller kan Findbugs vara till hjälp? Vi vill se hur TDD och frekvent användande av FindBugs fungerar ihop och vi hoppas att få se en kod som ser ännu bättre ut än bara genom att använda TDD. Dessutom vill vi även se om programmerarna med hjälp av Findbugs kommer efter ett tag att lära sig att undvika buggarna som Findbugs berättar för oss. 1 Extreme Programming 2 Test Driven Development 4

5 5. Findbugs 5.1 Utgivare FindBugs är ett OpenSource program som går under licensen Lesser GNU Public Licens 3. Det är ett program som utvecklas och leds av en person som heter Bill Pugh (med några medhjälpare), som även är personen som starta projektet en gång i tiden. 5.2 Allmänt om FindBugs Man kan tro att FindBugs tittar på java koden i programmet för att hitta buggarna, men så är inte fallet. FindBugs tittar istället i de kompilerade.class filerna, vilket innebär att man inte behöver ha källkoden för att hitta buggar till ett program. Man behöver inte ens köra programmet för att det ska fungera. Eftersom FindBugs vill hitta så många potentiella buggar som möjligt, kommer det på grund av detta även en hel del falska buggar med(i praktiken dock under 50%). Vill du skriva till egna Detektorer (mönster för buggar), måste du vara bekant med Java Byte kod, då detta är det som används. 5.3 Funktionalitet i Findbugs Vi ska här berätta om en del av de olika saker som erbjuds av FindBugs: Det vi letar efter är ett analysprogram till vår kod, detta är precis vad FindBugs kan göra. Finns stöd för att köra det i Eclipse som plugin, du får på så sätt en liten insekt bredvid raden när det är något som blir fel (om du väljer att köra det automatiskt). I annat fall kan du välja att köra det när du själv vill. Ett väldokumenterat program med Javadoc och ett stort community som snabbt kan svara på frågor. Möjligheter att skapa egna Detektorer som körs med programmet. En Detektor är ett eget mönster som du vill låta programmet söka efter. Det är inte helt enkelt att skapa egna, men det finns exempel och instruktioner på deras hemsidan 4 som man kan följa. Även IBM har skrivit en guide 5. Exempel på buggar som FindBugs kan upptäcka är buffert overflow, ohanterade exceptions, nullpointers med mera. Följande två exempel är tagna från Grindstaff [1]: String astring = "bob"; astring.replace('b', 'p'); if(astring.equals("pop")); I detta första exempel skapas en sträng med texten bob. Det som händer sen är att programmeraren vill ersätta alla b med p. Därefter görs en koll om strängen nu är pop. Det som programmeraren har glömt är att replace() inte ersätter strängen som man vill ersätta tecken i, utan den skickar en ny sträng tillbaka findbug2/ 5

6 Person person = amap.get("bob"); if (person!= null) { person.updateaccesstime(); } String name = person.getname(); I detta andra exempel har programmeraren försökt hämta ut ett objekt ur en Map. Om objektet inte finns, kommer null att skickas tillbaka. FindBugs upptäcker här att du kollar ifall personen är null på ena stället, men att du glömt det i det andra.[1] 6. Findbugs i Projekt Vi har kört FindBugs i ett projektteam under 4 veckor för att skapa oss en uppfattning om huruvida det kan hjälpa oss att producera bättre kod. Vi vill här ge några tips som dels kommer från oss och dels kommer från andra som delar uppfattning om hur man bör använda det. Det är inte helt trivialt och vi hoppas här att kunna ge idéer och en klarare bild över hur man kan använda ett statiskt analysprogram i sina projekt. 6.1 Varför ska man använda det? Varför man ska använda sig av ett statiskt analysprogram så som FindBugs är ganska enkelt att inse. För det första kan alla göra fel och misstag, detta är ofta enkla fel som ett analysprogram kan upptäcka. Det tar inte vidare lång tid att låta programmet köra igenom koden och leverera en fullständig rapport på kända fel man kan ha gjort. Man kan också tänka sig att det är bra att ha en extra fallskärm när nya utvecklare kommer till projektet och inte kan den företagsspecifika koden så bra. Där kan man då ha skrivit egna detektorer och på så sätt undviker sådana misstag. FindBugs hittar tyvärr inte alla fel, men alla som kan hittas är guld värt för ett projekt. Dessutom är FindBugs väldigt enkelt att implementera i byggprocessen med hjälp av ANT script och filter[1]. När du väl har installerat programmet och fått igång dina egna detektorer, är kostnaden försvinnande då programmet dessutom är gratis. 6.2 Hur/När ska man FindBugs användas, och av vem? Det är inte helt självklart när och hur man borde använda detta analysprogram. Man skulle kunna tro att det bara är att installera på datorn man ska köra det på och sedan är det bra med det. Så är förvisso fallet, men enbart om du inte har några större krav än att få rapporter på alla buggar i som kan tänkas uppstå i hela projektet. Ska programmet vara nyttigt och användbart från start, bör man använda dess filterfunktioner för att avgränsa vilka filer/metoder och buggar som ska testas. Har man inställt på att allt ska testas, finns risken (som vi märkte i projektet) att buggar/varningar du är medveten om och valt att göra, stör dig och gör att du inte kollar så noggrant på FindBugs varningar. Då just detta hände oss i ett litet projekt med relativt lite kod, kan tänka sig att i ett projekt av större storlek, kan allvarligare buggar/varningar försvinna i mängden av felaktiga varningar. [1] FindBugs är ett program som du själv kan välja när det ska köras eller låta det ligga igång i bakgrunden, undertiden som utvecklarna jobbar. Har man valt att det ska köras hela tiden, kommer programmet att (i t ex Eclipse) visa en symbol bredvid den rad som buggen berör. Givetvis får man även reda på raden det blivit fel på, precis på samma sätt, om man väljer att köra programmet vid annat tillfälle (så som vi byggprocessen). Man kan tänka sig att man har tre valmöjligheter till när man skulle vilja att programmet ska köras. 6

7 1. Under tiden som koden skrivs; Här har man fördelen av att hela tiden kunna följa i koden, undertiden som man programmerar, var det blir fel. Detta ger en stor möjlighet att rätta till felen direkt. Det är välkänt att desto längre det har gått innan man rättar en bugg, desto mer kommer det kosta att rätta den. 2. Varje gång projektet byggs; Om vi istället väljer att köra FindBugs varje gång projektet byggs, ja då har vi en möjlighet till att få statistik över hur projektet går. Man får fördelen att man under regelbundna tider kan få reda på i vilken riktning projektet är på väg, samt om det skrivs mindre buggar/fel. Väljer man denna metod, har man möjlighet att få ut grafer och annat nyttigt som kan hjälpa i ett projekt. 3. Vid varje milstolpe; Att köra buggtest vid varje milstolpe är även det nyttigt. Det är precis nu man vill testa om programmet håller för vad det är tänkt att göra, samt att FindBugs kan hjälpa till att hitta brister i säkerheten. Nu till den sista frågan, vem ska köra programmet? Det är inte en helt trivial fråga, man kan tänka sig att det är utvecklarna som kör det, men även att det är en speciell säkerhetsgrupp som får uppgift att hålla koll på bristerna i programmet. Fördelen med att låta utvecklarna sköta det, är att de är mer insatta i koden och kan köra det under tidens gång. Nackdelen är att det kanske stör eller att de inte har den kunskap som behövs för att avgöra huruvida allvarligt ett fel är. Om man däremot låter ett säkerhetsteam sköta det hela, så har de en stor koll på hur allvarliga felen är och kan bättre prioritera vad som ska lösas först. Man har möjligheten att skicka frågor till utvecklarna när ett allvarligt fel har upptäckts. Samtidigt har man nackdelen att dessa inte är insatta på samma sätt som utvecklarna, i vad koden gör. De måste även kunna ge utvecklarna bra feedback, så de blir samspelta och förstår varandra. [2] 6.3 Hur ska man hantera resultatet? Man kan hantera data som FindBugs levererar på många sätt. En bra möjlighet är att exportera informationen om buggarna till XML fil och med hjälp av XSL formatera en HTML fil och lägga upp denna på en sida som alla kommer åt. Detta medför att alla utvecklare kan hålla koll på alla fel och då ges det möjlighet att föra diskussion kring dem. Då det är av intresse att se huruvida koden håller en bra standard och hur kvalitén förändras över tiden, kan det vara bra att föra statistik. Genom att använda informationen man får, kan man hålla koll på projektet och se till att det inte glider åt fel håll, se till att där blir färre buggar skrivna och på så sätt skriva bättre kod. Men kom ihåg, FindBugs är bara ett program, det kan inte ersätta vettigt tänkande. [1] 6.4 Hur får man ett team att börja använda det? Den stora frågan som vi försökte ta reda på i vårt projekt var just hur vi skulle få teamet att använda FindBugs. Vi körde på iden att låta de alla köra programmet på sina datorer och använda det när de själva känner att de vill, men med lite påminnelser i början. Det visade sig ganska snabbt att FindBugs inte kördes kontinuerligt, utan att det istället blev att man körde det en gång om dagen och innan en release. För att undvika att onödiga buggar kommer upp och att farliga försvinner i mängden, kan det vara bra att börja smått (använda Filters i FindBugs) och välja ut vilka filer/buggar och buggar man vill testa. På detta sätt får alla känna på programmet och ser direkt användningen av programmet. Man kan sedan skala upp det, genom att lägga till fler buggar och skriva egna detektorer. [2] 7

8 Man kan sätta en person som har lite kunskap i all kod, som ansvarig för att lära sig programmet extra bra. På så sätt kan han ha ansvar för att användningen av programmet sker smidigt och hjälpa folk vid problem. Denna person väljs av anledning till att den kan hjälpa till vid skapande utav specifika tester till olika delar av koden, samtidigt som den troligen har kontakt med flest olika personer. På så sätt behöver man inte introducera en ny människa som ska hjälpa personer i en avdelning där den inte har någon som helst koll på vad som händer. Använd resultaten som man kan få ut av FindBugs. Skriv ut grafer, statistik eller andra informativa papper och visa för utvecklarna att det lönar sig att använda ett analysprogram. Ändra programmet efter egna behov. Du kan lägga till egna detektorer och få dem att söka efter buggar du själv angivit. Detta kan vara nyttigt till egna moduler i företaget då det inte ligger som standard i programmet att veta vad som räknas som fel i er specifika kod. Genom att utveckla egna detektorer får man ett mer heltäckande analysprogram och det är större chans att upptäcka fel som t ex nya utvecklare kan göra när de kommer till företaget (eller andra anställda). [2] 8

9 7. Utvärdering av Findbugs Vi valde att göra en undersökning bland våra utvecklare som ingick i vårt programvaruteam. De fick som uppgift att använda Findbugs under PVG 6 projektets gång, och här kommer både frågorna, samt en sammanställning av svaren de gav på vår enkät. 7.1 Frågor vi ställde till programvaruteamet Här kommer frågorna som programvaruteamet fick svara på, till denna djupstudie. 1. Vad var dina första förväntningar med Findbugs? 2. Hur smidigt är det att få igång och köra? 3. Hitta den många/få fel jämfört med du förvänta dig? 4. Var det någon skillnad att använda Findbugs mellan de olika iterationerna av PVGprojektet? 5. Har resultatet varit användbart och lätt att förstå? 6. När under XP projektet kan Findbugs mest lämpa sig att användas; vid build, milestone eller kodning? (motivera och rangordna från 1 3 där 1 innebär lämpligast) 7. Hade du kunnat tänka dig att använda det kontinuerligt under ett projekt? 8. Kommer ni använda Findbugs som verktyg i framtida projekt?(ej kontinuerligt som på fråga sju). Motivera om ni svara nej på fråga sju. 9. Övriga synpunkter om Findbugs? 10. Betyg av Findbugs. (på en skala 1 10 där 1 är sämsta och 10 bäst) 7.2 Svar på frågeställning Här kommer en sammanställning av svaren som vi fick från vårt programvaruteam. 1. Det fanns inga specifika förväntningar på 80% av svaren och de resterade hade en väldig positiva förväntningar att det skulle hjälpa dem. Dock så fanns det en avvikelse med en negativ inställning, då Findbugs antogs ge störande meddelanden. 2. Här har alla svarat att det var smidigt att få igång och väldigt enkelt att använda. 3. Överlag så hittades fler fel än vad man förvänta sig, men det var inte alla fel som man behövde åtgärda och vissa som man hade gjort medvetet. 4. Här var det bara en som svarade att man fick fler fel i senare iterationer, när man gjorde om systemet, annars ansågs det inte vara någon skillnad på resten av de tillfrågade. 5. Alla var överens om att bara en del av resultatet var användbar och man behövde ändra i koden. Den andra delen var bara varningar som man ignorera. 6. Har var resultatet väldig blandat, men man kunde se att kodning eller under byggprocessen, som var det lämpligaste stället att använda Findbugs och inte vid en milstolpe. 7. Här svara 40% ja att det skulle tänka sig, och 60% nej. I Nej gruppen så fanns det bland annat en motivering att man har klarat sig utan Findbugs innan. 8. Här fanns det många som hade svarat nej på fråga 7 som svarade att de kanske skulle testa det då och i så fall under projekt för att kolla at inga stora fel hittas. 9. De flesta ansåg att idén var jättebra men att det skulle behövas förbättras på att visa buggar i koden och inte visa så många varningar på möjliga fel. 10. Medelbetyget sluta på 4,6 av 10 och fördelningen kan ses på Figur 1. 6 Programvaruutveckling i grupp på Lunds Tekniska Högskola (Kurskod: EDA260) 9

10 Findbugs Betyg 37,50% 25% 25% 12,50% Figur 1 Bild över fördelningen av Findbugs betyg 7.3 Egna uppfattningar under projektets gång Som Coacher över ett programvaruteam, som läser kursen PVG, har vi kunnat bilda en egen uppfattning om Findbugs. Detta har vi fått genom att observera och fråga utvecklarna under arbetets gång. På så sätt har vi kanske kunnat få en annorlunda bild av hur Findbugs kan användas i ett projekt än utvecklarna. Utav detta har vi dragit några slutsatser, som t ex att vi anser att Findbugs kan vara hjälpsamt och förbättra kvalitén i koden på ett smidigt sätt. Det första som vi direkt observera var att Findbugs är mycket effektivt till nya programmerare som inte har en sådan stor vana att programmera innan PVG kursen. Då hjälpte Findbugs till att informera dessa när de hade gjort slarvfel eller enklare fel. På så sätt fick de mer tid att programmera än att fixa fel. Detta var inte lika uppenbart vid mer vanna programmerare som tyckte att Findbugs meddelande bara mest var i vägen. Detta eftersom de redan viste vad de gjorde och att där var det medvetna fel som hanterades på annat sätt. Dessa personer tyckte då att Findbugs tog mer tid än vad det var värt. Vid flera tillfällen då vi frågade de mer vana programmerarna vad de tyckte om Findbugs, fick vi samma svar som vi hade observerat, de ville inte ha igång FindBugs under utvecklingen. Dock så tyckte man att det skulle kunna användas till att optimera, då det gav information om duplicerade variabler och liknande. Detta skulle specifikt kunna göras innan en utgåva av programmet skulle skickas till kund, för att testa om programmet hade buggar. Men förutom själva optimeringen vid en utgåva, så har vi också kunnat dra slutsatsen att det är mycket bra att köra igenom FindBugs för att hitta svagheter (så som buggar) i programmet. Detta både för att fixa buggarna, men också för att få en kvalitetsstämpel som inte testerna kan ge. För om man nu kan köra igenom projektet med FindBugs(utan fel), så är risken mindre att en bugg kommer fram då kunden testar systemet. 10

11 8. Diskussion Vi ville se hur FindBugs fungerar ihop med XP metodiken och om det skulle kunna hjälpa till med testning och kodkvalitén. Men det allra viktigaste är hur vida utvecklarna tycker om Findbugs och hur mycket det kan hjälpa de. Vi har nu sett i djupstudien att man får man skilja på om utvecklarna är oerfarna eller vanna. Detta är speciellt viktigt då man ska introducera ett nytt program för att hjälpa till med utvecklingen. Då en van utvecklare har sitt arbetssätt, är det betydligt svårare att introducera något nytt jämfört med en oerfaren utvecklare. På så sätt kan nyttan av programmet försvinna bort då de vana utvecklar motsätter sig programmet och inte ändrar sitt arbetssätt till att utnyttja programmet. Så på XP metodiken kan det faktiskt vara bra och smidigt sätt att införa och lära sig ett nytt program. Då man använder parbyten under iterationerna får man en spridning av kunskapen och de olika personerna kan lära varandra hur programmet fungerar av varandra. 9. Slutsats Det vad vi har kommit fram angående Findbugs kan summeras upp till fyra punkter. FindBugs kan vara speciellt bra till nya utvecklare till ett nytt företag eller projekt. Samtidigt kan det vara bra till personer som helt enkelt inte har vanan uppe i att programmera än. FindBugs kan ses som ett extra skydd för att undvika en del förödande fel och misstag. Findbugs är ett bra komplement till TDD i XP. Då den hittar fel i koden och inte testar själva funktionaliteten som TDD gör. Därför blir det tillsammans ett bra sätt att sätta en exta kvalitetsstämpel. FindBugs hjälper utvecklarna att programmerare och att lära dem att göra mindre fel. Detta har vi inte sett något spår av i frågeställningen och är svårt att mäta på sådan kort tid, men man kan alltid spekulera om att allt som pekar på ens brister, hjälper en att lära sig. Man lär sig av sina misstag helt enkelt. Sista punkten är att om Findbugs ska slå igenom stort för utvecklare, så kommer det behövas utvecklas vidare. För idag så fungerar det bra, men det ska kunna köras hela tiden och hitta kritiska buggar och inte informera en om fel som man ibland har valt själv att göra. Det måste helt enkelt bli lättare att skriva egna Detektorer och göra inställningar. 11

12 Litteraturförteckning [1] Grindstaff, C. (den 25 Maj 2004). FindBugs, Part 1: Improve the quality of your code. Hämtat från IBM: findbug1/ den [2] Putting the Tools to Work:How to Succeed with Source Code Analysis. (MAY/JUNE 2006). IEEE SECURITY & PRIVACY, ss