bélyegkép|Tervezési és visszacsatolási ciklus az extrém programozásban Az extrém programozás (XP) egy szoftverfejlesztési módszertan, amelynek célja a szoftver minőségének fejlesztése és a változó vevői igényekhez való reagálás javítása. Az agilis szoftverfejlesztés egyik típusaként"Human Centred Technology Workshop 2006 ", 2006, PDF, Human Centred Technology Workshop 2006UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003 .USFCA-edu-601-lecture Extreme Programming. rövid fejlesztési ciklusokban támogatja a gyakori "kiadásokat", amelyek célja a termelékenység javítása és az ellenőrző pontok bevezetése, ahol új ügyféligényeket lehet elfogadni.

Az extrém programozás további elemei: páros programozás vagy széles körű kódáttekintés, az összes kódegység tesztelése, a szolgáltatások programozásának elkerülése, amíg azok valóban nem szükségesek, lapos menedzsment szerkezet, kódegyszerűség és érthetőség, az ügyfél igényeinek időbeli változására számító, a probléma jobb megértése, valamint a vevő és a programozók közötti gyakori kommunikáció. A módszertan neve onnan jött, hogy a hagyományos szoftverfejlesztési gyakorlatok jótékony elemeit "extrém" szintre kell vinni. Például a kódáttekintést előnyös gyakorlatnak tekintik. Ezt extrém szinten véve a kód folyamatosan áttekinthető, azaz ez a páros programozás gyakorlata.

Története Kent Beck fejlesztette ki az extrém programozást a Chrysler átfogó kompenzációs rendszer (C3) bérszámfejtési projektje során. Beck 1996 márciusában vált a C3 projektvezetőjévé. Elkezdte finomítani a projektben alkalmazott fejlesztési módszertant, és könyvet írt a módszertanról (Extreme Programming Explained, megjelent 1999. október).Computerworld-appdev-92 "Extreme Programming", Computerworld (online), December 2001. A Chrysler 2000 februárjában, hét év után, amikor a Daimler-Benz megvásárolta a társaságot, visszavonta a C3 projektet.

Sok extrém programozási gyakorlat létezik egy ideje; a módszertan a jól bevált gyakorlatokat extrém szintre emeli. Például az „először teszt fejlesztésben, a tesztek megtervezése és megírása megelőz minden egyes programsor hozzáadást” gyakorlatot már a NASA „Mercury-programján, az 1960-as évek elején alkalmazták. A teljes fejlesztési idő lerövidítése érdekében néhány hivatalos tesztdokumentumot (például elfogadási teszteléshez) fejlesztettek ki a tesztelésre kész szoftverrel párhuzamosan (vagy röviddel azelőtt). A NASA független tesztcsoportja formai követelmények és logikai korlátok alapján írhatja ki a tesztelési eljárásokat, mielőtt a programozók megírják a szoftvert és integrálnák azt a hardverrel. Az XP ezt a koncepciót extrém szintre állítja, automatizált teszteket (néha a szoftvermodulokon belül) írva, amelyek még a szoftverkódolás inkább kisebb részeinek működését is validálják, mint a nagyobb szolgáltatások tesztelését.

Eredet Két nagyobb hatás befolyásolta a szoftverfejlesztést az 1990-es években:

Belsőleg, az objektumorientált programozás felváltotta a procedurális programozást, a néhány fejlesztő által kedvelt programozási paradigmát. Külsőleg az internet és a dot-com fellendülése hangsúlyozta a piacra lépést és a vállalati növekedést, mint versenyképes üzleti tényezőket.

A gyorsan változó követelmények rövidebb termékéletciklusokat igényeltek, és gyakran ütköztek a szoftverfejlesztés hagyományos módszereivel.

A Chrysler átfogó kompenzációs rendszer (C3) azzal indult, hogy meghatározzák az objektumtechnológiák felhasználásának legjobb módját. A kutatás tárgyaként a Chrysler bérszámfejtési rendszereit használva, a Smalltalk nyelvvel, az adat-hozzáférési réteg pedig a GemStone volt. Chrysler behozta Kent Becket aki egy kiemelkedő Smalltalk-gyakorló volt, hogy végezzen teljesítményhangolást a rendszeren, de szerepe kibővült, mivel a fejlesztési folyamat számos problémájára rámutatott. Megragadta a lehetőséget, hogy javasoljon és végrehajtson néhány változtatást a fejlesztési gyakorlatban - gyakori munkatársával, Ward Cunninghammel végzett munkája alapján, Beck leírja a módszerek korai koncepcióját:

Beck meghívta Ron Jeffriest a projektbe, hogy segítsen fejleszteni és finomítani ezeket a módszereket. Jeffries ezt követően edzőként járt el, hogy a C3 csapatba belenevelje a gyakorlatokat.

Az XP mögött meghúzódó alapelvekkel és gyakorlatokkal kapcsolatos információkat az eredeti wikiről, Cunningham WikiWikiWebjéről folytatott megbeszélések útján terjesztették a szélesebb világban. Különböző közreműködők megvitatták és kibővítették az ötleteket, ami néhány spin-off módszertan eredményezett (lásd agilis szoftverfejlesztés). Az XP fogalmakat évekig magyarázták egy hipertext rendszertérkép segítségével, az XP webhelyénhttp://www.extremeprogramming.org 1999 körül.

Beck egy könyvsorozatot készített az XP-ről, kezdve saját Extreme Programming Explaineddel (1999, ), ötleteit sokkal nagyobb közönségnek terjesztve. A sorozat szerzői különféle szempontokat tekintettek át, amikor megvizsgálták az XP-t és gyakorlatait. A sorozat egy olyan könyvet tartalmazott, amely kritikus volt a gyakorlatokkal szemben.

Jelenlegi helyzet Az XP az 1990-es évek végén és a 2000-es évek elején jelentős érdeklődést váltott ki a szoftverközösségek körében, mivel az elfogadását számos, az eredetétől radikálisan eltérő környezetben jelent meg.

Az eredeti gyakorlatok által megkövetelt magas fegyelem gyakran az út mentén haladt, és e gyakorlatok némelyikét, például a túl merevnek ítélt gyakorlatokat, az egyes helyszíneken elavulttá nyilvánították, gyengítették, vagy akár befejezetlenül hagyták. Például egy adott projekt nap végi integrációs tesztet, hét végi ütemtervre lehet változtatni, vagy egyszerűen egy közösen elfogadott időpontban történő tesztelésre lehet redukálni. Egy ilyen nyugodtabb ütemtervvel az emberek kevésbé érzik, hogy mesterséges tüskéket készítenek, csak azért, hogy a nap végi teszteket teljesíthessék. Egy kevésbé szigorú ütemterv lehetővé teszi komplex funkciók fejlesztését egy néhány napos periódus alatt.

Eközben más agilis fejlesztési gyakorlatok nem álltak meg, és 2019-re az XP tovább fejlődik, és a gyakorlati tapasztalatokból további tanulságok elsajátítását más gyakorlatok felhasználásával valósítja meg. Az Extreme Programming Explained második kiadásában (2004. november), öt évvel az első kiadás után, Beck további értékeket és gyakorlatokat adott hozzá, és megkülönböztette az elsődleges és a következményes gyakorlatokat.

A fenntartható szoftverfejlesztés elmélete megmagyarázza, hogy miért sikeresek az extrém programozási csapatok, a csapatok szétszakítása ellenére is.

Koncepció

Célok Az Extreme Programming Explained az extrém programozást olyan szoftverfejlesztési tudományágként írja le, amely arra szervezi az embereket, hogy termelékenyebben készítsenek magasabb színvonalú szoftvereket.

Az XP megkísérli csökkenteni a követelmények változásainak költségeit, mivel nem egy hosszú, hanem több rövid fejlesztési ciklust használ. Ebben a doktrínában a változások a szoftverfejlesztési projektek természetes, elkerülhetetlen és kívánatos szempontjai, és ezeket a stabil követelmények meghatározásának megkísérlése helyett meg kell tervezni.

Az extrém programozás számos alapvető értéket, alapelvet és gyakorlatot vezet be az agilis programozási keret mellett.

Tevékenységek Az XP négy alapvető tevékenységet ír le, amelyeket a szoftverfejlesztési folyamat során hajtanak végre: kódolás, tesztelés, meghallgatás és tervezés. E tevékenységek mindegyikét alább ismertetjük.

Kódolás Az XP támogatói úgy érvelnek, hogy a rendszerfejlesztési folyamat egyetlen igazán fontos terméke a kód - szoftver utasítások, amelyeket a számítógép értelmezhet. Kód nélkül nincs működő termék.

A kódolás felhasználható a legmegfelelőbb megoldás kitalálására. A kódolás segíthet a programozási problémákkal kapcsolatos gondolatok közlésében. Ha egy programozó összetett programozási problémával foglalkozik, vagy nehezen tudja megmagyarázni a megoldást a programozó társak számára, akkor egyszerűsített módon kódolhatja, és a kód segítségével mutathatja meg, hogy mit gondol. A kód, ezen álláspontjának támogatói szerint, mindig világos és tömör, és egynél több módon nem értelmezhető. Más programozók visszajelzést adhatnak erről a kódról, gondolataik kódolásával is.

Tesztelés A tesztelés az extrém programozás központi eleme. Az extrém programozás megközelítése az, hogy ha egy kis tesztelés kiküszöböl néhány hibát, akkor sok tesztelés kiküszöböl még több más hibát.

Az egységtesztek meghatározzák, hogy egy adott szolgáltatás a kívánt módon működik-e. A programozók annyi automatizált tesztet írnak, amennyiről csak azt gondolják,hogy "megtörheti" a kódot. Ha az összes teszt sikeresen lefut, akkor a kódolás befejeződött. Minden megírt kóddarabot tesztelünk, mielőtt továbbmegyünk a következő funkcióra. Az elfogadási tesztek igazolják, hogy a programozók által megértett követelmények megfelelnek-e az ügyfél tényleges követelményeinek.

A rendszerszintű integrációs tesztelést először arra ösztönözték, mint egy nap végi tevékenységet az összeférhetetlen interfészek korai felismerésére, az újracsatlakozásra, mielőtt az egyes szakaszok nagymértékben eltérnek a koherens funkcionalitástól. A rendszerszintű integrációs tesztelést azonban lecsökkentették heti vagy még ritkább végrehajtásra, a rendszer összeköttetéseinek stabilitásától függően.

Meghallgatás A programozóknak meg kell hallgatniuk, hogy mi szükséges az ügyfeleknek a rendszerhez, milyen üzleti logikára van szükség. Meg kell értenie ezeket a szükségleteket ahhoz, hogy visszajelzést adjon az ügyfeleknek a probléma megoldásának vagy meg nem oldásának technikai szempontjairól. Az ügyfél és a programozó közötti kommunikációt a tervezési játékban tovább tárgyalják.

Tervezés Az egyszerűség szempontjából természetesen azt lehet mondani, hogy a rendszerfejlesztéshez nem kell több, mint a kódolás, tesztelés és figyelés. Ha ezeket a tevékenységeket jól hajtják végre, akkor az eredménynek mindig egy működő rendszernek kell lennie. A gyakorlatban ez nem fog működni. Tervezés nélkül is hosszú utat lehet elérni, de egy adott időpontban elakadhat. A rendszer túlságosan összetetté válik, és a rendszeren belüli függőségek már nem egyértelműek. Ezt el lehet kerülni, ha olyan tervezési struktúrát hoz létre, amely a rendszer logikáját szervezi. A jó tervezés elkerüli a rendszeren belüli sok függőséget; ez azt jelenti, hogy a rendszer egyik részének megváltoztatása nem érinti a rendszer többi részét.

Értékek Az extrém programozás kezdetben négy értéket ismert el 1999-ben: kommunikáció, egyszerűség, visszajelzés és bátorság. Új értéket, a tiszteletet adta az Extreme Programming Explained második kiadása. Ezt az öt értéket az alábbiakban ismertetjük.

Kommunikáció A szoftver rendszerek felépítéséhez le kell kommunikálni a rendszerkövetelményeket a rendszer fejlesztőivel. A formális szoftverfejlesztési módszertanban ezt a feladatot dokumentációval hajtják végre. Az extrém programozási technikák olyan módszereknek tekinthetők, amelyek segítségével gyorsan fejleszthetők és terjeszthetők az intézményi ismeretek egy fejlesztői csapat tagjai között. A cél az, hogy minden fejlesztő láthassa a rendszert, amely megegyezik a rendszer felhasználóinak nézetével. Ennek érdekében az extrém programozás az egyszerű tervezést, a közös metaforákat, a felhasználók és a programozók együttműködését, a gyakori verbális kommunikációt és a visszajelzést támogatja.

Egyszerűség