Az Extreme Programming ( Extreme Programming , XP ) az egyik agilis szoftverfejlesztési módszer . A módszertan szerzői Kent Beck , Ward Cunningham , Martin Fowler és mások.
A módszertan elnevezése a szoftverfejlesztés hasznos, hagyományos módszereinek és gyakorlatainak alkalmazásáról származik, új „extrém” szintre emelve azokat. Így például a kódrevízió végrehajtásának gyakorlata , amely abból áll, hogy egy programozó ellenőrzi a másik programozó által írt kódot, az "extrém" verzióban a "páros programozás", amikor az egyik programozó kódot ír, és a partnere ugyanakkor folyamatosan felülvizsgálja, hogy milyen kódot írt.
A módszert Kent Beck dolgozta ki a Chrysler Comprehensive Compensation System (C3) bérszámfejtési projektjén végzett munkája során. Beck 1996 márciusában lett a projekt vezető specialistája. Elkezdte fejleszteni a projektben használt fejlesztési módszertant, és könyvet írt erről Extreme Programming Explained (1999 októberében jelent meg) címmel. [1] A projektet 2000 februárjában zárták le.
A tizenkét alapvető extrém programozási technika (az Extreme programozás első kiadása szerint ) négy csoportba sorolható:
Az XP automatizált tesztek írását foglalja magában (kifejezetten más kódok logikájának tesztelésére írt kód). Különös figyelmet kell fordítani két típusú vizsgálatra:
Egy fejlesztő nem lehet biztos az általa írt kód helyességében, amíg az általa fejlesztett rendszer minden egységtesztje nem működik. Az egységtesztek (egységtesztek) lehetővé teszik a fejlesztők számára, hogy megbizonyosodjanak arról, hogy mindegyikük megfelelően működik-e. Más fejlesztőknek is segítenek megérteni, hogy miért van szükség egy adott kódrészletre és hogyan működik – a tesztkód tanulmányozása során világossá válik a tesztelt kód logikája, hiszen egyértelmű, hogyan kell használni. Az egységtesztek azt is lehetővé teszik a fejlesztő számára, hogy minden félelem nélkül újraaktiváljon .
A funkcionális tesztek célja a több (sokszor meglehetősen lenyűgöző méretű) rész kölcsönhatásából létrejövő logika működésének tesztelése. Kevésbé részletesek, mint az egységtesztek, de sokkal többet fednek le – vagyis azok a tesztek, amelyek végrehajtásuk során nagyobb mennyiségű kódot érintenek, nyilvánvalóan nagyobb eséllyel észlelnek bármilyen helytelen viselkedést. Emiatt az ipari programozásban a funkcionális tesztek írása gyakran elsőbbséget élvez az írási egységtesztekkel szemben.
Az XP esetében a TDD (az angol tesztvezérelt fejlesztés - fejlesztés tesztelésen keresztül ) elnevezésű megközelítés magasabb prioritást élvez. Ennek a megközelítésnek megfelelően először egy tesztet írnak, amely kezdetben sikertelen (mivel az a logika, amelyet ellenőrizni kellene, egyszerűen még nem létezik), majd a teszt sikerességéhez szükséges logika implementálódik. A TDD bizonyos értelemben kényelmesebben használható kód írását teszi lehetővé - ugyanis tesztíráskor, amikor még nincs logika, akkor a legegyszerűbb a leendő rendszer kényelméről gondoskodni.
A tervezési játék fő célja egy hozzávetőleges munkaterv gyors összeállítása és annak folyamatos frissítése, ahogy a feladat feltételei tisztázódnak. A tervezési játék műtermékei egy papírkártya-készlet, amely tartalmazza a vásárló kívánságait (ügyféltörténeteket), valamint egy hozzávetőleges munkatervet a termék következő egy vagy több kisebb verziójának kiadásához. Az a kritikus tényező, amely ezt a tervezési stílust hatékonysá teszi, hogy ebben az esetben az ügyfél felelős az üzleti döntések meghozataláért, a fejlesztő csapat pedig a műszaki döntésekért. Ha ezt a szabályt nem tartják be, az egész folyamat szétesik.
Az XP-ben nem az a "vásárló", aki fizeti a számlákat, hanem a szoftvertermék végfelhasználója. Az XP azt állítja, hogy az ügyfélnek állandóan kapcsolatban kell lennie, és elérhetőnek kell lennie kérdések esetén.
A páros programozás feltételezi, hogy az összes kódot ugyanazon a számítógépen dolgozó programozópárok hozták létre. Az egyik közvetlenül a program szövegével dolgozik, a másik az ő munkáját nézi, és követi a történések összképét. Ha szükséges, a billentyűzet szabadon áthelyezhető egyikről a másikra. A projekten végzett munka során a párok nincsenek rögzítve: ajánlatos összekeverni őket, hogy a csapat minden programozója jó elképzeléssel rendelkezzen az egész rendszerről. Így a páros programozás fokozza a csapaton belüli interakciót.
Ha elég gyakran integrálja a fejlesztés alatt álló rendszert, elkerülheti a vele kapcsolatos problémák nagy részét. A hagyományos módszerekben az integrációt általában a terméken végzett munka végén hajtják végre, amikor úgy tekintik, hogy a fejlesztés alatt álló rendszer összes összetevője teljesen készen áll. Az XP-ben a teljes rendszer kódintegrációja naponta többször megtörténik, miután a fejlesztők megbizonyosodtak arról, hogy minden egységteszt megfelelően működik.
Az újrafaktorálás egy olyan technika, amellyel a kódot a funkcionalitás megváltoztatása nélkül javítják. Az XP azt jelenti, hogy ha egyszer megírják a kódot, azt szinte biztosan többször is meg fogják ismételni a projekt során. Az XP fejlesztői kíméletlenül átdolgozzák a korábban megírt kódot, hogy javítsák azt. Ezt a folyamatot refaktorálásnak nevezik. A tesztlefedettség hiánya a rendszer feltörésétől való félelem miatt a refaktorálás elutasítását váltja ki, ami a kód fokozatos leépüléséhez vezet.
A termék verzióinak (kiadásainak) a lehető leggyakrabban gyártásba kell kerülniük. Az egyes verziókon végzett munkának a lehető legkevesebb időt kell igénybe vennie. Ugyanakkor minden verziónak elég értelmesnek kell lennie az üzleti élet szempontjából.
Minél korábban adják ki a termék első működő verzióját, annál hamarabb kezd a vásárló többletnyereséghez jutni emiatt. Ne feledje, hogy a ma megkeresett pénz többet ér, mint a holnap megkeresett pénz. Minél hamarabb kezdi el használni a terméket a vásárló, annál hamarabb kapnak tőle tájékoztatást a fejlesztők arról, hogy mi felel meg a vevő követelményeinek. Ezek az információk rendkívül hasznosak lehetnek a következő kiadás megtervezésekor.
Az XP abból indul ki, hogy a munka során a probléma körülményei többször változhatnak, ami azt jelenti, hogy a fejlesztés alatt álló terméket nem szabad előre teljesen és teljesen megtervezni. Ha már a munka kezdetén megpróbáljuk részletesen megtervezni a rendszert, az időpocsékolás. Az XP azt sugallja, hogy a tervezés olyan fontos folyamat, hogy a projekt teljes élettartama alatt folyamatosan kell végezni. A tervezést kis lépésekben, a folyamatosan változó követelmények figyelembevételével kell elvégezni. Minden egyes időpontban meg kell próbálnia az aktuális problémának megfelelő legegyszerűbb kialakítást használni, és a probléma körülményeinek változásával módosítani.
Kent Beck és Martin Fowler [2] azt javasolja, hogy az „egyszerű tervezést” a következő négy kritérium teljesítéseként írja le:
Robert Martin egyetért [3] ezekkel a szabályokkal, de korábbi munkájában [4] azt is javasolja, hogy az "egyszerű tervezést" a következő három alapelv alapján írja le:
Az architektúra egy rendszer összetevőinek és egymáshoz való viszonyának ábrázolása. A fejlesztőknek elemezniük kell a szoftverarchitektúrát, hogy megértsék, hol kell új funkcionalitást hozzáadniuk a rendszerhez, és hogy az új komponens mivel fog kölcsönhatásba lépni.
A rendszermetafora analóg azzal, amit a legtöbb technika architektúrának nevez. A rendszermetafora képet ad a csapatnak arról, hogyan működik a rendszer jelenleg, hol kerülnek hozzáadásra az új komponensek, és milyen formájúak legyenek.
Egy jó metafora kiválasztása megkönnyíti a fejlesztőcsapat számára a rendszer működésének megértését. Néha ezt nem könnyű megtenni.
Ezen a ponton Bob Martin elismerte, hogy a rendszermetafora elavult, és a Domain Driven Design-ra kellene felváltani .
A munkavégzés során minden csapattagnak meg kell felelnie a közös kódolási szabványok követelményeinek. Ezáltal:
Ha a csapat nem használ egységes kódolási szabványokat, akkor a fejlesztők számára nehezebbé válik az újrafaktorálás; párban történő partnerváltáskor több nehézség adódik; általában nehéz a projekt előrehaladása. Az XP keretein belül meg kell nehezíteni annak megértését, hogy ki a szerzője ennek vagy annak a kódrészletnek - az egész csapat egységesen, egy emberként működik. A csapatnak szabályokat kell alkotnia, majd minden csapattagnak követnie kell ezeket a szabályokat a kódírás során. A szabályok listája nem lehet kimerítő vagy túl terjedelmes. A feladat az, hogy olyan általános irányelveket fogalmazzunk meg, amelyek a kódot minden csapattag számára érthetővé teszik. A kódolási szabványnak eleinte egyszerűnek kell lennie, majd fokozatosan összetettebbé válhat, ahogy a fejlesztőcsapat tapasztalatokat szerez. Nem kell túl sok időt tölteni a szabvány előkészítésével.
A kollektív tulajdonjog azt jelenti, hogy a csapat minden tagja felelős az összes forráskódért . Így mindenkinek joga van megváltoztatni a program bármely részét. A páros programozás ezt a gyakorlatot támogatja: különböző párokban dolgozva minden programozó megismeri a rendszer kódjának minden részét. A kollektív kódtulajdonlás fontos előnye, hogy felgyorsítja a fejlesztési folyamatot, hiszen ha hiba lép fel, azt bármelyik programozó ki tudja javítani.
Minden programozónak a kód megváltoztatásának joga azzal a kockázattal jár, hogy hibákat vezetnek be olyan programozók, akik azt hiszik, hogy tudják, mit csinálnak, de nem vesznek figyelembe bizonyos függőségeket. Az extrém programozók úgy vélik, hogy a jól meghatározott egységtesztek megoldják ezt a problémát: ha az át nem vizsgált függőségek hibákat generálnak, akkor az egységtesztek következő futtatása sikertelen lesz, és felfedi a problémát.
| Szoftverfejlesztés | |
|---|---|
| Folyamat | |
| Magas szintű koncepciók | |
| Útvonalak |
|
Fejlesztési módszertanok | |
| Modellek |
|
| Figyelemre méltó alakok |
|