Aktiviteter i praktiken Extreme Programming Aktivitet ett: Kommunicera! Sven and Olle are two farmers way up in the northernmost part of Scandinavia, where people are few and far between and words are even fewer and further between. They meet one day by the side of the road. Sven, who has recently moved to the northern expanse from the capital to take up farming, breaks the silence. - Say Olle, one of my cows has colic. Didn't one of your cows have colic? - Yup. - What did you do about it? - I gave her gasoline to drink. A week later they meet again. Sven cautiously breaks the silence. - Say Olle, I thought you said you gave your cow gasoline for the colic. - Yup. - I gave my cow gasoline and she died! - So did mine. In our haste to get technology and services to market, we all too often miss asking the necessary follow-up questions. Martin Karlsson marka@itn.liu.se K7522 011 36 34 63 07-03-20 Martin Karlsson - XP 2 Aktiviteter Parprogrammering Två programmerare jobbar sida vid sida En programmerare, föraren, har kontrollen över tangentbordet och implementerar aktivt. Den andre programmeraren, observatören, observerar kontinuerligt det som föraren kodar för att identifiera taktiska defekter Vid behov kan de två programmerarna brainstorma runt hinder de möter på vägen och eftersom de ibland byter roller, arbetar de jämlikt tillsammans. 07-03-20 Martin Karlsson - XP 3 07-03-20 Martin Karlsson - XP 4 Parprogrammeringens sju myter Arbetsbördan kommer att dubbleras då två personer gör samma arbete som en person kan göra Jag får aldrig jobba ensam. Usch och fy! Det fungerar bara med rätt programmeringspartner Parprogrammering är bra för träning, men när du vet vad du gör, så är det bara slöseri med tid Parprogrammeringens sju myter Jag får aldrig känna att det jag gör är mitt. Jag måste dela det med min programmeringspartner. Kompilatorn kan kvalitetskontrollera bättre än min observatör Jag får bara tillräckligt med arbete genomfört när jag arbetar ensam. Parprogrammering gör att det inte blir något gjort. 07-03-20 Martin Karlsson - XP 5 07-03-20 Martin Karlsson - XP 6 1
Parprogrammeringens synergieffekter Pair pressure Pair negotiation Pair courage Pair reviews Pair debugging Pair learning Pair trust Arbetsplatsen Två personer ska kunna sitta bekvämt bredvid varandra framför en lagom stor skärm När roller byts innebär det att man flyttar tangentbord och mus en liten bit åt sidan Caves and Commons (Kent Beck, 2001) Egna utrymmen vid sidan om, parutrymmen i mitten De kralligaste maskinerna i mitten 07-03-20 Martin Karlsson - XP 7 07-03-20 Martin Karlsson - XP 8 Kommunikation mellan par Effektiv kommunikation inom och mellan par är viktig Programmerarna i teamet behöver se varandra Det är bra om man råkar höra vad de andra paren diskuterar, fast det får inte störa. Dock verkar de flesta par tycka att man lätt kan stänga ute all kommunikation som inte är viktig, när man är mitt uppe i parprogrammerandet. Interaktion mellan par är viktig för teamkänslan Partnerbyte Byt ofta, men informellt Parprogrammera med den person som passar bäst för ändamålet Parprogrammera inte bara med den som ni tycker är trevligast/snyggast/luktar bäst När och hur byter man? Short, daily, stand-up meetings Just say yes 07-03-20 Martin Karlsson - XP 9 07-03-20 Martin Karlsson - XP 10 Gruppstorlek Optimalt med 10-12 personer för maximalt utbyte och god uppbyggnad av personliga förhållanden Dessutom är det max för att man ska få en god uppfattning om vad all kod i alla delar av systemet gör och hur den är uppbyggd Övrigt Alla programmerare har olika preferenser vad gäller utvecklingsmiljö. Första veckorna man parprogrammerar bör man prova olika miljöer för att se hur bra det passar för två istället för en En liten, men dock viktig sak. Observatören får inte peta på skärmen med fingret. Använd en penna istället! 07-03-20 Martin Karlsson - XP 11 07-03-20 Martin Karlsson - XP 12 2
Sju tips för effektiv parprogrammering Ta raster Var ödmjuk Var självsäker / Var mottaglig Kommunicera Lyssna Var en lagspelare Finslipa balansen mellan att kompromissa och att stå på sig Men fungerar det? Parprogrammerare spenderar ungefär 15% mer tid än individuella programmerare på samma uppgift. Dock är denna extra tid inte statistiskt signifikant Parprogrammerare får 15% färre fel i koden än individuella programmerare. Denna högre kvalitet är statistiskt signifikant 95% av parprogrammerare säger att de trivs bättre med arbetet, är mer självsäkra och litar på att den kod de har producerat fungerar. I det långa loppet tjänar man alltså både moral och pengar, eftersom det tar mycket lång tid att rätta buggar. http://collaboration.csc.ncsu.edu/laurie/papers/dissertation.pdf 07-03-20 Martin Karlsson - XP 13 07-03-20 Martin Karlsson - XP 14 Testdriven utveckling Testdriven utveckling lockar programmerarna att skriva kod som är automatiskt testbar, exempelvis returnera ett värde från en metod istället för att skriva ut värdet i metoden. Fördelar Produktion av pålitliga system Kvalitetsökning av testsatsningen Minskning av testansträngningen Och därmed tidsvinst Testdriven utveckling Historiskt är debugging en klar flaskhals inom programkonstruktion Ju längre en defekt finns i systemet desto svårare och kostsamt är det att ta bort den Testdriven utveckling ger direkt feedback på felaktigheter i kod Därmed kan man hitta defekter och dess orsaker med lätthet 07-03-20 Martin Karlsson - XP 15 07-03-20 Martin Karlsson - XP 16 Hur fungerar det? Testdriven utveckling använder sig av en testfall som samlas i en testbänk Genom att kontinuerligt köra dessa automatiska testfall kan man lätt se om en förändring påverkar systemet negativt Den automatiska testbänken gör därmed att ny funktionalitet lätt integreras i koden Men hur gör man? Man skriver testfall innan man implementerar metoden, Man behöver inte skriva testfall för alla metoder, bara de som är produktionsspecifika. Tanken är dessutom inte att bara skriva testfall före implementation. Ytterligare testfall kan givetvis läggas till i efterhand. Integrationstest brukar skapas efter implementation. Testdriven utveckling formar eller förändrar våra designval till att förenkla kod och skapa ökad flexibilitet i systemet 07-03-20 Martin Karlsson - XP 17 07-03-20 Martin Karlsson - XP 18 3
Forskning på testdriven utveckling Forskning på testdriven utveckling Jeff Langr (ObjectMentor) jämför två implementationer av identisk kod. En framtagen med testdriven utveckling och en utan. Koden hade 20 testfall och 6 metodere, medel antal rader kod per metod var 25. Små metoder kan öka underhållbarhet, kommunicerbarhet och flexibilitet av kod Resultat Passerade testfall 0 1-3 4-7 TDU 9% 41% 50% Ej TDU 43% 30% 27% Inte bara hade TDU bättre teststatistik, men även metoder med färre rader kod. Samma funktionalitet, men bättre design. 07-03-20 Martin Karlsson - XP 19 07-03-20 Martin Karlsson - XP 20 XP och testdriven utveckling Två varianter Forma design utefter ett story-kort eller brainstormingsession Börja all implementation med att skriva ett automatiskt testfall som uppfyller kraven för metoden, utan någon design Det andra fallet kräver kunskaper inom omfaktorisering (). Programmerarna inser att de inte når fram till den bästa designen vid första försöket. Testdriven utveckling Skriv test Aktiviteter Kompilera testet. Första gången ska det fallera, eftersom du inte har skrivit koden som testet ska anropa och testa Implementera precis tillräckligt för att testet ska gå igenom Kasta koden Kör testet och kolla om det fallerar Färdig 07-03-20 Martin Karlsson - XP 21 07-03-20 Martin Karlsson - XP 22 Testcykeln i XP 1. Skriv ett test 2. Kompilera testet. Det ska fallera, eftersom du inte har skrivit koden som testet ska anropa och testa 3. Implementera precis tillräckligt för att kompileringen ska gå igenom 4. Kör testet och kolla om det fallerar 5. Om det fallerar, kasta all kod och implementera precis tillräckligt igen för att testet ska gå igenom 6. Kör testet och kolla så att det inte fallerar 7. Omfaktorisera för förtydligande och borttagning av duplicit kod Testcykeln i XP Hur lång tid tar cykeln? Mellan 1 och 5 minuter. 10 minuter max. Om det tar längre tid då? Skapa mindre testfall Går det inte slött att koda på det här viset? Faktiskt inte. Om man skulle planera sin design innan så tar ju det också tid, och om fallet inte används sedan så har man designat i onödan 07-03-20 Martin Karlsson - XP 23 07-03-20 Martin Karlsson - XP 24 4
Verktyg för testdriven utveckling Testbänken brukar vara uppbyggd av ett ramverk för testning. Det finns kommersiella och det finns självklart open source-ramverk. För Java är Kent Beck och Erich Gammas junit den vanligaste. Men det finns olika varianter på den s.k. xunitgrunden på följande länk: http://c2.com/cgi/wiki?testingframework Spikes Test av hur komplex en uppgift kan vara Leta - ladda hem - ändra - testa - kasta Behövs inom nya områden eller områden man är osäker på i allmänhet Ger mer exakta tidsuppskattningar Ej bortkastad tid, bara kod Två typer Arkitektonisk spike Konstruktionsspike 07-03-20 Martin Karlsson - XP 25 07-03-20 Martin Karlsson - XP 26 In anything at all, perfection is finally attained, not when there is no longer anything to add, but when there is no longer anything to take away - Saint-Exupéry Förbereder dig för förändring eftersom att ändra kod blir en daglig syssla, en vana Möjliggör förändring eftersom koden blir enkel och lättförståelig Låter dig dessutom lära dig olika aspekter av programmering snabbare än normalt, eftersom det krävs att du ändrar din kod kontinuerligt utan att förändra dess funktionalitet 07-03-20 Martin Karlsson - XP 27 07-03-20 Martin Karlsson - XP 28 Grundprincipen är att om du ser något i koden som är svårförståeligt och/eller komplicerat, refaktorisera! Du ska inte göra det om koden inte fungerar och behöver skrivas om (eller om den helt enkelt är under uppbyggnad) Sluta refaktorisera när koden är bra, inte när den är perfekt Så... hur gör man? Smelly code Duplicerad kod Långa metoder Lång parameterlista Stora klasser Utspridda ändringar Om ändringar måste införas på flera ställen Switch/Case-satser, villkorskomplexitet Ger upphov till farliga ändringar... förenkla Onödig generalitet Primitiva tvångstankar Javas inbyggda typer är *mycket* bättre än klassobjekt! Offrar tydlighet och skydd Kommentarer Är kommentarerna där som deodorant för dålig kod? 07-03-20 Martin Karlsson - XP 29 07-03-20 Martin Karlsson - XP 30 5
Aktiviteter (revisited) Andra vanliga refaktoriseringar Encapsulate data En variabel görs private och enda sättet att ändra den är genom en publicfunktion Extract method En metod skrivs i en klass, men använder väldigt lite av den, därmed flyttas den till någon klass där den passar bättre Extract class Flera metoder och data hör inte ihop med de andra, de bryts ut och skapar en egen klass, en subklass eller en superklass Inline method En metods kod är precis lika tydlig som metodens namn. Byt ut anropet till koden mot dess kod 07-03-20 Martin Karlsson - XP 31 07-03-20 Martin Karlsson - XP 32 6