Az Extreme Programming egy szoftverfejlesztési módszer, amelynek célja a szoftver minőségének javítása, valamint az ügyfél vagy az ügyfél változó igényeihez való megfelelő alkalmazkodás képessége. A kilencvenes évek közepén és végén, miközben a Chrysler átfogó kompenzációs rendszerén (C3) dolgozott, hogy segítsen kezelni a vállalat bérszámfejtését, Ken Beck szoftvermérnök először kifejlesztette az extrém programozási módszert., 1999 októberében kiadta az Extreme Programming Explained-et, részletezve a teljes módszert mások számára, nem sokkal később pedig a hivatalos weboldal is elindult.

a többi agilis fejlesztési módszerhez hasonlóan az Extreme Programming célja, hogy iteratív és gyakori kis kiadásokat biztosítson a projekt során, lehetővé téve mind a csapattagok, mind az ügyfelek számára, hogy megvizsgálják és áttekintsék a projekt előrehaladását az SDLC egész területén.,

ebben a cikkben megvizsgáljuk, hogy pontosan mi a szélsőséges programozás és hogyan működik, a mögötte álló értékektől és elvektől kezdve az új extrém programozási projekt megvalósításához használt szabályokig és eljárási legjobb gyakorlatokig, Tehát kezdjük el!,/td>

a Rational Unified Process Big Bang-Modell V-Modell Fogalmi Modell Kaizen Modell Kanban Modell Spirál Modell

Extrém Értékek

ez az öt alapvető értékek biztosítják az alapot, amelyre az teljes egészében a Szélsőséges Programozási paradigma épül, amely lehetővé teszi, hogy az ember részt vesz, a projekt magabiztosnak érzem magam abba az irányba, hogy a projekt tart, meg kell értenie, hogy a személyes visszajelzések, illetve a megfigyelés, mint szükséges, isten hozott, mint bárki más.,

egyszerűség: megteszünk mindent, amire szükség van, de nem többet. Ez maximalizálja az eddig végrehajtott beruházáshoz létrehozott értéket. Apró, egyszerű lépéseket teszünk a célunk elérése érdekében, és a kudarcok enyhítése érdekében, amint azok megtörténnek. Létrehozunk valamit, amire büszkék vagyunk, és hosszú távon fenntartjuk ésszerű költségek mellett.

kommunikáció: mindenki a csapat tagja, naponta szemtől szemben kommunikálunk. Mindent együtt fogunk dolgozni a követelményektől a kódig. Mi lesz a legjobb megoldás a problémára, hogy mi lehet együtt.,

visszajelzés: minden iterációs elkötelezettséget komolyan veszünk a működő szoftver szállításával. Bemutatjuk a szoftver korai, majd gyakran figyelmesen hallgatni, és hogy minden szükséges változtatást. A projektről fogunk beszélni, és ehhez igazítjuk a folyamatunkat, nem fordítva.

tisztelet: mindenki megadja és érzi azt a tiszteletet, amit megérdemel, mint értékes csapattag. Mindenki hozzájárul az értékhez, még akkor is, ha egyszerűen lelkesedés. A fejlesztők tiszteletben tartják az ügyfelek szakértelmét, és fordítva. A vezetés tiszteletben tartja azt a jogunkat, hogy felelősséget vállaljunk és felhatalmazást kapjunk a saját munkánk felett.,

bátorság: elmondjuk az igazságot a haladásról és a becslésekről. Nem dokumentáljuk a kudarc kifogásait, mert azt tervezzük, hogy sikerül. Nem félünk semmitől, mert senki sem dolgozik egyedül. Alkalmazkodni fogunk a változásokhoz, amikor valaha is megtörténnek.

Extreme Rules

eredetileg megjelent Don Wells 1999-ben, a tulajdonos az Extreme Programming honlapján, ez a sor extrém programozási szabályok eredetileg célja, hogy segítsen ellensúlyozni az állítások, hogy az extrém programozás nem támogatja néhány kiemelkedő tudományágak szükséges a modern fejlődés.,

tervezés

• felhasználói történetek vannak írva.
• a Kiadástervezés létrehozza a kiadási ütemtervet.
• Készítsen gyakori kis kiadásokat.
• a projekt iterációkra oszlik.
• az iterációs tervezés minden iterációt elindít.

kezelése

• adjon a csapatnak egy dedikált nyitott munkaterületet.
• állítsa be a fenntartható tempót.
• stand up meeting starts each day.
• a projekt sebességét mérjük.
• mozgassa az embereket.
• Fix Extrém programozás, amikor eltörik.

• egyszerűség.,
• válasszon egy rendszer metaforát.
• használjon CRC kártyákat tervezési munkamenetekhez.
• hozzon létre spike megoldásokat a kockázat csökkentése érdekében.
• nincs funkció hozzá Korán.
• Refactor amikor csak lehetséges.

kódolás

• az ügyfél mindig elérhető.
• kódot kell írni, hogy elfogadott szabványoknak.
• először kódolja az egységtesztet.
• az összes gyártási kód pár programozva van.
• egyszerre csak egy pár integrálja a kódot.
• gyakran integrálódik.
• hozzon létre egy dedikált integrációs számítógépet.
• használja a kollektív tulajdonjogot.,

tesztelés

• minden kódnak egységtesztekkel kell rendelkeznie.
• minden kódnak meg kell felelnie az összes egységtesztnek, mielőtt felszabadulna.
• Ha hibát talál, tesztek jönnek létre.
• az elfogadási teszteket gyakran futtatják, és a pontszámot közzéteszik.

Extreme Practices

az akkoriban a szoftverfejlesztés legjobb gyakorlatának tartott módszerek felhasználásával létrehozott szélsőséges gyakorlatok részletezik azokat a konkrét eljárásokat, amelyeket az extrém programozást alkalmazó projekt végrehajtásakor követni kell.,

Finomléptékű visszacsatolás

pár programozás

lényegében a pár programozás azt jelenti, hogy két ember ugyanabban a rendszerben dolgozik, amikor bármilyen termelési kódot fejleszt. Az Extreme Programming az egész csapatban gyakran forgó partnerekkel elősegíti a jobb kommunikációt és a csapatépítést.

tervezési játék

gyakran ez egy gyakori és jól meghatározott időközönként (egy-két hetente) találkozó formájában történik, ahol a projekt tervezésének többsége megtörténik.,

ezen az eljáráson belül létezik a Kiadástervezési szakasz, ahol meghatározások készülnek a közelgő kiadásokhoz szükséges információkról. A Kiadástervezés szakaszai a következők:

• feltárási szakasz: a Történetkártyákat az ügyfelek legértékesebb követelményeinek részletezésére használják.
• kötelezettségvállalási szakasz: a csapat tervezését és kötelezettségvállalásait a következő ütemezés kiadásának igényeinek kielégítésére és időben történő kiszállítására készítik el.,
• kormányzási szakasz: Ez lehetővé teszi a korábban kidolgozott tervek kiigazítását a projekt változó igényei alapján, hasonlóan sok más agilis modell módszertanhoz.

A kiadás tervezését követően az iterációs tervezési szakasz is, amely ugyanazon három alfázisból áll, de megvalósításuk változataival:

• feltárási szakasz: minden projektkövetelmény le van írva.
• kötelezettségvállalási szakasz: a szükséges feladatok, amelyeket még be kell fejezni a közelgő iterációs kiadás teljesítéséhez, a fejlesztőkhöz vannak rendelve, és megfelelően ütemezve.,
• kormányzási fázis: a fejlesztés megtörténik, és a megvalósítás után az eredményül kapott iterációt összehasonlítjuk a tervezési eljárás kezdetén létrehozott vázolt történetkártyákkal.

Teszt vezérelt fejlesztés

Míg egy teljes cikket írt arról, hogy a teszt-vezérelt fejlesztés, a koncepció meglehetősen jól ismert, a fejlesztők pedig gyakorlatilag azt jelenti, hogy a vizsgálatok keletkezik minden követelmény a projekt, akkor a kód kifejleszteni, amely sikeresen át azokat a teszteket.,

egész csapat

mint sok más SDLC-módszernél és gyakorlatnál, az Extreme Programming elősegíti az ügyfelek és az ügyfelek bevonását az egész folyamat során, visszajelzéseik segítségével, hogy mindig alakítsák a projektet.

folyamatos folyamat

folyamatos integráció

egy másik gyakori gyakorlat a modern fejlesztés, az ötlet mögött folyamatos integráció, hogy az összes kifejlesztett kódot az egész csapat beolvadt egy közös tároló naponta többször., Ez biztosítja, hogy a projekt egészére kiterjedő integrációval kapcsolatos kérdéseket a lehető leghamarabb észrevegyék és kezeljék.

Code refactoring

egy másik nagyon gyakori gyakorlat, a code refactoring mögött álló ötlet egyszerűen a már meglévő kód szerkezetének javítása és újratervezése, alapvető viselkedésének módosítása nélkül. A refaktorálás egyszerű példái közé tartozik a nem megfelelő nevek változóinak vagy módszereinek rögzítése, valamint az ismételt kód csökkentése egyetlen módszerre vagy funkcióra.,

kis kiadások

nagyon összhangban az iteratív modell gyakorlatával, ez a koncepció biztosítja, hogy a projekt gyakori iterált, kis kiadásokkal rendelkezzen, lehetővé téve az ügyfél számára, mint minden csapattag, hogy megértse a projekt fejlődését.

közös megértés

kódolási szabványok

a kódolási szabvány egyszerűen a kódon belüli legjobb gyakorlatok halmaza, mint például a formázás és a stílus, amelyet az egész csapat a projekt életciklusa során betartja., Ez elősegíti a kód jobb megértését és olvashatóságát nemcsak a jelenlegi tagok számára, hanem a jövőbeli fejlesztők számára is.

kollektív kódtulajdon

Ez a gyakorlat lehetővé teszi, hogy a csapat bármely fejlesztője szükség szerint megváltoztassa a kód bármely szakaszát. Bár ez a gyakorlat egyesekre veszélyesnek tűnhet, felgyorsítja a fejlesztési időt, és minden lehetséges problémát meg lehet szüntetni a megfelelő egységvizsgálattal.

egyszerű kialakítás

kevés ok van a dolgok bonyolítására, ha egyszerűbb lehetőség áll rendelkezésre., Ez az alapvető gyakorlat, hogy az összes komponenst és kódot a lehető legegyszerűbben tartsuk, biztosítja, hogy az egész csapat mindig értékelje, hogy a dolgok könnyebben elvégezhetők-e.

rendszer metafora

a kódolási szabványok részeként a rendszer metafora az az elképzelés, hogy a csapat minden tagjának képesnek kell lennie arra, hogy megnézze a kifejlesztett magas szintű kódot, és világosan megértse, hogy a kód milyen funkciókat hajt végre.,

programozó jólét

fenntartható ütemben

a legfontosabb koncepció a jobb munka-élet egyensúly a fejlesztők egy extrém programozási projekt az az elképzelés, hogy senki nem kell dolgozni meghaladja a normál ütemezett Munkahét. A túlóra homlokát ráncolja, csakúgy, mint a “crunch time” fogalma, ahol a fejlesztők várhatóan extrém órákat dolgoznak a kiadás vége felé, hogy mindent időben elkészítsenek.