Extrém programozási gyakorlatok
Az extrém programozás (XP) egy agilis szoftverfejlesztési módszer, amelyet szoftverprojektek megvalósítására használnak. Ez a cikk részletezi az ebben a módszertanban alkalmazott gyakorlatokat. Az extrém programozásnak 12 gyakorlata van, négy területre csoportosítva, amelyek a szoftverfejlesztés legjobb gyakorlataiból származnak.[1]
Finom léptékű visszajelzés[szerkesztés]
Páros programozás[szerkesztés]
A páros programozás azt jelenti, hogy az összes kódot két ember állítja elő, akik egy feladatra programoznak egy munkaállomáson. Az egyik programozó irányítja a munkaállomást, és leginkább a kódoláson gondolkodik részletesen. A másik programozó jobban összpontosít a teljes képre, és folyamatosan felülvizsgálja az első programozó által előállított kódot. A programozók akár percenként, vagy óránként cserélnek szerepet.
A párok nem állandóak; A programozók gyakran cserélnek partnereket, így mindenki tudja, mit csinál, és mindenki ismeri az egész rendszert, még a képességeiken kívül eső részeket is. Ily módon a páros programozás javíthatja a csapatszintű kommunikációt is. (Ez együtt jár a kollektív tulajdon fogalmával is).
Tervezési játék[szerkesztés]
Az extrém programozáson belüli fő tervezési folyamatot Tervezési Játéknak nevezik. A játék egy találkozó, amelyre ismétlésenként egyszer kerül sor, jellemzően hetente egyszer. A tervezési folyamat két részre oszlik:
- Kiadás tervezése: Ez arra összpontosít, hogy meghatározza, milyen követelményeket tartalmaznak az adott rövid távú kiadások, és mikor kell azokat teljesíteni. Az ügyfelek és a fejlesztők egyaránt részesei ennek. A kiadás tervezése három szakaszból áll:
- Felfedező szakasz: Ebben a fázisban az ügyfél megadja a rendszerrel szemben támasztott nagy értékű követelmények rövid listáját. Ezeket a felhasználói történet kártyákra írják fel.
- Kötelezettségvállalási szakasz: A kötelezettségvállalási szakaszban a vállalkozások és a fejlesztők elkötelezik magukat a benne foglalt funkciók és a következő kiadás dátuma mellett.
- Kormányzási szakasz: Az irányítási fázisban a terv módosítható, új követelményekkel egészíthető ki és/vagy a meglévő követelmények módosíthatók vagy törölhetők.
- Iterációs tervezés: a fejlesztők tevékenységeit és feladatait tervezi. Ebben a folyamatban az ügyfél nem vesz részt. Az iterációs tervezés is három szakaszból áll:
- Feltárási fázis: Ebben a fázisban a követelményt különböző feladatokra fordítják. A feladatokat feladatkártyákon rögzítjük.
- Elköteleződési szakasz: A feladatokat a programozók osztják ki, és a végrehajtáshoz szükséges időt becsülik.
- Irányítási fázis: A feladatok végrehajtása megtörténik, és a végeredmény illeszkedik az eredeti felhasználói történethez.
A tervezési játék célja, hogy a terméket a szállításba vezesse. Ahelyett, hogy megjósolná a pontos dátumokat, hogy mikor lesz szükség a teljesítményekre, és mikor kell azokat előállítani, ami nehezen kivitelezhető, a cél az, hogy a projektet egy egyszerű megközelítéssel "irányítsa" a teljesítés felé. A Planning Game megközelítést a nem szoftveres projektek és csapatok is átvették az üzleti agilitással összefüggésben.
A kiadás tervezése[szerkesztés]
Feltárási szakasz[szerkesztés]
Ez egy iteratív folyamat a követelmények összegyűjtésére és az egyes követelmények munkára gyakorolt hatásának becslésére.
- Írjon egy történetet: Az üzletnek amikor problémája van; egy értekezlet során a fejlesztés megpróbálja meghatározni ezt a problémát és követelményeket kérni. Az üzleti probléma alapján egy történetet (user story) kell írni. Ezt az üzlet végzi, ahol rámutatnak arra, hogy mit szeretnének a rendszer egy részétől. Fontos, hogy a fejlődés ne legyen hatással erre a történetre. A történet egy felhasználói történetkártyára van írva.
- Becsüljön meg egy történetet: A fejlesztés megbecsüli, hogy mennyi időbe telik a történetkártya által feltételezett munka végrehajtása. A fejlesztés tüskés megoldásokat is létrehozhat a probléma elemzésére vagy megoldására. Ezeket a megoldásokat a becsléshez használják, és elvetik, amint mindenki világos képet kap a problémáról. Ez megint csak nem befolyásolhatja az üzleti követelményeket.
- Történet felosztása: Minden tervezési kritikus összetettséggel foglalkozni kell az iterációs tervezés megkezdése előtt. Ha a fejlesztés nem képes megbecsülni a történetet, fel kell osztani és újra meg kell írni.
Ha az üzlet nem tud több követelményt felmutatni, akkor az ember az elkötelezettségi szakaszba lép.
Elköteleződési szakasz[szerkesztés]
Ez a fázis magában foglalja a költségek, hasznok és az ütemterv hatásának meghatározását. Négy összetevője van:
- Rendezés érték szerint: A Vállalkozás az üzleti érték szerint rendezi a felhasználói történeteket.
- Rendezés kockázat szerint: A fejlesztés kockázat szerint rendezi a történeteket.
- Sebesség beállítása: A fejlesztés határozza meg, hogy milyen sebességgel tudják végrehajtani a projektet.
- Hatókör kiválasztása: A következő kiadásban befejeződő felhasználói történetek kerülnek kiválasztásra. A felhasználói történetek alapján kerül meghatározásra a megjelenés dátuma.
Rendezés érték szerint[szerkesztés]
Az üzleti oldal üzleti érték szerint rendezi a felhasználói történeteket. Három kupacba rendezik őket:
- Kritikus: olyan történetek, amelyek nélkül a rendszer nem tud működni, vagy nincs értelme.
- Jelentős üzleti érték: Nem kritikus felhasználói történetek, amelyek jelentős üzleti értékkel rendelkeznek.
- Jó, ha van: olyan felhasználói történetek, amelyeknek nincs jelentős üzleti értéke.
Rendezés kockázat szerint[szerkesztés]
A fejlesztők kockázat szerint rendezik a felhasználói történeteket. Három csoportba is sorolhatók: alacsony, közepes és magas kockázatú felhasználói történetek. A következő egy példa erre a megközelítésre:
- Határozza meg a kockázati indexet: Adjon minden felhasználói történetnek egy indexet 0-tól 2-ig a következő tényezők mindegyikéhez:
- Teljesség (tudjuk a történet összes részletét?)
- Teljes (0)
- Hiányos (1)
- Ismeretlen (2)
- Volatilitás (valószínű, hogy megváltozik?)
- alacsony (0)
- közepes (1)
- magas (2)
- Bonyolultság (mennyire nehéz felépíteni?)
- egyszerű (0)
- szabvány (1)
- komplex (2)
- Teljesség (tudjuk a történet összes részletét?)
Minden indexek a felhasználó történetet adunk, hozzárendeljük a felhasználói történetek a kockázati index alacsony – közepes (2 – 4), vagy magas –
Irányítási fázis[szerkesztés]
Az irányítási fázison belül a programozók és az üzletemberek "irányíthatják" a folyamatot. Vagyis változtatásokat eszközölhetnek. Az egyes felhasználói történetek vagy a különböző felhasználói történetek relatív prioritásai változhatnak; a becslések tévesnek bizonyulhatnak. Ez a lehetőség a terv megfelelő kiigazítására.
Iterációs tervezés[szerkesztés]
Figyelembe véve a tervezendő csapatsebesség-történetpontokat. Az iteráció időtartama 1-3 hét lehet.
Feltárási szakasz[szerkesztés]
Az iterációs tervezés feltáró szakasza a feladatok létrehozásáról és azok megvalósítási idejének becsléséről szól.
- A követelmény fordítása feladatokra: Helyezze el a feladatkártyákra.
- Feladat egyesítése/felosztása: Ha a programozó nem tudja megbecsülni a feladatot, mert az túl kicsi vagy túl nagy, akkor a programozónak kombinálnia vagy fel kell osztania a feladatot.
- Feladat becslése: Becsülje meg a feladat végrehajtásához szükséges időt.
Elköteleződési szakasz[szerkesztés]
Az iterációs tervezés kötelezettségvállalási szakaszában a programozók olyan feladatokat kapnak, amelyek a különböző felhasználói történetekre hivatkoznak.
- A programozó elfogad egy feladatot: Minden programozó kiválaszt egy feladatot, amelyért felelősséget vállal.
- A programozó megbecsüli a feladatot: Mivel most a programozó felelős a feladatért, neki kell megadnia a feladat végső becslését.
- Beállított terhelési tényező: A terhelési tényező az ideális gyakorlati fejlesztési időt programozónként egy iteráción belül. Például egy 40 órás hétben, ahol 5 órát szentelnek az értekezleteknek, ez nem több 35 óránál.
- Kiegyenlítés: Amikor a csapat összes programozója megkapta a feladatokat, összehasonlítjuk a feladatok becsült idejét és a terhelési tényezőt. Ezután a feladatokat kiegyensúlyozzák a programozók között. Ha egy programozó túlterhelt, más programozóknak át kell venniük a feladatai egy részét, és fordítva.
Irányítási fázis[szerkesztés]
A feladatok végrehajtása az iteráció irányító szakaszában történik.
- Szerezzen feladatkártyát: A programozó megkapja a feladatkártyát az egyik feladathoz, amelyre elkötelezte magát.
- Partner keresése: A programozó egy másik programozóval együtt hajtja végre ezt a feladatot. Erről bővebben a Páros programozás gyakorlatban van szó.
- A feladat megtervezése: Ha szükséges, a programozók megtervezik a feladat funkcionalitását.
- Végezze el a feladatot tesztvezérelt fejlesztéssel (TDD) (lásd alább)
- Funkcionális teszt futtatása: Funkcionális tesztek futnak (a kapcsolódó felhasználói történet és feladatkártya követelményei alapján).
Tesztvezérelt fejlesztés[szerkesztés]
Az egységtesztek olyan automatizált tesztek, amelyek a kód egyes részei (pl. osztályok, metódusok) működőképességét tesztelik. Az XP-n belül az egységtesztek az esetleges kód kódolása előtt íródnak. Ennek a megközelítésnek az a célja, hogy arra ösztönözze a programozót, hogy gondolkodjon olyan körülményeken, amelyek között a kódja meghibásodhat. Az XP azt mondja, hogy a programozó befejez egy bizonyos kódrészletet, amikor nem tud további feltételeket felhozni, amelyek esetén a kód meghibásodhat.
A tesztvezérelt fejlesztés a következő lépések gyors átfutásával megy végbe, és minden lépés legfeljebb percet vesz igénybe, lehetőleg sokkal kevesebbet. Mivel minden felhasználói történet általában egy-két napos munkát igényel, nagyon sok ilyen ciklusra lesz szükség történetenként.
- Írjon egységtesztet: A programozók levelet minimális tesztet kell nem azért, mert a funkcionalitás nem hajtották végre maradéktalanul a gyártási kód.
- Nézze meg az új teszt kudarcát: A programozók ellenőrzik, hogy a teszt valóban sikertelen. Bár időpocsékolásnak tűnhet, ez a lépés kritikus fontosságú, mert igazolja, hogy a gyártási kód állapotáról alkotott meggyőződésed helyes. Ha a teszt nem bukik meg, a programozóknak meg kell állapítaniuk, hogy a tesztkódban van-e hiba, vagy a gyártói kód valóban támogatja az új teszt által leírt funkciókat.
- Kód írása: A programozók csak annyi gyártási kódot írnak le, hogy az új teszt sikeres legyen.
- Teszt futtatása: Az egységtesztek végrehajtása annak ellenőrzésére történik, hogy az új gyártási kód megfelel-e az új tesztnek, és más tesztek sem hibáznak-e.
- Refaktor: Távolítson el minden kódszagot mind a gyártási, mind a tesztkódból.
A fenti folyamat intenzívebb változatát lásd Bob bácsi három TDD szabályában.[2]
Egész csapat[szerkesztés]
XP-n belül nem az a "vevő" aki fizeti a számlát, hanem aki tényleg használja a rendszert. Az XP azt mondja, hogy az ügyfélnek mindig kéznél kell lennie, és elérhetőnek kell lennie a kérdések megválaszolására. Például a pénzügyi adminisztrációs rendszert fejlesztő csapatnak tartalmaznia kell egy pénzügyi adminisztrátort.
Folyamatos feldolgozás[szerkesztés]
Folyamatos integráció[szerkesztés]
A fejlesztőcsapatnak mindig a szoftver legújabb verzióján kell dolgoznia. Mivel a különböző csapattagok különböző változtatásokkal és javításokat tartalmazó verziókkal rendelkezhetnek helyben elmentve, meg kell próbálniuk néhány óránként, vagy amikor egy jelentős törés jelentkezik, feltölteni az aktuális verziót a kódtárba. A folyamatos integráció elkerüli a projektciklus későbbi szakaszában az integrációs problémák okozta késéseket.
Tervezési fejlesztés[szerkesztés]
Mivel az XP doktrínája csak azt javasolja, hogy programozzuk azt, amire ma szükség van, és a lehető legegyszerűbb megvalósítást, ez időnként a rendszer elakadását eredményezheti. Ennek egyik tünete a kettős (vagy többszörös) karbantartás szükségessége: a funkcionális változások megkezdik ugyanazon (vagy hasonló) kód több példányának módosítását. Egy másik tünet, hogy a kód egy részének változásai sok más részt is érintenek. Az XP doktrínája azt mondja, hogy amikor ez megtörténik, a rendszer azt kéri, hogy az architektúra megváltoztatásával alakítsa újra a kódot, egyszerűbbé és általánosabbá téve azt.
Kis kiadások[szerkesztés]
A szoftver szállítása a konkrét értéket teremtő, éles funkciók gyakori kiadásán keresztül történik. A kisebb kiadások segítenek az ügyfélnek abban, hogy bizalmat kapjon a projekt előrehaladásával kapcsolatban. Ez segít fenntartani az egész csapat koncepcióját, mivel az ügyfél most már a valós tapasztalatokon alapuló javaslatokat tehet a projektre vonatkozóan.
Közös megértés[szerkesztés]
Kódolási szabvány[szerkesztés]
A kódolási szabvány megegyezett szabályrendszer, amelyet a teljes fejlesztőcsapat betart a projekt során. A szabvány meghatározza a forráskód egységes stílusát és formátumát a választott programozási nyelven belül, valamint különböző programozási konstrukciókat és mintákat, amelyeket a hibák valószínűségének csökkentése érdekében kerülni kell. A kódolási szabvány lehet a nyelv szállítója által meghatározott szabványos konvenciók (pl. a Sun által ajánlott The Code Conventions for the Java Programming Language), vagy a fejlesztőcsapat által meghatározott egyedi konvenciók.
Extreme Programming támogatókat szószólója kódot, amely önmagát dokumentálja, hogy a legtávolabbi mértékben lehetséges. Ez csökkenti a kódhoz fűzött megjegyzések szükségességét, amelyek kieshetnek magával a kóddal.[3]
Kollektív kódtulajdonlás[szerkesztés]
A kollektív kódtulajdonlás (más néven "csapatkód tulajdonjog" és "megosztott kód") azt jelenti, hogy mindenki felelős a kódért; ezért mindenki megváltoztathatja a kód bármely részét. A kollektív kódtulajdonlás nemcsak szervezeti politika, hanem érzés is. "A fejlesztők jobban érzik a csapatkód tulajdonjogát, ha megértik a rendszerkörnyezetet, hozzájárultak a szóban forgó kódhoz, jónak ítélik meg a kód minőségét, hiszik, hogy a termék kielégíti a felhasználói igényeket, és nagyfokú csapatkohéziót észlelnek."[4] A páros programozás, különösen az átfedő párok forgatása hozzájárul ehhez a gyakorlathoz: a különböző párokban végzett munka révén a programozók jobban megértik a rendszer kontextusát, és a kódbázis több területéhez járulnak hozzá.
A közös kódtulajdonlás felgyorsíthatja a fejlesztést, mivel a hibát észlelő fejlesztő azonnal kijavíthatja azt, ami összességében csökkentheti a hibák számát. A programozók azonban olyan kód megváltoztatásakor, amelyet nem értenek jól, hibákat is bevihetnek. A kellően jól definiált egységteszteknek enyhíteniük kell ezt a problémát: ha az előre nem látható függőségek hibákat okoznak, akkor az egységtesztek futtatásakor hibákat fognak mutatni.
A kollektív kódtulajdonlás a tagok jobb biztonsági mentését, a tudás és a tanulás nagyobb elosztását, a kód közös felelősségét, jobb kódminőséget és kevesebb kódjavítást eredményezhet. De ez a tagok gyakoribb konfliktusához, a hibák növekedéséhez, a fejlesztők szellemi teljesítményének megváltozásához, az érvelésük akadályozásához, megnövekedett fejlesztési időhöz vagy a kód nehezebb megértéséhez is vezethet.[5]
Egyszerű kialakítás[szerkesztés]
A programozóknak a "legjobb az egyszerű" megközelítést kell alkalmazniuk a szoftvertervezésben. Amikor egy új kódrészletet írnak, a szerzőnek fel kell tennie magának a kérdést, hogy "van-e egyszerűbb módja ugyanannak a funkciónak a bevezetésére?". Ha a válasz igen, akkor az egyszerűbb megoldást kell választani. Az összetett kód egyszerűbbé tételéhez a refaktorálást is alkalmazni kell.
Rendszermetafora[szerkesztés]
A rendszermetafora egy történet, amelyet minden – vásárló, programozó és menedzser – elmondhat a rendszer működéséről. Ez az osztályok és metódusok elnevezési koncepciója, amely megkönnyíti a csapattagok számára, hogy kitalálják egy adott osztály/metódus funkcionalitását, pusztán a nevéből. Például egy könyvtári rendszer létrehozhat loan_records(class) a borrowers(class), és ha a tétel késedelmessé válna, akkor elvégezhet egy make_overdue műveletet egy catalogue(class)-on . Minden egyes osztály vagy művelet esetében a funkcionalitás nyilvánvaló az egész csapat számára..
Programozói jólét[szerkesztés]
Fenntartható tempó[szerkesztés]
A koncepció az, hogy a programozók vagy szoftverfejlesztők ne dolgozzanak többet heti 40 óránál, és ha egy héten van túlóra, akkor a következő héten ne legyen egyáltalán. Mivel a fejlesztési ciklusok a folyamatos integráció rövid ciklusaiból állnak, és a teljes fejlesztési (kiadási) ciklusok gyakoribbak, az XP-ben lévő projektek nem követik azt a tipikus időt, amelyet más projektek túlórában igényelnek.
Ebbe a koncepcióba az is beletartozik, hogy az emberek akkor teljesítenek a legjobban és legkreatívabban, ha teljesen kipihentek.
A fenntartható munkasebesség elérésének kulcsfontosságú eleme a gyakori kódegyesítés, valamint a folyamatosan végrehajtható, tesztelhető, kiváló minőségű kód. A folyamatosan alakuló munkamódszer friss és éber elméjűvé teszi a csapattagokat. A csapaton belüli intenzív együttműködés arra késztet, hogy a hétvégéken pihenéssel újra feltöltődjünk.
A jól tesztelt, folyamatosan integrált, gyakran telepített kódok és környezetek szintén minimálisra csökkentik a váratlan fejlesztési problémákat és a leállások gyakoriságát, valamint a szükséges munkaidőn túli éjszakába nyúló és hétvégi munkát.
Hivatkozások[szerkesztés]
- ↑ Beck, K. Extreme Programming Explained: Embrace Change 2nd. ed. Addison-Wesley, 2000 pp. 54
- ↑ Martin: Three Rules of TDD
- ↑ Archivált másolat. [2021. december 17-i dátummal az eredetiből archiválva]. (Hozzáférés: 2021. december 17.)
- ↑ Sedano, Todd. Practice and Perception of Team Code Ownership, Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering. ACM, 1–6. o.. DOI: 10.1145/2915970.2916002 (2016). ISBN 9781450336918
- ↑ Ribeiro, Danilo & Silva, Fabio & Valença, Diana & Freitas, Elyda & França, César. (2016). Advantages and Disadvantages of using Shared code from the Developers Perspective: A qualitative study.
Fordítás[szerkesztés]
Ez a szócikk részben vagy egészben az Extreme programming practices című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.