UTVÄRDERING AV ECLIPSE I ETT XP- PROJEKT

UTVÄRDERING AV ECLIPSE I ETT XP- PROJEKT 23-5-15 Anders Mårtensson, dama@efd.lth.se Marcus Andersson, dman@efd.lth.se

INNEHÅLLSFÖRTECKNING Inledning...3 Vad är Eclipse?...3 Kort om XP och projektet...3 Problemställning...4 Utförande...4 Resultat...4 TANKAR OM ECLIPSE...5 JÄMFÖRELSE MELLAN ECLIPSE OCH EMACS...5 PROBLEM VID ANVÄNDNING AV OLIKA UTVECKLINGSVERKTYG...5 FÖRDELAR OCH NACKDELAR...5 Analys...6 ÄR ECLIPSE FÖR AVANCERAT?...6 PRINCIPERNA I XP...6 ECLIPSE UPPLEVS LÅNGSAMT OCH BUGGIGT...7 FÖRDELAR OCH NACKDELAR MED EN INTEGRERAD UTVECKLINGSMILJÖ...7 BLANDADE UTVECKLINGSMILJÖER...8 ÖVERGÅNG TILL ECLIPSE...8 SKA MAN ERSÄTTA DET TRADITIONELLA ARBETSSÄTTET MED EN IDE I TIDIGARE KURSER?...9 Sammanfattning...9 Referenser... Bilagor... 2

Inledning Ett bra verktyg kan snabba upp utvecklingsprocessen avsevärt. En möjlig fördel med att använda Eclipse i projekt är att det har stöd för alla de refaktoreringar som är så viktigt för att följa principerna i Extreme Programming, t ex Simple design. En annan intressant frågeställning är att se om Eclipse kan underlätta utvecklingen av programvara och vilka problem det kan innebära vid övergång från en textorienterad miljö. Det och mycket mer tar den här djupstudien upp. Vad är Eclipse? Före denna kurs har elever på Lunds Tekniska Högskola programmerat med hjälp av en texteditor (emacs) och en kompilator (javac). Eclipse är ett integrerat utvecklingsverktyg, dvs ett program med alla delar man behöver för att utveckla mjukvara. Ett utvecklingsverktyg brukar också kallas för IDE (eng: Integrated development enviroment). Eclipse innehåller en fullfjädrad texteditor, refaktoreringsverktyg, stöd för CVS 1 (Concurrent Versions System), stöd för automatiserade tester med junit 2, inkrementell kompilator, debugger samt mycket mera. Eclipse är en IDE skapad av IBM, och är utvecklad som ett open-source projekt och är gratis att använda vilket gör det attraktivt för högskolor. Kort om XP och projektet I kursen Programutveckling i grupp projekt 3 får studenter lära sig att arbeta i grupp och utveckla program med Extreme Programming 4 som utvecklingsprocess. Extreme Programming är en lättviktig iterativ process där tyngdpunkten ligger på kommunikation och förändring till skillnad från traditionella utvecklingsprocesser där en vattenfallsmodell används och tyngdpunkten ligger på dokumentation. Varje iteration representerades i form av åtta timmar långa laborationer. Dessa långlabbar genomfördes varje vecka i sex veckor. Mellan varje långlabb hölls ett två timmar långt planeringsmöte där den föregående iterationen gicks igenom och nya stories delades ut till nästa iteration. Varje vecka fick dessutom studenterna fyra timmars hemarbete där de skulle förbereda något inför den kommande laborationen. Programmet studenterna utvecklar är ett tidtagningsprogram för endurotävlingar. I ett XPprojekt finns det olika roller. Den första rollen fyller studenterna själva. De programmerar i par eftersom det är en av principerna i XP ( Pair Programming ). Vi, författarna, läser kursen Coaching av programvaruteam 5 och vår roll i projektet var att agera coach, som är den andra rollen. Året innan läste vi den kursen som studenterna läser just nu. Coachens uppgift är att göra den första grundläggande arkitekturen, assistera parprogrammerarna så att arbetet underlättas samt guida parprogrammerarna rätt så att principerna i XP följs. Den tredje rollen fylls av anställda på institutionen i form av kunder. En kunds uppgift är att kontinuerligt formulera krav på systemet i form av så kallade stories där varje story beskriver en funktion i programmet samt att ge kritik på programmet efterhand som det utvecklas. Det är dessa stories som programmerarna implementerar. 1 Se http://www.cvshome.org/ för mer information om CVS. 2 Se http://www.junit.org/index.htm för mer information om junit. 3 Se http://www.cs.lth.se/education/lth/eda26/ för mer information om kursen. 4 Se http://www.extremeprogramming.org för mer information om Extreme Programming. 5 Se http://www.cs.lth.se/education/lth/coach/ för mer information om kursen. 3

Problemställning Med fullt stöd för refaktorering, CVS, junit, ett grafiskt användargränssnitt, en bra debugger, automatiska förslag till kompileringsproblem, formatering av kod, snabb kompilator som bara kompilerar det som behövs och så vidare har Eclipse en hel del finesser. Är verktyget så avancerat att arbetet försvåras? Är inlärningströskeln hög och känner nybörjarna sig vilsna i början och vad kan i så fall göras för att undvika detta? Hur förändrades studenternas inställning till Eclipse efter att de använt verktyget ett tag? En annan fråga som är naturlig att ställa sig är om det är en god idé att börja med en IDE tidigare i utbildningen? Finesserna gör inte bara arbetet lite trevligare än vanligt utan det kan även bidra till att XPs principer följs lättare. Nedan finns en kort lista på principer som stöds direkt eller indirekt: Refaktoreringstöd Simple design CVS Collective code ownership junit Test first Formatering av kod Coding standards Frågan är om det i praktiken verkligen bidrar till att följa XPs principer eller inte. En annan fråga som är intressant är hur väl fungerar det att blanda utvecklingsmiljöer och vilka problem kan uppstå? Är övergången från en annan utvecklingsmiljö svår? Vilka fördelar har en integrerad utvecklingsmiljö jämfört med en traditionell utvecklingsmiljö med separat texteditor och kompilator? Utförande Vi delade ut enkäter till ett par grupper (se bilaga 1) för att få en uppfattning av vad de olika grupperna tyckte. Vi valde grupperna så att vi fick olika typer av grupper, dvs grupper som enbart använde Eclipse, grupper som enbart använde texteditor och grupper som blandade utvecklingsmiljöer. Enkäten fylldes i under andra iterationen. Två grupper använde blandade utvecklingsverktyg, en grupp använde enbart texteditorer och resterande tre grupper använde enbart Eclipse. Totalt gav vi enkäten till 52 studenter varav de flesta svarade på alla frågor. Enkäterna delades ut under andra iterationen till fyra grupper och resterande två grupper fick dem vid ett senare tillfälle. Resultat Här följer en sammanfattning av de fakta vi fick ut ur enkäten som delades ut. En mer detaljerad sammanställning kan ses i bilaga 4. I enkätutfrågningen var det 13 % som använde enbart en texteditor, 73 % som använde enbart Eclipse och de resterande 14 % blandade mellan Eclipse och en texteditor. 4

Tankar om Eclipse Av de tillfrågade tyckte 7 % av teknologerna att det var lätt att använda Eclipse för första gången. De teknologer som inte tyckte det var så enkelt skrev att det berodde på att Eclipse var rörigt och att det var svårt att veta vilka finesser som fanns. De som använde Eclipse hade en relativt positiv inställning till programmet i början. På en femgradig skala om vilken inställning de hade i början svarade 26 % tre och 59 % fyra eller högre. Efter att ha använt det under hela första långlabben hade omdömet om Eclipse förbättrats något. 36 % gav det ett högre betyg medan endast 15 % gav det sämre betyg. Här bör det noteras att det var bara bland dem som blandade utvecklingsmiljöer som gav ett sämre betyg. När det gällde att använda den inbyggda refaktoreringen i Eclipse så tyckte 61 % att de använde det inbyggda stödet för refaktorering ofta (betyg 3 eller högre). De som inte använde det sa att det berodde på att det var inte helt intuitivt, att de glömmer bort att det finns sådant stöd eller att de olika refaktoreringarna ibland hade svåra namn att förstå. Jämförelse mellan Eclipse och Emacs 25 % av Eclipse-användarna gjorde inte refaktorering för de tyckte att det var svårt medan motsvarande siffra för de som använde texteditor var hela 66 %. Vi frågade hur många som tyckte bättre om att använda en IDE istället för en texteditor och fick då fram att 71 % tyckte så. Problem vid användning av olika utvecklingsverktyg En fjärdedel blandade utvecklingsverktyg och av dem så var det knappt hälften som tyckte att det innebar problem. Problemen var i huvudsak att de olika verktygen hade olika representationer för indentering, dvs att representera tabbar som tabbtecken eller som mellanslag. Fördelar och nackdelar När vi frågade vilka fördelar de tyckte Eclipse hade så var det många olika svar som kom upp vilket antagligen beror på att där finns många finesser i programmet. De populäraste var stöd för refaktorering och inbyggt stöd för CVS. Många tyckte även att de tyckte att de fick bättre översikt på såväl koden som projektet. Andra fördelar med Eclipse var automatisk komplettering, samma kortkommandon som Windows och automatisk felanalys av koden när man programmerade. De största nackdelarna med Eclipse var att det var långsamt och buggigt. De tyckte även att det var rörigt pga alla finesser och därmed svårt att använda. När det gällde Emacs-användarna så pekade alla nästan på samma fördelar; det var enkelt att använda och snabbt. Det nämndes även att det var bra att det var Unix-kortkommandon, bra färgkodning och att det fungerar till alla programmeringsspråk (Eclipse fungerar även till andra programmeringsspråk men har bara stöd för Java som standard, men en plug-in till C++ finns att ladda hem). Nackdelarna var däremot mer utspridda över olika punkter. De vanligaste anmärkningarna var att stöd för refaktorering saknades, att allt inte var integrerat, ingen automatisk felanalys av koden, inget CVS-stöd och dålig översikt. 5

Analys Vi har dragit våra slutsatser genom att analysera de svar vi fick genom enkäten. Vi har även uppmärksammat hur våra egna projektmedlemmar upplevde Eclipse samt vad de andra coacherna har berättat på coaching-mötena. Är Eclipse för avancerat? Den första halvtimmen på den första långlabben upplevde vi det som att projektmedlemmarna tyckte att Eclipse var lite jobbigt att arbeta med. När de väl hade provat på alla finesser ett par gånger så flöt dock arbetet på bra. Första gången de skulle t ex uppdatera filerna från CVSrepositoriet var de lite rädda för att göra fel, men när de väl lärt sig att allt man behövde göra var att högerklicka och välja Update så gick det smidigt. Det var precis samma sak när de skulle prova på att refaktorera för första gången. Med andra ord är inlärningströskeln inte så hög om man kan programmera i Java sen tidigare. Vi skrev två lathundar så att de skulle komma igång fortare (bilaga 2 och 3). Den första lathunden tar upp hur man startar Eclipse, konfigurerar CVS, importerar inställningar för editorn, konfigurerar junit samt hur man kör ett program. Den andra lathunden tar upp de olika finesserna i Eclipse, t ex automatisk komplettering av kod, hyperlänkar till implementationer av metoder, överlagring av metoder och automatiska förslag på kompileringsfel. De som tog del av lathundarna uppskattade dem mycket och använde fler finesser än de som inte fick dem. De gav också Eclipse ett högre betyg. Det är svårt att veta vilka finesser som finns och därmed inte utnyttja dem. Förhoppningsvis får alla ut lathundarna nästa år för att på vis korta ner inlärningstiden samt informera vilka finesser som finns. Det är väldigt bra att experimentera lite grann innan projektet börjar så man känner sig lite säkrare och vet vad som finns. De finesser de tyckte var svåra eller onödiga använde de inte. Om man vill kan man använda editorn i Eclipse enbart som en renodlad texteditor utan några som helst finesser. Den enda gången som Eclipse riktigt försvårade arbetet var när det uppstod svåra mergekonflikter. Det var inte helt intuitivt hur man skulle hantera detta och om man var för snabb kunde man lätt blanda ihop den gamla koden med den nya koden och på så vis skapa en hel del kod som var väldigt rörig. Kod som till synes inte gjorde något togs bort och till slut fungerade ingenting. Det gäller som sagt att vara väldigt försiktig med stora merge-konflikter. Vi kom fram till att man aldrig ska radera någon kod utan istället kommentera bort den. När alla tester väl går igenom kan man ta bort den bortkommenterade koden. Det här visar tydligt vad som behöver övas mer på före projektet. I år fanns det laborationer som både tog upp refaktorering och CVS, men de bör kanske utökas något. Absolut viktigast är hanteringen av merge-konflikter. Principerna i XP När man tittar på finesserna i Eclipse så verkar det underlätta XPs principer då det har inbyggt stöd för junit, inbyggt stöd för refaktorering, stöd för release av projekt (export till jar-fil), inbyggd kodformatering och CVS-stöd. Inbyggt stöd för junit är viktigt för XP då XP bygger på att testa sin kod så mycket som möjligt. Vi märkte att junit användes flitigt av alla grupper och de körde test så ofta som möjligt. Detta var lätt för dem när det bara var en knapp i fönstret som gjorde detta möjligt. Men även de andra grupperna utan Eclipse använde junit flitigt. 6

Simple Design är en av huvudprinciperna i XP och det kan bl a fås genom refaktorering. Även refaktorering i sig är en XP-princip vilket gör att det är viktigt att ha stöd för refaktorering för att få så bra XP-kod som möjligt. Den inbyggda refaktorering i Eclipse ledde till att refaktorering gjordes oftare i Eclipse-par än i de andra paren. Men här var det problem ibland eftersom detta var en ganska ung skara programmerare som inte kände till de olika namnen som olika refaktoreringar hade och därmed höll de sig till de enklare av de automatiska refaktoreringarna. Vi märkte även att vissa par inte var vana vid att använda de inbyggda refaktoreringarna och därmed inte tänkte på att använda dem utan refaktorerade koden för hand. När vi själva har använt Eclipse har vi sett att refaktorerings-verktygen används mer när vi fått mer erfarenhet av Eclipse. För att följa XPs principer så är det väldigt viktigt att ha en CVS-server då den underlättar för Collective Ownership och Continues Integration. Gruppmedlemmarna hade redan innan projektet provat på att använda en CVS server men aldrig i ett projekt. Därför uppstod mycket jobb vid uppladdning av kod. Men detta problem fanns i alla grupper och var oberoende om man använde Eclipse integrerade CVS-stöd eller ett externt CVS-program. Det märktes att det var vanligare att de som använde Eclipse uppdaterade sin kod oftare när de enkelt kunde komma åt det i Eclipse. De hade dock svårigheter i början när de var ovana vid menyerna i Eclipse och hitta alla CVSrelaterade finesser. Coding Standards är också en XP-princip som säger att projektet skall ha enhetligt formaterad kod. Eclipse har inbyggd kodformatering som kan konfigureras hur man vill ha sin kod. Detta användes i projektet i våra grupper genom att vi gav dem en konfigurationsfil som ställde in kodformatet. Efterhand såg vi att grupperna började formatera koden oftare och oftare med hjälp av Eclipse och då fick mer enhetlig kod. Jämfört med innan då det var lätt att glömma gruppens standarder på något ställe. Eclipse upplevs långsamt och buggigt Många som har gett Eclipse dåligt betyg har gjort det på grund av att det känns långsamt och buggigt. Eclipse flyter på mycket bättre på Windows än vad det gör på Solaris och är även mycket stabilare. Vad detta beror på kan vi bara spekulera om. Eclipse kräver en snabb dator med mycket minne. Ett absolut minimum är 256 Mb RAM. Eclipse kördes under en halv långlaboration i en av salarna med enbart 128 Mb RAM (Val) och det var väldigt frustrerande. Datorerna ska troligtvis uppgraderas under sommaren så Eclipse kanske fungerar bättre nästa år. Alternativt kanske man kan driva projektet i en sal med datorer med Windows på nästa år, men det kanske innebär andra problem. En stor skärm är också viktigt eftersom det visas så mycket information samtidigt i Eclipse (klasser, metoder, texteditor, kompileringsfel). Med det i åtanke och att man är ett par som programmerar ihop kan det innebära ett problem eftersom det enbart är 15 -skärmar i salarna med Windows. Fördelar och nackdelar med en integrerad utvecklingsmiljö Det finns massor med fördelar med en integrerad utvecklingsmiljö jämfört med en traditionell utvecklingsmiljö med separat texteditor och kompilator. Först och främst får man en mycket bättre överblick över vilka metoder samt vilka klasser som finns. I och med att kompilatorn är integrerad får man tillgång till en rad finesser. Man kan hoppa direkt till kompileringsfel genom att helt enkelt klicka på felet i en lista. Eftersom ens program körs genom utvecklingsverktyget får man även tillgång till en kraftfull debugger, men den har dock inte använts så flitigt under projektets gång. Inbyggt stöd för CVS är givetvis också bra för det räcker att man högerklickar på en fil så får man tillgång till alla de funktioner för CVS. Att köra automatiserade tester med junit är lika enkelt som att köra ett program. Att allt är integrerat har givetvis sina nackdelar också. Man får ingen valfrihet vad gällande kompilator eller texteditor. Val av texteditor är väldigt personligt på grund av dess kortkommandon och finesser. Val av kompilator kan man inte heller påverka. Ofta duger Suns javac bra eller IBMs 7

jikes, men det finns även andra kompilatorer som kan vara snabbare eller som optimerar koden bättre. Eclipse använder en inkrementell kompilator 6. Man kan även själv välja vilket verktyg man vill använda för CVS, t ex tkcvs eller textvarianten. Blandade utvecklingsmiljöer Eclipse är en bra grund som innehåller flera delar som behövs vid utveckling av programvara, men när man jobbar i projekt har alla olika bakgrund och vissa vill hellre jobba med de verktyg de är vana vid. Att blanda olika program kan ställa till problem men är det lättare att tvinga alla anpassa sig till ett verktyg eller är det bättre att blanda de olika verktygen och ta konsekvenserna? De flesta grupperna valde att bara använda Eclipse och det var bara två grupper som valde att ha olika utvecklingsmiljöer. När man blandade utvecklingsmiljöer uppstod problem med att Eclipse och Emacs inte hade samma representation av indenteringar. Detta ordnades genom en inställning i Eclipse så att det använde samma indentering som Emacs. Annars var där inga större problem med att blanda utvecklingsmiljöerna. Men där är andra saker man bör tänka på om man väljer att blanda utvecklingsmiljö. Det kan bli splittring i gruppen där alla håller på sitt eget program t ex vid parprogrammering kan detta ge problem. Men däremot så kommer kunskap sprida sig i gruppen och personerna i gruppen kommer att lära sig nya utvecklingsmiljöer. En enhetlig utvecklingsmiljö kommer dock att ge mer djupgående kunskap om miljön. För att ta reda på hur det är i industrin pratade vi med två mjukvaruingenjörer. Brian Matzon på Solvision (www.solvision.dk) jobbar i nuläget med plattformen.net, men när han jobbade på Certus (www.certus.dk) blandade de utvecklingsverktyg. De använde vi, Visual Slickedit, Netbeans och Eclipse. De problem de hade var samma som vi hade, dvs problem med formatering och indentering. Joerg Plewe på Science Factory (www.science-factory.com) säger att de hade samma problem och att de använder JBuilder, Netbeans (med refactorit), IDEA, CodeGuide, Together, Eclipse och Emacs tillsammans. Trenden verkar vara att man får använda vilken IDE som man vill så länge den är gratis och i vissa fall så betalar företagen licenser för kommersiella verktyg. Som sammanfattning kan man säga att det är inte ger några större problem att blanda utvecklingsmiljöer men man bör tänka på andra aspekter såsom sociala och ekonomiska. Ett företag har kanske inte råd att köpa in flera program utan håller sig kanske till ett eller två. I det här fallet är Eclipse gratis, men det är långt ifrån alla. Övergång till Eclipse En programmerare kommer under sin tid bli mer fäst vid ett verktyg än vid andra och då förespråka detta verktyg (gäller även språk och operativsystem). Detta kan man se på de tusentals forum på Internet där folk diskuterar vad som är bäst. Hur blir det då när man måste jobba på ett projekt som använder ett annat verktyg? Och hur är det att gå över till en IDE från att ha använt en texteditor? Vi märkte direkt vilka som helst inte ville lära sig Eclipse. När vi sedan pratade med dem så nämnde de att de brukade använda andra verktyg och vilka fördelar de såg i dem jämfört med Eclipse. Men de använde Eclipse precis som alla andra men så fort det var något som gick fel så var det fel på Eclipse och inte handhavande fel. De andra teknologerna som inte hade valt någon favoritmiljö ännu klandrade hellre sig själv än Eclipse. Detta berodde förmodligen på att det finns en inlärningströskel och de som redan hade lärt sig ett annat program tyckte det gick snabbare att 6 Se www.eclipse.org för mer information. 8

använda något de redan kunde jämfört med något som tog tid att lära sig. Medan de andra inte hade något annat att jämförda med och på så sätt tog mer till sig informationen och ville lära sig. Att gå över ifrån en texteditor till en IDE är en stor omväxling. I en texteditor och extern kompilator syns det steg för steg vad som händer med koden medan i en IDE behöver man bara trycka på en knapp och ut kommer ett program. Teknologerna lärde sig ganska snabbt att använda Eclipse och det kändes som de snabbt tog till sig flera av de fördelar som programmet gav. Detta berodde kanske på att de fick hjälp att lära sig genom de två lathundarna som vi gett ut. Det berodde nog också på att de använt flera andra grafiska program tidigare och att de är tekniskt kompetenta. När de lärt sig grunderna tog det däremot längre tid att lära sig extra finesser. De kände att de var nöjda med vad de redan kunde och orkade inte lära sig mer. De tar dock till sig nya finesser som de lär sig under tiden, men inte lika snabbt som innan. Ska man ersätta det traditionella arbetssättet med en IDE i tidigare kurser? Det här är en svår fråga eftersom vi inte har studerat hur det hade fungerat i praktiken så det är bara antaganden vi presenterar här. Vi anser att man inte bör börja med en IDE direkt i inledande programmeringskursen utan att det är mer lämpligt att börja kanske det andra året. Den största orsaken är enligt vår mening att Eclipse hjälper till för mycket (om man vill). Som exempel kan vi ta när man ska tilldela en variabel ett värde av en annan typ: int x = 1.2f; Eclipse föreslår då add cast to int, vilket kan vara korrekt, men det är inte säkert (man kanske vill avrunda eller konvertera x till float). För vana programmerare är detta bekvämt och bra. En nybörjare kan se detta på två sätt: 1. Studenten ser att det är fel och ser att Eclipse föreslår att det behövs typkonvertering och lär sig varför. Eclipse rättar till felet och studenten fortsätter programmera. 2. Studenten ser att det är fel och ser att Eclipse föreslår att det behövs typkonvertering. Studenten vet inte varför det fungerar och låter Eclipse rätta till felet och studenten fortsätter programmera utan att bry sig om vad som var fel och därmed lär studenten sig inget. En annan sak som också talar emot är att det kanske blir för mycket att lära sig. Det kanske är för mycket att lära sig programmera samtidigt som man lär sig ett avancerat verktyg och alla dess finesser. Hur det är i praktiken vet vi tyvärr inte, men det behöver undersökas innan man ersätter det traditionella arbetssättet i grundkurserna med en IDE. Sammanfattning Det är en relativt låg inlärningströskel och om man kommer över denna så är det värt mödan. Om man inte får hjälp när man försöker komma över denna tröskel så kan tröskeln kännas lite högre. Med andra ord är det viktigt att coacherna kan svara på alla de frågor som projektmedlemmarna kan tänkas ha och komma med konkreta tips i det dagliga arbetet. Principerna i XP underlättas direkt och indirekt av användandet av Eclipse; refaktorering utförs mycket oftare eftersom det är så enkelt, Coding Conventions stöds genom anpassningsbar kodformatering samt inbyggt stöd för CVS och junit för att stödja Test First och Collective Code Ownership. Om projektmedlemmarna inte hade tillräckliga kunskaper i Eclipse så användes dock inte alla finesser, t ex refaktorering, och därmed förlorade verktyget sin betydelse för XP. 9

Referenser [1] Working the Eclipse Platform, (http://www-6.ibm.com/developerworks/library/os-plat/) [2] Ron Jeffries, Ann Anderson, Chet Hendrickson: Extreme Programming Installed. [3] Don Wells: The Rules and Practices of Extreme Programming, (http://www.extremeprogramming.org/rules.html) [4] The Eclipse Project Slide Presentation, (http://www.eclipse.org/eclipse/presentation/eclipseslides_files/frame.htm) [5] Project Builders and Natures, (http://www.eclipse.org/articles/article-builders/builders.html) [6] Kent Beck, Embracing Change with Extreme Programming, Computer Sweden, October 1999 [7] Lars Bendix, Görel Hedin, Boris Magnusson, Introducing Software Engineering by means of Extreme Programming, October 22 Bilagor (se nästa sida)

Utvärdering av Eclipse Marcus Andersson, dman, och Anders Mårtensson, dama. Bilaga 1 Svara Ja eller Nej på följande frågor. Om det finns en graderad skala, ange vilken grad du överensstämmer med påståendet. 1 instämmer inte alls, 5 instämmer helt. 1. Eclipse var lätt att använda första gången jag använde det. Ja Nej Om inte, var god skriv en liten kommentar om vad du tyckte var svårt. 2. Jag använder texteditor (emacs/vi) Eclipse Annat: Om du inte använder Eclipse, var god hoppa till fråga 7. 3. Jag hade en positiv inställning till Eclipse i början. 4. Efter att ha arbetat med det ett tag har jag en positiv inställning. 5. Om det har varit problem med Eclipse så har jag fått hjälp. Ja Nej 6. Jag använder Eclipse inbyggda stöd för refaktorering ofta. Eventuell kommentar om du inte använder det så ofta: 7. Jag tycker det är svårt att göra refaktorering och gör det därför sällan. 8. Jag anser att Eclipse innehåller många buggar. 9. Jag tycker att det behövs snabbare datorer än de vi har för att kunna använda Eclipse.. Jag föredrar att använda en IDE (Eclipse eller liknande) jämfört med en texteditor (emacs, vi eller en annan texteditor). 11. Jag har tagit del av lathunden (av Anders och Marcus) för att Ja Nej snabbt komma igång med Eclipse/CVS/jUnit. 12. Jag har tagit del av översikten över finesser i Eclipse ( En kort Ja Nej lista över finesser i Eclipse av Anders). 11

13. Har alla i ert team kört samma miljö (dvs enbart texteditor eller Ja Nej enbart Eclipse)? Om Ja, hoppa vidare till fråga 15. 14. Innebar det några problem att blanda utvecklingsverktyg? Ja Nej Om ja, skriv lite om problemen nedan: 15. Nämn de tre största fördelarna med Eclipse: 16. Nämn de tre största nackdelarna med Eclipse: 17. Nämn tre största fördelarna med en texteditor: 18. Nämn tre största nackdelarna med en texteditor: 19. Är det jobbigt med enkäter? Ja Nej 2. Övriga kommentarer: Tack så hemskt mycket för all din hjälp! 12

Bilaga 2 Starta Eclipse Skapa en mapp att ha projektets arbetsyta i t ex. ~/xp/ Gå in i mappen och kör ingång Eclipse: >> initcs >> eclipse rc2 & Lägg till vyer Eclipse är uppbyggt av vyer. En för CVS, en för att skriva kod, en för debugging etc. Dessa kommer inte fram som standard utan man måste lägga till dem. Det görs på följande sätt: 1. Klicka på ikonen: 2. Välj other... från menyn som kommer fram. 3. Då kommer Select Perspective-rutan fram. 4. Lägg till önskad vy 5. Upprepa tills du har alla vyer du behöver Rekommenderade vyer är CVS och Java. Konfigurera CVS Gå till vyn CVS och högerklicka i det stora gråa fältet till vänster ( CVS Repositories ) och välj New -> Repository location. Fyll i dialogrutan enligt nedan: Host: torvalds.cs.lth.se Repository path: /CVS/EDA26/cs3x User: <ditt login> Password: <ditt lösenord> Lämna resterande fält som de är (dvs Connection type: pserver, Use default port och Validate connection on finish ). Om allt fungerade som det ska återstår bara att checka ut projektet. Tryck på det lilla plustecknet och ytterliggare en gång där det står HEAD. Högerklicka sen på de projekt du vill ha och välj Checkout as project. Importera inställningar För att säkerställa att ni inte får några problem med att utveckla i Eclipse på grund av dålig konfiguration har vi gjort en inställningsfil åt er. Ni kan konfigurera Eclipse som ni vill, men lämna nedanstående saker som vi har ställt in dem. 13

Kodformatering ( Coding standards ) Autogenererade kommentarer som t ex att Anders har gjort den här klassen ( Collective code ownership ) Representation av tabbar som mellanslag (för att säkerställa kompatibilitet med Emacs) Filen finns att ladda hem från http://13.235.185.8/xp (spara ner filen på lämpligt ställe). Välj Window -> Preferences. På nästa dialogruta välj Import. Leta upp filen xp.epf och klicka på Open. Lägg till TestAll För att använda junit behövs en junit-körning. Den läggs till under Run-knappen. 1. Klicka på pilen sidan om gubben. Då kommer en meny fram. Välj Run... 2. Markera junit och klicka på new 3. Se till att projektnamnet är rätt och namnge testkörningen i rutan Name. 4. Markera All tests in Project, Source Folder or Package. 5. Tryck Search... -knappen 6. Välj din projekt-mapp 7. Tryck på Run" 8. Sedan kan du köra testerna genom att klicka på Run knappen (denna gången på gubben). Exekvering av program Lägga till en programkörning är nästan likadant som att lägga till en junit-körning. Skillnaden är att man skapar en Java Application istället för junit under Run... Istället för att leta efter testklasser letas main-funktioner upp. Sedan väljs main-funktionen som skall användas. Om main-funktionen skall ha inparametrar läggs de till under fliken Arguments. Annars är det precis som att lägga till junit-körning. 14

En kort lista över finesser i Eclipse Bilaga 3 Detta är bara en kort lista över de finesser jag själv använder. Det finns många fler, men dessa är bra att börja med. De är ordnade efter i mitt tycke nyttighetsgrad. För övrigt så ger övning färdighet. Den är anpassad för att kunna skrivas ut på en A4-sida. Kommentarer mottages tacksamt. Kompilera och spara kod CTRL+S sparar aktuell fil samt kompilerar. Går (oftast) snabbt eftersom enbart påverkade filer kompileras. Komplettering Tryck CTRL+SPACE för att komplettera metodnamn, klasser och variabler etc. Finns flera alternativ dyker en lista upp. Ett alternativ väljs med piltangenter och enter/space (snabbast) eller med musen. Formatera kod Beroende på vilken version som används, högerklicka i editorn och välj Format eller välj Format i menyn Source. Refaktorering Alla refaktorerings-verktygen under menyn Refactor är mycket bra och användbara. Rename, Extract method och Convert local variable to field använder jag dagligen. Kompileringsfel Kompileringsfel visas i listan där nere och för att hoppa till ett fel, klicka på ett fel så hoppar markören automatiskt till där felet befinner sig. Länkar (hoppa till metoder, variabler, klasser etc.) Om du t ex har följande kod: int x = calcdelay() så kan man trycka CTRL+<vänster musknapp> på calcdelay() för att hoppa till implementationen av calcdelay(). 15

Generera get()/set()-funktioner Oftast behövs en hel drös med get/set-funktioner, som t ex getx() och setx(int x). Source - > Generate getter and setter. En ruta dyker upp och det är bara att klicka för de metoder man vill ha. Överlagring/implementering av metoder Om du implementerar ett interface så kan man välja Source -> Override/Implement methods så dyker det upp en lista på de metoder som finns. Klicka för de du vill ha så generas kod för dem automatiskt. Fungerar även för superklasser. Automatiska förslag på lösning av diverse fel Om något är fel dyker det oftast upp en liten glödlampa på vänster sida på den rad felet befinner sig på. Genom att klicka med musen på glödlampan dyker en lista med olika förslag upp. Det går även att trycka CTRL+1. Exempel på förslag är att en import saknas, fel datatyp och att en metod saknas (och då kan ett skelett för denna skapas). Hoppa mellan funktioner/attribut Genom att trycka CTRL+SHIFT+UPPIL (eller NEDPIL) så kan man hoppa mellan funktioner och attribut. Try/catch-block Markera det vill omge med try{}. Välj Source -> Surround with try/catch block. 16

Bilaga 4 Resultat från enkäten i mer detaljerad form Fråga 1 - Eclipse var lätt att använda första gången 4 3 2 Ja Nej 35 3 25 2 15 5 Fråga 2 - Val av utvecklingsverktyg Texteditor Eclipse Annat Båda Fråga 3 - Positiv inställning till Eclipse i början Fråga 4 - Positiv inställning till Eclipse efter att ha arbetat med det ett tag 2 15 5 3 2 Betyg Betyg Fråga 5 - Om det har varit problem med Eclipse så har jag fått hjälp Fråga 6 - Jag använder Eclipse inbyggda stöd för refaktorering ofta 35 3 25 2 15 5 Ja Nej 2 15 5 Betyg Fråga 7 - Jag tycker det är svårt att göra refaktorering och gör det därför sällan Fråga 8 - Jag anser att Eclipse innehåller många buggar 2 15 5 Betyg 2 15 5 Betyg 17

3 2 Fråga 9 - Jag tycker att det behövs snabbare datorer än de vi har för att kunna använda Eclipse. Betyg Fråga - Jag föredrar att använda en IDE (Eclipse eller liknande) jämfört med en texteditor (emacs, vi eller en annan texteditor). 2 Betyg Fråga 11 - Jag har tagit del av lathunden (av Anders och Marcus) för att snabbt komma igång med Eclipse/CVS/jUnit. Fråga 12. Jag har tagit del av översikten över finesser i Eclipse ( En kort lista över finesser i Eclipse av Anders). 3 24,5 2 Ja Nej 24 23,5 23 22,5 Ja Nej Fråga 13 - Har alla i ert team kört samma milö (dvs enbart texteditor eller enbart Eclipse)? Fråga 14 - Innebar det några problem att blanda utvecklingsverktyg? 4 3 2 Ja Nej 8 6 4 2 Ja Nej 18