Mi az extrém programozás?

tervezési játék

az XP tervezés a szoftverfejlesztés két kulcsfontosságú kérdésével foglalkozik: megjósolja, hogy mi lesz az esedékesség napján, és meghatározza, hogy mi a következő lépés. A hangsúly a projekt irányításán van – ami meglehetősen egyszerű -, nem pedig a pontos előrejelzésen, hogy mire lesz szükség, és mennyi ideig tart – ami meglehetősen nehéz., Az XP-ben két fő tervezési lépés van, ezek a két kérdés megválaszolása:

A Kiadástervezés olyan gyakorlat, ahol az ügyfél bemutatja a programozók számára a kívánt funkciókat, a programozók pedig becsülik nehézségeiket. A költségbecslésekkel együtt, valamint a funkciók fontosságának ismeretében az ügyfél tervet készít a projektre. A kezdeti kiadási tervek szükségszerűen pontatlanok: sem a prioritások, sem a becslések nem igazán szilárdak, és amíg a csapat nem kezd dolgozni, nem fogjuk tudni, hogy milyen gyorsan fognak menni., Még az első kiadási terv is elég pontos a döntéshozatalhoz, azonban az XP csapatok rendszeresen felülvizsgálják a kiadási tervet.

az iterációs tervezés az a gyakorlat, amelynek során a csapatot néhány hetente irányítják. XP csapatok építeni szoftver kéthetes “iterációk”, nyilvánított futó hasznos szoftver végén minden iteráció. Az iterációs tervezés során az ügyfél bemutatja a következő két hétben kívánt funkciókat. A programozók feladatokra bontják őket ,és becsülik a költségeiket (finomabb részletességgel, mint a kiadás tervezésekor)., Az előző iterációban elvégzett munka mennyisége alapján a csapat feliratkozik arra, amit a jelenlegi iterációban végeznek.

ezek a tervezési lépések nagyon egyszerűek, mégis nagyon jó információkat és kiváló kormányzási irányítást nyújtanak az ügyfél kezében. Néhány hetente a haladás mennyisége teljesen látható. Az XP-ben nincs” kilencven százalék”: egy szolgáltatás története befejeződött, vagy nem volt., Ez a láthatóságra való összpontosítás szép kis paradoxont eredményez: egyrészt, oly sok láthatósággal, az ügyfél abban a helyzetben van, hogy visszavonja a projektet, ha a haladás nem elegendő. Másrészt az előrehaladás annyira látható, és az a képesség, hogy eldöntsük, mi lesz a következő lépés, annyira teljes, hogy az XP projektek általában többet nyújtanak a szükségből, kevesebb nyomással és stresszel.

Ügyféltesztek

az egyes kívánt funkciók bemutatásának részeként az XP ügyfél egy vagy több automatizált elfogadási tesztet határoz meg annak igazolására, hogy a szolgáltatás működik., A csapat ezeket a teszteket arra használja, hogy bebizonyítsa magának, valamint az ügyfélnek, hogy a szolgáltatás helyesen van megvalósítva. Az automatizálás azért fontos, mert az időnyomásban a kézi tesztek kimaradnak. Ez olyan, mint kikapcsolni a lámpákat, amikor az éjszaka legsötétebb lesz.

a legjobb XP csapatok ugyanúgy kezelik az ügyfélteszteket, mint a programozó teszteket: miután a teszt fut, a csapat ezt követően megfelelően fut. Ez azt jelenti, hogy a rendszer csak javul, mindig előre halad, soha nem csúszik vissza.,

kis kiadások

az XP csapatok két fontos módon gyakorolják a kis kiadásokat:

először a csapat kiadja a futó, tesztelt szoftvert, az ügyfél által választott üzleti értéket, minden iterációt. Az Ügyfél bármilyen célra felhasználhatja ezt a szoftvert, legyen az értékelés, vagy akár kiadás a végfelhasználóknak (erősen ajánlott). A legfontosabb szempont az, hogy a szoftver minden iteráció végén látható, illetve adott legyen az ügyfélnek. Ez mindent nyitott és kézzelfogható.

második, XP csapatok engedje, hogy a végfelhasználók gyakran is., XP webes projektek kiadás olyan gyakran, mint a napi, a ház projektek havi vagy gyakrabban. Még a zsugorfóliás termékeket is olyan gyakran szállítják, mint negyedévente.

lehet, hogy lehetetlen ilyen gyakran jó verziókat létrehozni, de az XP csapatok egész idő alatt ezt csinálják. Lásd a folyamatos integrációt további információkért, és vegye figyelembe, hogy ezeket a gyakori kiadásokat az XP tesztelési megszállottsága tartja megbízhatónak, amint azt az Ügyféltesztekben és Tesztvezérelt fejlesztésekben leírtuk.

egyszerű kialakítás

XP csapatok szoftvereket készítenek egy egyszerű, de mindig megfelelő kialakításra., Egyszerűnek indulnak, és a programozó tesztelésén és a tervezés fejlesztésén keresztül így is tartják. Egy XP csapat tartja a design pontosan alkalmas a jelenlegi működését a rendszer. Nincs kárba veszett mozgás, a szoftver mindig készen áll arra, ami a következő.

Az XP-ben a tervezés nem egyszeri dolog, vagy egy up-front dolog, hanem minden idők. Vannak tervezési lépések a kiadástervezésben és az iterációtervezésben, valamint a csapatok gyors tervezési munkamenetekkel és tervezési felülvizsgálatokkal foglalkoznak a refactoring révén, a teljes projekt folyamán., Egy inkrementális, iteratív folyamat, mint a szélsőséges programozás, jó tervezés elengedhetetlen. Ezért van olyan nagy hangsúly a tervezésre az egész fejlesztés során.

pár programozás

az XP összes termelési szoftverét két programozó építette, egymás mellett ülve, ugyanazon a gépen. Ez a gyakorlat biztosítja, hogy az összes gyártási kódot legalább egy másik programozó felülvizsgálja, és jobb tervezést, jobb tesztelést és jobb kódot eredményez.

nem tűnik hatékonynak, ha két programozó “egy programozó munkáját” végzi, de a fordított igaz., A páros programozás kutatása azt mutatja, hogy a párosítás jobb kódot eredményez körülbelül ugyanabban az időben, mint az egyedül dolgozó programozók. Így van: két fej tényleg jobb, mint egy!

egyes programozók kifogásolják a programozás párosítását anélkül, hogy valaha is megpróbálnák. Némi gyakorlásra van szükség ahhoz, hogy jól működjön, és néhány hétig jól kell csinálnia, hogy megnézze az eredményeket. Kilencven százaléka programozók, akik megtanulják pár programozás inkább azt, ezért nagyon ajánlom, hogy minden csapat.

párosítás, amellett, hogy jobb kód és tesztek, is arra szolgál, hogy kommunikálni tudás az egész csapat., Ahogy a párok váltanak, mindenki megkapja mindenki speciális tudásának előnyeit. A programozók tanulnak, készségeik javulnak, értékesebbé válnak a csapat és a vállalat számára. A párosítás, még az XP-n kívül is, mindenki számára nagy győzelem.

Tesztvezérelt fejlesztés

az extrém programozás megszállottja a visszajelzéseknek, a szoftverfejlesztésben pedig a jó visszajelzés jó tesztelést igényel. A top XP csapatok gyakorolják a “tesztvezérelt fejlesztést”, nagyon rövid ciklusokban dolgoznak egy teszt hozzáadásával, majd működőképessé teszik., Szinte könnyedén a csapatok közel 100 százalékos tesztfedezetű kódot állítanak elő, ami nagy előrelépés a legtöbb üzletben. (Ha a programozók már csinál még kifinomultabb tesztelés, több energiát az Ön számára. Csak így tovább, csak segíteni tud!)

nem elég teszteket írni: futtatnia kell őket. Itt is az extrém programozás extrém. Ezek a ” programozó tesztek “vagy” egységtesztek ” mind össze vannak gyűjtve, és minden alkalommal, amikor bármely programozó kiadja a kódot a tárolóba (és a párok általában naponta kétszer vagy többet bocsátanak ki), minden egyes programozó tesztnek megfelelően kell működnie., Száz százalékig, mindig! Ez azt jelenti, hogy a programozók azonnali visszajelzést kapnak arról, hogy mit csinálnak. Ezenkívül ezek a tesztek felbecsülhetetlen támogatást nyújtanak, mivel a szoftvertervezés javul.

Design Improvement (Refactoring)

Extreme Programming összpontosít nyilvánított üzleti értéket minden iteráció. Ennek megvalósításához az egész projekt során a szoftvernek jól megtervezettnek kell lennie. Az alternatíva az lenne, hogy lelassul, és végül elakad., Tehát az XP a folyamatos tervezési fejlesztés folyamatát használja, amelyet Refactoringnak neveznek, Martin Fowler könyvének címéből, “Refactoring: a meglévő kód tervezésének javítása”.

a refaktorálási folyamat a duplikáció eltávolítására (a rossz tervezés biztos jele), valamint a kód “kohéziójának” növelésére összpontosít, miközben csökkenti a “kapcsolást”. A magas kohéziót és az alacsony összekapcsolódást legalább harminc éve ismerik el a jól megtervezett kód fémjelzéseként. Az eredmény az, hogy az XP csapatok jó, egyszerű tervezéssel indulnak, és mindig jó, egyszerű kialakítással rendelkeznek a szoftver számára., Ez lehetővé teszi számukra, hogy fenntartsák a fejlesztési sebesség, sőt általában növeli a sebességet, mint a projekt halad előre.

a Refactoringot természetesen erősen támogatja az átfogó tesztelés, hogy megbizonyosodjon arról,hogy a tervezés fejlődésével semmi sem törött. Így az ügyféltesztek és a programozó tesztek kritikus tényező. Az XP gyakorlatok támogatják egymást: együtt erősebbek, mint külön-külön.

folyamatos integráció

az extrém programozási csapatok mindig teljes mértékben integrálják a rendszert. Azt mondjuk, hogy a napi építések wimps: XP csapatok építeni naponta többször., (Egy XP csapat negyven ember épít legalább nyolc vagy tíz alkalommal naponta!)

az előnye ennek A gyakorlatnak az visszagondolva a projektek hallottad, mi történt (vagy egy része), ahol a build folyamat volt hetente, vagy ritkábban, általában vezetett, hogy az “integráció pokol”, ahol minden összetört, de senki sem tudta, hogy miért.

a ritka integráció súlyos problémákat okoz egy szoftverprojektben., Először is, bár az integráció kritikus fontosságú a jó munka kódjának szállításához, a csapatot nem gyakorolják rajta, gyakran olyan emberekre ruházzák át, akik nem ismerik az egész rendszert. Másodszor, ritkán integrált kód gyakran-azt mondanám, általában-hibás kód. Az integrációs időben olyan problémák merülnek fel, amelyeket a nem integrált rendszeren végzett tesztelés nem észlel. Harmadszor, gyenge integrációs folyamat vezet hosszú kód lefagy., Kód lefagy azt jelenti, hogy hosszú ideig, amikor a programozók is dolgozik fontos feladható funkciók, de ezeket a funkciókat vissza kell tartani. Ez gyengíti pozícióját a piacon, vagy a végfelhasználókkal.

kollektív Kódtulajdonság

egy extrém programozási projekten a programozók bármelyik párja bármikor javíthatja a kódot. Ez azt jelenti, hogy minden kód sok ember figyelmének hasznára válik, ami növeli a kód minőségét és csökkenti a hibákat., Van egy másik fontos előny is: amikor a kód magánszemélyek tulajdonában van, a szükséges funkciókat gyakran rossz helyre helyezik, mivel az egyik programozó felfedezi, hogy szüksége van egy olyan funkcióra, amely valahol kódban van, amelyet nem birtokol. A tulajdonos túl elfoglalt ahhoz, hogy ezt megtegye, így a programozó a saját kódjába helyezi a funkciót, ahol nem tartozik. Ez csúnya, nehezen karbantartható kódhoz vezet, tele duplikációval és alacsony (rossz) kohézióval.

a kollektív tulajdonjog problémát jelenthet, ha az emberek vakon dolgoztak a kódon, amit nem értettek., Az XP két kulcsfontosságú technikával kerüli el ezeket a problémákat: a programozó tesztek hibákat fognak el, a pár programozás pedig azt jelenti, hogy az ismeretlen kódon való munka legjobb módja a szakértővel való párosítás. Amellett, hogy szükség esetén megfelelő módosításokat biztosít, ez a gyakorlat a tudást az egész csapatban terjeszti.

kódolási szabvány

az XP csapatok egy közös kódolási szabványt követnek, így a rendszer összes kódja úgy néz ki, mintha egy – nagyon kompetens – egyén írta volna., A szabvány sajátosságai nem fontosak: fontos, hogy az összes kód ismerősnek tűnik, a kollektív tulajdon támogatása érdekében.

metafora

az extrém programozási csapatok közös képet alkotnak a program működéséről, amelyet “metaforának”nevezünk. Legjobb esetben a metafora egy egyszerű felidéző leírás arról, hogyan működik a program, mint például “ez a program úgy működik, mint egy méhkas, megy ki a pollen és hozza vissza a kaptárba”, mint egy ügynök-alapú információ-visszakeresési rendszer leírása.

néha elég költői metafora nem merül fel., Mindenesetre, vagy anélkül, élénk fantázia, XP csapatok közös rendszer a nevek, hogy biztos, hogy mindenki érti, hogyan működik a rendszer, hol kell keresned a funkciót keres, vagy megtalálni a megfelelő helyet a funkciót hozzátesz.

fenntartható tempó

Extrém programozó csapatok vannak benne hosszú távon. Keményen dolgoznak, olyan ütemben, amely határozatlan ideig tartható. Ez azt jelenti, hogy túlóráznak, ha az hatékony, és általában úgy dolgoznak, hogy maximalizálják a termelékenységet hétről hétre., Manapság elég jól érthető, hogy a death march projektek nem produktívak, sem minőségi szoftvereket nem gyártanak. Az XP csapatok benne vannak, hogy nyerjenek, ne haljanak meg.

következtetés

az extrém programozás az egyszerűség, a kommunikáció, a visszajelzés és a bátorság értékein alapuló szoftverfejlesztés tudományága. Úgy működik, hogy az egész csapatot egyszerű gyakorlatok jelenlétében hozza össze, elegendő visszajelzéssel ahhoz, hogy a csapat láthassa, hol vannak, és a gyakorlatokat az egyedi helyzetükhöz igazítsa.