next previous Mjukvaruprocessen: översikt och repetition. XP: problemformulering. JUnit. Innehåll Allmännt om utvecklingsprocesser från Bruegge kapitel 12 Separata OH-bilder Introduktion till eXtreme Programming (XP) Översikt och problem som man vill lösa Ett enhetstestning med hjälp av Junit Från Fowler med separat utdrag och OH-bilder OOMPA 2000 Föreläsning 12

previous next 2 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit. eXtreme Programming eXtreme Programming (XP), av Kent Beck Tillvägagångsätt (12 grundpelare) Planeringsspel planera snabbt förutsättningarna för nästa release; prioritera, teknikkrav Små releaser släpp nya versioner ofta Metafor hitta en enkel och bra metafor Enkel design gör designen så enkel som möjligt Testa testa koden kontinuerligt. Måste lyckas innan utvecklingen går vidare. Skriv testerna först! Omstrukturera ("refactoring") strukturera om ofta; ta bort onödig kod, förenkla osv Parprogrammering två programmerare per maskin Kollektivt ägande av koden alla äger och kan ändra i koden Kontinuerlig integration integrera och bygg systemet flera gånger per dag 40-timmarsvecka jobba som regel inte mer än 40 timmar per vecka Inkludera en "kund" i teamet inkludera en "riktig användare" på full tid Följ kodstandard förenklar kommunikation

previous next 3 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit. Grundproblemet: Risk Tidsramar brister –Programvaran ej klar vid utsatt datum Projekt avbryts –Efter massa fel så avbryts projekt System blir sura –Efter några år blir det för dyrt att underhålla programvara även om den var lyckosam från början Många defekter –Produktionsprogramvara använd inte pga för många defekter

previous next 4 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit....problemet Fel problem löses –Programvaran löser inte det problem som man från början skulle läsa Problemdomänen förändras –Efter ett tag ändras behoven så den existerande programvaran löser ett gammalt problem Massa onödiga ”features” –Programvaran innehåller massa finesser som var roliga att progammera fast egentligen inte behövs Utvecklare byts ut –Efter ett tag tröttnar programmerarna på projektet och slutar

previous next 5 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit. XPs lösning på problemet: Risk Tidsramar brister –XP använder korta cykler med täta releaser Projekt avbryts –XP ber kunden att välja den minsta release som ger maximalt värde. Vilket medför att så lite som möjligt kan gå fel innan avstämning, samtidigt som man fokusera på det viktigaste System blir sura –I XP skapas massor av tester som körs efter varje förändring. Detta gör att systemen ”hålls i form” Många defekter –I XP skriver både utvecklare och kunder tester vilket reducerar sannolikheten för defekter

previous next 6 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit....XPs lösning på problemet Fel problem löses –I XP deltar kunden som en viktig del i utvecklingsteamet. Specifikationer uppdateras kontinuerligt under utvecklingen Problemdomänen förändras –XP förkortar releasecyklerna, så det är inte så många förändringar i utvecklingen av en release. Däremot är kunden välkommen att komma med nya krav kontrinuerligt (som vanligen tas upp under nästa cykel) Massa onödiga ”features” –I XP fokuserar man på högprioriterade uppgifter Utvecklare byts ut –I XP behandlas utvecklare som intelligenta och ansvarsfulla individer som får ta eget ansvar. Därmed minskar man risken för frustrerade programmerare. XP innehåller också element för övertagande av kod.

previous next 7 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit. Arbetssättet vid kodning i XP, några huvuddrag Par programmerar tillsammans Utvecklingen drivs av tester –Man testar först kodar sedan –Alla tester måste fungera innan man är klar Par gör inte bara enskilda delar körbara utan utvecklar och designar också (om) hela systemet Integration följer hela tiden på utvecklingen av en viss del –Detta inkluderar också integrationstestning

previous next 8 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit. Vi försöker kontrollera fyra variabler Kostnad –Mer pengar löser vissa problem fast för mycket kan skapa nya problem Tid –Mer tid gör att vi kan leverera mer. Men för mycket tid kan vara till skada. Kvalitet –Genom att tumma på kvaliteten kan man göra vissa vinster på kort sikt. Men på längre sikt kostar det för mycket. Omfattning –Mindre omfattning gör det möjligt att bättre kvalitet samt leverera tidigare och billigare

previous next 9 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit. Kostnad för förändring Man brukar säga att kostnaden för förändringar av ett system ökar exponentiellt över tiden Med XP verkar det som om kostnaden för förändring planar ut –Detta därför att vi hela tiden testar (automatiskt), gör så lite som möjligt (inga onödiga finesser som gör systemt mer komplext), gör saker på bara ett ställe, integrerar kontinuerligt och alltid omstrukturerar –Vi blir dessutom på grund av detta vana att hela tiden förändra och modifiera designen

previous next 10 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit. Fyra värden Kommunikation –Utvecklare kommunicerar med varandra Enkelhet –Vad är det enklaste som kan fungera? Återkoppling (feedback) –Tester, stories, systemet välstrukturerat och självförklarande Kurage –Fixa fel eller brister med stort kurage, dvs tveka inte

previous next 11 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit. Grundläggande principer Snabb återkoppling –Kort tid mellan aktion och feedback Antag enkelhet –Behandla ett problem som om det kan lösas otrolig enkelhet Inkrementell förändring –Lös problem som en serie av små förändringar Anamma förändring –Bästa lösningen är att lösa det viktigaste först men ha maximalt med möjligheter till variationer kvar Kvalitetsarbete –Alla vill göra ett så bra jobb som möjligt

previous next 12 Mjukvaruprocessen: översikt och repetition. XP: problemformulering. Junit. Basala element Kod –Till slut är det bara koden som räknas oavsett hur många diagram du ritat Test –Vi vet inte om något fungera om vi inte testar det –Testerna gör att vi kan tänka på ett problem på ett lite annorlunda sätt Lyssna –Lyssna på kunder, domänexperter osv Design –För att få ett bra system måste vi (självklart) designa även i XP