Alternativ utvecklingsmetodik:
Extreme Programming (XP)
Kent Beck
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.
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
2. Planering
• Fokusera hela tiden på nästa version av systemet.
• Bestäm innehåll beroende på behov och tekniska
aspekter
3. Metafor
En kort historia om hur systemet fungerar
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
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
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.
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!
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.
(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
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
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)
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]
Exempel: Ska man skriva
void f() { ...
}
eller void f() {
...
}
Om flera personer ska arbeta med samma kod måste man enas
