1. Utveckla i små steg

(1)

Extreme programming Sven-Olof Nyström

Alternativ utvecklingsmetodik:

Extreme Programming (XP) Kent Beck

Objectorienterad programmering Sida 1

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

(2)

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.

(3)

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

(4)

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]

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

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.