Kezdetek
eXtreme Programming programozástechnika
Martin Fowler : The New Methodology Legtöbb projekt követelményei állandóan változnak Megoldást „adaptív” módszerek
Készítette: Török Balázs G5-S8
Kezdetek - „Adaptivitás”
Fı célja
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
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. Kommunikáció 1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
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. Egyszerőség 1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
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.
3. Visszajelzés 1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
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.”
4. Bátorság 1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
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
2
5. Tisztelet 1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
1. 2. 3. 4. 5.
Kommunikáció Egyszerőség Visszajelzés Bátorság Tisztelet
Csapattagok tisztelete Magunk tisztelete
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:
Story card:
Fejlesztık + Ügyfél: release megbeszélés → iteráció tartalma Ü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”:
„Elıny”:
Feszített munkatempó Állandó koncentrálás 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
3
Test-First 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 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
4
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
Standish Group - Chaos jelentés 1999 - 2004
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.
5
Forrás Juhász Sándor Ferenc: Az Extreme Programming programozástechnikai elvei (2006. november 30.)
Köszönöm a figyelmet!
6
