Extreme programming Sven-Olof Nyström
Alternativ utvecklingsmetodik:
Extreme Programming (XP) Kent Beck
Objectorienterad programmering Sida 1
Extreme programming Sven-Olof Nyström
Motivering
Extreme programming (XP) kan ses som en reaktion på den traditionella utvecklingsmetodiken (till exempel objekt-orienterad analys och design), och ett försök att uppnå samma mål med andra medel.
De tolv reglerna nedan sammanfattar XP.
Objectorienterad programmering Sida 2
Extreme programming Sven-Olof Nyström
1. Utveckla i små steg
• Börja med ett enkelt system (så enkelt som är rimligt)
• Ta fram nya, utökade versioner med jämna mellanrum
Objectorienterad programmering Sida 3
Extreme programming Sven-Olof Nyström
2. Planering
• Fokusera hela tiden på nästa version av systemet.
• Bestäm innehåll beroende på behov och tekniska aspekter
Objectorienterad programmering Sida 4
Extreme programming Sven-Olof Nyström
3. Metafor
En kort historia om hur systemet fungerar
Objectorienterad programmering Sida 5
Extreme programming Sven-Olof Nyström
4. Automatiska tester
• Skriv en svit av tester för att testa systemet i stort och dess enskilda delar (unit testing)
• Skriv tester som beskriver önskat beteende innan du börjar koda!
• Testerna blir specifikationen
Objectorienterad programmering Sida 6
Extreme programming Sven-Olof Nyström
5. Enkelhet
• Skriv det enklaste programmet som klarar alla tester
• ingen duplicerad kod
• minsta möjliga antalet klasser&metoder
• ingen “onödig” funktionalitet
• koda inte för framtiden
• Programmet ska uttrycka programmerarens avsikt
Objectorienterad programmering Sida 7
Extreme programming Sven-Olof Nyström
6. Refactoring
Försök ständigt förenkla programmet!
Exempel: Två klasser som gör ungefär samma sak—ersätt dem med en enda klass.
Inte trivialt: Klasserna kan ha olika metodnamn etc.
Vi kan bli tvungna att ändra kod som använder klasserna.
Annat exempel: Två klasser har delvis samma funktionalitet.
Skapa en abstrakt klass som båda ärver från.
Objectorienterad programmering Sida 8
Extreme programming Sven-Olof Nyström
7. Parprogrammering
All programmering görs i grupper av två Två programmerare—ett tangentbord
Grupperna kan variera beroende på (tex) arbetsuppgift Fördelar: Undvik enkla misstag .
Nackdel: Halvera arbetsstyrkan!
Objectorienterad programmering Sida 9
Extreme programming Sven-Olof Nyström
8. Gemensamt ägande av kod
• Alla har ansvar för all kod
• Alla har rätt att ändra
• Om en programmerare (ett par) ser en brist i din kod (eller en möjlighet att förbättra) är det deras
skyldighet att göra detta.
Objectorienterad programmering Sida 10
Extreme programming Sven-Olof Nyström
(Vad är alternativen till gemensamt ägande?)
• Inget ägande av kod (vet inte om detta nånsin förekommit)
• Alla äger sitt avsnitt
– Om nån annan vill ändra i din kod måste han be dig
– Stabilt, men förändringar kan vara svåra att genomföra
Objectorienterad programmering Sida 11
Extreme programming Sven-Olof Nyström
9. Ständig integration
Nyskriven kod ska testas i systemet efter (högst) några timmar.
Varje par har ansvar för att föra in sin förändring och se till att den klarar testsviten till 100%
Om de inte klarar det—släng ändringarna
Objectorienterad programmering Sida 12
Extreme programming Sven-Olof Nyström
10. 40-timmarsvecka
Populärt låta folk arbeta mer än så
• Mänskliga skäl
• Långa arbetsveckor är ofta ett sätt att dölja brister i projektplanering
• Om man är trött sjunker produktiviteten (och man gör fler misstag)
Objectorienterad programmering Sida 13
Extreme programming Sven-Olof Nyström
11. Kund på plats
Ha en “äkta kund” (dvs en kund som ska använda systemet) på plats
Hjälper programmerarna att bedöma vad som är viktigt Provkör systemet
[Rimligtvis bör kunden fortfarande kunna utföra en del av sina vanliga arbetsuppgifter]
Objectorienterad programmering Sida 14
Extreme programming Sven-Olof Nyström
12. Kodningsstandarder
Exempel: Ska man skriva void f() {
...
} eller void f() { ...
}
Om flera personer ska arbeta med samma kod måste man enas om en standard
Objectorienterad programmering Sida 15
Extreme programming Sven-Olof Nyström
Sammanfattning:
Traditionell systemutveckling lägger stor vikt på planering.
Extreme programming fokuserar på programmet...
...och lägger allt ansvar på programmerarna.
Flera av reglerna strävar till att minska risken att programmet går överstyr: parprogrammering, testning, ständig integration, refactoring.
I stället för analys och design i separata faser arbetar man direkt mot kund.
Objectorienterad programmering Sida 16