eXtreme Programming programozástechnika Készítette: Török Balázs G5-S8
Kezdetek Martin Fowler : The New Methodology Legtöbb projekt követelményei állandóan változnak Megoldást „adaptív” módszerek
Kezdetek - „Adaptivitás” Nagyobb hangsúly (XP értékei): - 1. kommunikáció - 2. egyszerőség - 3. visszajelzés - 4. bátorság - 5. tisztelet Minimális hangsúly: - prediktív hozzáállás, - bürokratikus hozzáállás Számos új lightweight vagy agilis módszertan Kent Beck, Extreme Programming
Fı célja Változtatások költségvonzatának csökkentése Példa: SSADM: követelmény adott, nincs változás, ÁLTALÁBAN… DE, ha van változtatás → NAGY KÖLTSÉG Törekvés más alapvetı értékek, elvek, és gyakorlatok bevezetésére:
egy XP projekt rugalmasabb a késıbbi változtatásra
1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
1. Kommunikáció Fejlesztıknek megmondani, hogy mi a feladat. Az XP technika = gyors információ-rendszerezı és terjesztı technika A cél: minden fejlesztı ugyanúgy lássa a rendszert, ahogy a majdani felhasználók is látni fogják. Az XP „szereti”:
egyszerő tervet Metaforát ügyfél - fejlesztıi együttmőködést gyakori szóbeli kommunikációt visszajelzéseket
1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
2. Egyszerőség Kezdjük el a lehetı legegyszerőbben, és folyamatosan dolgozzuk át a programot, hogy egyre jobb és jobb legyen. XP ellenzık vallják: ez hátrány, mivel:
következı hónap → új követelmény → rendszer átdolgozás → idıveszteség >= megvalósított, de késıbb haszontalan featureökre fordított idı.
Az egyszerőség elve:
kód zsúfoltság → fejlesztı: „azt sem tudom ez miért van itt” & „ezt a metódust én írtam?” → többletmunka >>> folyamatos átdolgozás által generált munka.
Az egyszerőség segíti a kommunikációt:
egyszerő terv + egyszerő kód → sok programozó könnyen megért.
1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
3. Visszajelzés Fejlesztés több területére vonatkozik:
Visszajelzés a rendszertıl: részegység-tesztelés Visszajelzés az ügyféltıl: 2-3 hetente funkcionálistesztelés Visszajelzés a csapattól: ügyféltıl új igény → reakció → visszajelzés (idı, pénz)
Visszajelzés + egyszerőség + kommunikáció Kent Beck: „Az optimizmus szakmai ártalom a programozóknál, és a visszajelzés rá a gyógyír.”
1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
4. Bátorság Jellemzıi példákban:
Programkód „mai napra” írása Kódátdolgozás (egyszerősítés, átláthatóság) Megírt kód „eldobása” Állandó gondolkodás egy problémán → másnap egy perc alatt megoldódik
1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
5. Tisztelet Csapattagok tisztelete Magunk tisztelete
1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
eXtreme Programming folyamata 1. Cél behatárolás: a szoftver release-k fejlesztése. 2. Release: 1-2 hetes Iteráció eredménye
Release és interation planning game: Fejlesztık + Ügyfél: release megbeszélés → iteráció tartalma
Story card: Ügyfél: funkcionalitások írása → Fejlesztık: funkciók sorbarendezése → Ügyfél: legfontosabb funkciók összeállítása a következı release-ra illetve iterációra
Acceptance test: Ügyfél: Példákon keresztül leírt funkcionalitás leírása
3. Iteráció vége - összes (automatizált) Acceptance teszt sikeres lefutása.
Story card implementálása 1. Fejlesztık párban dolgoznak:
„Hátrány”: Feszített munkatempó Állandó koncentrálás
„Elıny”: Egymás hibáinak észrevétele Egymástól tanulás
2. Session: néhány Story Card implementálása (pár óra) 3. Verzió lekérés: után teszteset készítése → Implementálás → teszteset készítése → Implementálás → … 4. Story card kész: nem tudnak a fejlesztık újabb tesztet írni 5. Integrációs gép: új, LETESZTELT, MŐKÖDİ funkciók „commit”tálása
Elvek 1. Test-First Development 2. Test-Driven Development
Test-First Development 1. Teszteset írása
Szintaktikai hiba megjelenése, a még nem létezı kód miatt
2. Szintaktikai hiba elhárítása
Teszt lefordul, lefut, hibát dob
3. Funkció implementálása
Csak és kizárólag annyi, amitıl sikeres a teszt
Test-First Development
Test-First Development A tesztek csökkentik a bug-ok számát az új funkciókban. A tesztek jó dokumentációk. A tesztek korlátozzák az osztályok feladatait. A tesztek javítják a programkód minıségét. A tesztek megvédnek a bug-ok újra bevezetésétıl. A tesztek csökkentik a félelemérzetet. Felgyorsul a fejlesztés.
Elvek 1. Test-First Development 2. Test-Driven Development
Refactoring Jelentése:
1. (fn) Szoftver belsı struktúráján végrehajtott olyan módosítás, ami könnyebben érthetıvé és könnyebben módosíthatóvá teszi azt anélkül, hogy a kívülrıl megfigyelhetı viselkedésen módosítana. 2. (ige, angolul), a fenti tevékenység kivitelezése.
Refactoring Kent Beck: „code smells”:
Duplikált kód Terjedelmes osztály Feature Envy Data Clumps
Refactoring folyamata
Test-Driven Development Test-Driven Development:
Test-First Development + Refactoring
Test-Driven Development
Elvek 1. Test-First Development 2. Test-Driven Development
Test-Driven Development 1. Az új funkciók egyszerő teszteléséhez és implementálásához elengedhetetlen az egyszerő design. 2. Az egyszerőség eléréséhez a refactoring-ot alkalmazzuk 3. A refactoring viszont elképzelhetetlen az automatizált tesztek nyújtotta „védıháló” nélkül.
Standish Group - Chaos jelentés 1999 - 2004
Forrás Juhász Sándor Ferenc: Az Extreme Programming programozástechnikai elvei (2006. november 30.)
Köszönöm a figyelmet!
