Kent Beck: Extrém programozás.

Otthon Ez egy könyv az extrém programozásról. Az extrém programozás, amelyet gyakran "XP"-nek is neveznek, egy egyszerűsített gyártási módszer kis és közepes méretű fejlesztőcsapatok számára. szoftver termék

tisztázatlan vagy gyorsan változó követelményekkel szemben. Ennek a könyvnek az a célja, hogy segítsen eldönteni, hogy az XP megfelelő-e az Ön helyzetéhez...

Az XP sorozatról Az extrém programozás, amelyet gyakran XP-nek is neveznek, egy fejlesztési tudományág szoftver

valamint szoftvertermékek készítése terén folytatott üzleti tevékenység, amely mindkét fél (programozók és üzletemberek) erőfeszítéseit közös, teljesen elérhető célokra összpontosítja. Az XP-t használó csapatok nagyon gyors ütemben készítenek minőségi szoftvereket. A könyvben ismertetett HR tudományágat magában foglaló technikákat azért választottuk, mert az emberi kreativitáson és annak elfogadásán alapulnak, hogy az emberek ingatag és esendő lények.

Az XP-t gyakran technikák halmazaként mutatják be, de maga az XP nem a célvonal. Nem kell egyre jobban gyakorolnod és fejlesztened a HR-t ahhoz, hogy a folyamat végén megszerezd a régóta várt aranycsillagot. Éppen ellenkezőleg, az XP a kiindulási vonal. Az XP felteszi a kérdést: „Mennyire lehet minimális erőfeszítésünk, hogy továbbra is minőségi szoftvereket tudjunk gyártani?”

Azt mondtam, hogy "a válasz kezdete", mert a folytatás nem igazán létezik. Az XP létrehozói és megvalósítói ennek a problémának a megoldásán is gondolkodtak. Miután megpróbálták használni az XP-t, átlépték a küszöböt és beléptek az ismeretlenbe. Amikor visszatértek, elmondták a történetüket. Az általuk megfogalmazott gondolatok az út mentén elhelyezett táblák: „Itt élnek a sárkányok”, „15 km után nyílik szép kilátás", "Ez a terület veszélyes, ha esik."

Sajnálom, de ideje programozni.

Előszó

Extrém programozás (

extrém programozás

XP) a kódolást kulcsfontosságú és alapvető tevékenységként határozza meg egy szoftverprojekten végzett munka során. Ez tévedés lehet!

Szerintem érdemes elgondolkodni a saját szoftverfejlesztési tapasztalataimon. Olyan környezetben dolgozom, ahol a fejlesztés alatt álló termék folyamatosan működőképes állapotban van, ugyanakkor folyamatosan változtatnak rajta. A következő működő verzió megjelenésének határideje borzasztóan le van sűrítve, ugyanakkor mindezek felett óriási technikai kockázat lóg. Ilyen környezetben a kollégája kijavításának képessége olyan művészet, amely nélkül nem élhet túl. Az információcsere egy csapaton belül és több, gyakran földrajzilag elkülönült csapat között is kód segítségével történik. Elolvastuk a kódot, hogy megértsük az új vagy módosított dizájnt szoftveres interfészek rendszerek. Az összetett objektumok életciklusát és viselkedését tesztesetek, azaz ismét kód segítségével határozzuk meg. A hibajelentéseket tesztesetek kísérik, amelyek bemutatják a problémát, ismét kódot használva. Végezetül pedig folyamatosan azon dolgozunk, hogy javítsuk a meglévő kódot, hogy hatékonyabbá, rugalmasabbá és érthetőbbé tegyük azt. Nyilvánvalóan ilyen környezetben a szoftverfejlesztés szinte teljes egészében kódolásra épül, ugyanakkor képesek vagyunk a projekteket időben sikeresen befejezni, így ez a megközelítés eléggé életképes.

Ne feltételezze, hogy egy szoftverprojekt sikeres megvalósításához csupán meggondolatlan, heves programozásra van szüksége. Szoftverfejlesztés nagyon nehéz, jó minőségű szoftver fejlesztése és a munka időben történő elvégzése pedig még nehezebb. Ahhoz, hogy az általam leírt megközelítés működjön, fontos további szabályokat és technikákat kell következetesen alkalmazni. Kent Beck ezzel kezdi elgondolkodtató könyvét a HR-ről.

Kent azon Tektronix vezetői közé tartozott, akik felismerték a csatolt programozási technikákban rejlő óriási lehetőségeket a Smalltalk környezetben való komplex mérnöki alkalmazások fejlesztésében. Ward Cunninghammel együtt Kent inspirálta a mintaprogramozás (más néven mintaprogramozás) fejlesztését.

Együttműködtem Kenttel, és az XP-ben leírt epizódokat használtam, miközben egy kicsi, de jól ismert JUnit nevű projekten dolgoztam.

Bevezetés

Ez a könyv az extrém programozásról szól (

extrém programozás

XP). Az Extreme Programming egy egyszerűsített gyártási módszertan kis- és közepes méretű szakértői csapatok számára, akik szoftverterméket fejlesztenek tisztázatlan vagy gyorsan változó követelmények mellett. Ennek a könyvnek az a célja, hogy segítsen eldönteni, hogy az XP megfelelő-e az Ön helyzetében.

A HR sokak számára a józan ész szempontjából teljesen elfogadható és indokolt munkaszervezési módszerek halmazának tűnik. Akkor miért nevezik extrémnek az XP módszerekkel összhangban történő programozást? A lényeg az, hogy az XP számos általános és széles körben használt programozási elvet extrém szintre emel.

Ha a kód áttekintése jó, akkor folyamatosan ellenőrizzük a kódot (páros programozás);

Ha a tesztelés jó, akkor minden projekt résztvevő folyamatosan teszteli a programkódot (egységteszt), még az ügyfelek is (funkcionális tesztelés);

Ha a tervezés jó, akkor meg kell tervezni szerves része a projekt minden résztvevőjének napi munkája (kód átdolgozása);

Műfaj: ,

Szerzői jog birtokosai!

A mű bemutatott részlete a legális tartalom forgalmazójával, a liters LLC-vel egyetértésben kerül feladásra (az eredeti szöveg legfeljebb 20%-a). Ha úgy gondolja, hogy az anyagok közzététele sérti valaki más jogait, akkor.

Olvasók!

Fizetett, de nem tudja, mit tegyen?

Figyelem! Ön a törvény és a szerzői jog tulajdonosa által engedélyezett kivonatot tölt le (legfeljebb a szöveg 20%-át).
Az áttekintés után felkérjük, hogy lépjen a szerzői jog tulajdonosának webhelyére, és vásároljon teljes verzió művek.

• SharerSharpened:
• 16-12-2018, 02:17

⬇ Egyéb megjegyzések

Extrém programozás

Édesapámnak szenteltem, és köszönöm Cindee Andresnak, a feleségemnek és a páromnak, hogy megkövetelte tőlem, hogy figyelmen kívül hagyjam és írjak. Köszönöm Bethanynek, Lincolnnak, Forrestnek, hogy nem szakítottak félbe, és hagytak írni.

tisztázatlan vagy gyorsan változó követelményekkel szemben. Ennek a könyvnek az a célja, hogy segítsen eldönteni, hogy az XP megfelelő-e az Ön helyzetéhez...

Az Extreme Programming, gyakran rövidítve XP, a szoftverfejlesztés és szoftverüzletág olyan tudományága, amely mindkét fél (programozók és üzletemberek) erőfeszítéseit közös, elérhető célokra összpontosítja. Az XP-t használó csapatok nagyon gyors ütemben készítenek minőségi szoftvereket. A könyvben ismertetett HR tudományágat magában foglaló technikákat azért választottuk, mert az emberi kreativitáson és annak elfogadásán alapulnak, hogy az emberek ingatag és esendő lények.

valamint szoftvertermékek készítése terén folytatott üzleti tevékenység, amely mindkét fél (programozók és üzletemberek) erőfeszítéseit közös, teljesen elérhető célokra összpontosítja. Az XP-t használó csapatok nagyon gyors ütemben készítenek minőségi szoftvereket. A könyvben ismertetett HR tudományágat magában foglaló technikákat azért választottuk, mert az emberi kreativitáson és annak elfogadásán alapulnak, hogy az emberek ingatag és esendő lények.

Az XP-t gyakran technikák halmazaként mutatják be, de maga az XP nem a célvonal. Nem kell egyre jobban gyakorolnod és fejlesztened a HR-t ahhoz, hogy a folyamat végén megszerezd a régóta várt aranycsillagot. Éppen ellenkezőleg, az XP a kiindulási vonal. Az XP felteszi a kérdést: „Mennyire lehet minimális erőfeszítésünk, hogy továbbra is minőségi szoftvereket tudjunk gyártani?”

Azt mondtam, hogy "a válasz kezdete", mert a folytatás nem igazán létezik. Az XP létrehozói és megvalósítói ennek a problémának a megoldásán is gondolkodtak. Miután megpróbálták használni az XP-t, átlépték a küszöböt és beléptek az ismeretlenbe. Amikor visszatértek, elmondták a történetüket. A gondolataik az út mentén elhelyezett táblák: „Itt sárkányok élnek”, „15 km után már jó a kilátás”, „Esőben veszélyes ez a szakasz.”

Sajnálom, de ideje programozni.

Kent Beck, sorozat tanácsadó

Előszó

Extrém programozás ( extrém programozás,XP) a kódolást kulcsként és alapvető tevékenységként azonosítja, amikor egy szoftverprojekten dolgozik. Ez tévedés lehet!

Szerintem érdemes elgondolkodni a saját szoftverfejlesztési tapasztalataimon. Olyan környezetben dolgozom, ahol a fejlesztés alatt álló termék folyamatosan működőképes állapotban van, ugyanakkor folyamatosan változtatnak rajta. A következő működő verzió megjelenésének határideje rettenetesen le van sűrítve, ugyanakkor mindezek felett óriási technikai kockázat lóg. Ilyen környezetben a kollégája kijavításának képessége olyan művészet, amely nélkül nem élhet túl. Az információcsere egy csapaton belül és több, gyakran földrajzilag elkülönült csapat között is kód segítségével történik. Kódot olvasunk, hogy megértsük az új vagy módosított rendszerszoftver-interfészek tervezését. Az összetett objektumok életciklusát és viselkedését tesztesetek, azaz ismét kód segítségével határozzuk meg. A hibajelentéseket tesztesetek kísérik, amelyek bemutatják a problémát, ismét kódot használva. Végezetül pedig folyamatosan azon dolgozunk, hogy javítsuk a meglévő kódot, hogy hatékonyabbá, rugalmasabbá és érthetőbbé tegyük azt. Nyilvánvalóan ilyen környezetben a szoftverfejlesztés szinte teljes egészében kódolásra épül, ugyanakkor képesek vagyunk a projekteket időben sikeresen befejezni, így ez a megközelítés eléggé életképes.

Ne feltételezze, hogy egy szoftverprojekt sikeres megvalósításához csupán meggondolatlan, heves programozásra van szüksége. Szoftverfejlesztés nagyon nehéz, jó minőségű szoftver fejlesztése és a munka időben történő elvégzése pedig még nehezebb. Ahhoz, hogy az általam leírt megközelítés működjön, fontos további szabályokat és technikákat kell következetesen alkalmazni. Kent Beck ezzel kezdi elgondolkodtató könyvét a HR-ről.

Kent azon Tektronix vezetői közé tartozott, akik felismerték a csatolt programozási technikákban rejlő óriási lehetőségeket a Smalltalk környezetben való komplex mérnöki alkalmazások fejlesztésében. Ward Cunninghammel együtt Kent inspirálta a mintaprogramozás (más néven mintaprogramozás) fejlesztését. minták programozása, ami nagyban befolyásolta saját karrieremet. Az XP olyan szoftverfejlesztési megközelítést ír le, amely számos sikeres fejlesztő által alkalmazott technikákat ötvözi, akik rengeteg irodalmat tanulmányoztak a programozói munka megszervezésével kapcsolatban, és a gyakorlatban teszteltek számos szoftvertermék fejlesztési módszert és eljárást. A mintaprogramozáshoz hasonlóan az XP is bevált gyakorlatokat épít fel, például szoftvermodulok tesztelését, páros programozást és kód átdolgozását. Az XP-n belül ezek a technikák úgy vannak kombinálva, hogy kiegészítsék és gyakran irányítsák egymást. Ennek a könyvnek a fő célja, hogy beszéljen a különböző technikák interakciójáról és közös használatáról. Minden programozási technikának egy a célja – adott funkcionalitású szoftvertermék létrehozása adott határidőre. Az OTI nagysikerű Just In Time Software folyamata nem tiszta XP, de sok hasonlóság van a két megközelítés között.

Együttműködtem Kenttel, és egy kicsi, de jól ismert JUnit nevű projektben használtam az XP epizódokat. A szoftverfejlesztéssel kapcsolatos nézetei és megközelítései mindig elgondolkodtattak azon, hogyan dolgoztam személyesen egy szoftverprojekten. Az XP kétségtelenül kihívás elé állítja a programozási iparban használt hagyományos megközelítéseket. Miután elolvasta ezt a könyvet, maga döntheti el, hogy szüksége van-e XP-re a munkájában vagy sem.

Erich Gamma

Bevezetés

Ez a könyv az extrém programozásról szól ( extrém programozás, XP). Az Extreme Programming egy egyszerűsített gyártási módszertan kis- és közepes méretű szakértői csapatok számára, akik szoftverterméket fejlesztenek tisztázatlan vagy gyorsan változó követelmények mellett. Ennek a könyvnek az a célja, hogy segítsen eldönteni, hogy az XP megfelelő-e az Ön helyzetében.

A HR sokak számára a józan ész szempontjából teljesen elfogadható és indokolt munkaszervezési módszerek halmazának tűnik. Akkor miért nevezik extrémnek az XP módszerekkel összhangban történő programozást? A lényeg az, hogy az XP számos általános és széles körben használt programozási elvet extrém szintre emel.

Ha a kód áttekintése jó, akkor folyamatosan ellenőrizzük a kódot (páros programozás);

Ha a tesztelés jó, akkor minden projekt résztvevő folyamatosan teszteli a programkódot (egységteszt), még az ügyfelek is (funkcionális tesztelés);

Ha a tervezés jó, akkor a tervezést a projekt minden résztvevőjének napi munkájának szerves részévé kell tenni (kód átdolgozása);

Ha jó az egyszerűség, akkor tartsuk meg a rendszert a legegyszerűbb kialakításban, amely biztosítja a jelenlegi szükséges funkcionalitási szintet (a legegyszerűbb, ami valószínűleg működik); ha az architektúra fontos, akkor a projekt minden résztvevője folyamatosan azon dolgozik, hogy meghatározza és felülvizsgálja az architektúrát (metafora);

Ha fontos az integrációs tesztelés, akkor a fejlesztés alatt álló rendszert naponta többször össze kell szerelni, tesztelni (folyamatos integráció);

Ha a kis iterációk jók, akkor az iterációkat nagyon-nagyon kicsire kell tenni - másodpercek, percek, esetleg órák, de nem hetek és hónapok, és semmiképpen sem évek (a tervezési játék).

Amikor először úgy döntöttem, hogy megfogalmazom magamnak az XP lényegét, elképzeltem, hogy egy vezérlőpult gombjai vannak. Mindegyik fogantyú egy bizonyos technikának felelt meg, amelyről a sajátjából személyes tapasztalat Tudtam, hogy elég hatásos. Mindegyik gomb lehetővé tette egy adott technika használatát egy bizonyos mértékig: 1-től 10-ig. Megpróbáltam az összes gombot a lehető legnagyobb pozícióba (10) állítani, és meglepődve tapasztaltam, hogy az általam figyelembe vett technikák teljes készlete stabil, kiszámítható maradt. és rugalmas.

Az XP kétféle ígéretet generál:

Az XP azt ígéri a programozóknak, hogy mindegyikük minden munkanapon az igazán fontos problémák megoldásán fog dolgozni. Egyikük soha nem kerül nehéz helyzetbe egyedül. Mindegyikük mindent megtehet majd a fejlesztés alatt álló rendszer sikeréért. Mindegyik pontosan azon a területen tud majd dönteni, amelyben kompetens, és ha valamelyik területen nem elég kompetens, nem vesz részt a döntéshozatalban.

Az XP megígéri az ügyfeleknek és a menedzsereknek, hogy a projekten végzett munka minden hetéből a lehető legnagyobb megtérülést kapják. Néhány hetente láthatják majd, hogyan haladnak a kitűzött célok felé. Lehetőségük lesz a projekt középső fejlesztési irányának megváltoztatására anélkül, hogy félnének további rendkívüli költségektől.

Dióhéjban az XP azt ígéri, hogy csökkenti a projektkockázatot, javítja az üzleti változásokra való reagálást, javítja a projektek termelékenységét, és élvezetesebbé teszi a szoftverfejlesztési folyamatot – mindezt egyszerre. Nem viccelek, hagyd abba a nevetést. Csak olvassa el ezt a könyvet, és meglátja, ha megőrültem.

Ez a könyv

Ez a könyv az XP technikával kapcsolatos dolgokról szól – annak gyökereiről, filozófiájáról, különféle történetekről és mítoszokról. A könyv célja, hogy segítsen megalapozott döntést hozni arról, hogy használjon-e XP-t saját projektjében. Ha a könyv elolvasása után úgy dönt, hogy nem használ XP-t a projektben, akkor a fő célt ugyanúgy elértem, mintha a könyv elolvasása után úgy döntött, hogy az XP-re van szüksége. A könyv második célja, hogy segítsen azoknak, akik már XP-t használnak. A könyv elolvasása után az ilyen olvasók jobban megérthetik ezt a technikát.

Ez a könyv nem ad pontos utasításokat az extrém programozási folyamat pontos végrehajtására vonatkozóan. Nem fogsz benne sok példát, algoritmust vagy programozási történetet látni. Mindezek megszerzéséhez kereshet az interneten, beszélgethet a projektek néhány résztvevőjével, megvárhatja, míg megjelennek a neki szentelt könyvek, vagy saját maga készíthet ilyen anyagokat.

Az általam leírt XP szoftverfejlesztési tudományág jövőbeli sorsa egy olyan embercsoport (talán te is közéjük tartozol) kezében van, akik elégedetlenek a programozók munkaszervezésének jelenleg meglévő hagyományos módszereivel. szükséged van a legjobb módja szoftverfejlesztés, produktívabb és barátságosabb kapcsolatokat szeretne kialakítani ügyfeleivel, boldogabbá, lojálisabbá és eredményesebbé szeretné tenni a vezetése alatt álló programozókat. Röviden: jelentős előnyre szeretne szert tenni, és nem fél új ötleteket felhasználni ennek az előnynek a megszerzésére. Mielőtt azonban bármilyen kockázatot vállalna, meg kell győződnie arról, hogy legalább nem vagy teljesen bolond.

Az XP arra utasítja, hogy teljesen más módon végezze el a munkát, mint amit megszokott. Egyes esetekben az XP ajánlásai teljesen ellentmondanak az általánosan elfogadott normáknak. Jelenleg úgy gondolom, hogy csak az használhat XP-t, akinek nyomós oka van a dolgok meglévő rendjének megváltoztatására. Ha azonban ilyen okok fennállnak, azonnal elkezdheti használni az XP-t. Ezt a könyvet azért írtam, hogy többet megtudjon ezekről az okokról.

Mi az az XP?

Mi az az XP? Az XP egy leegyszerűsített, hatékony, rugalmas, kiszámítható, tudományos alapú és rendkívül élvezetes módja olyan szoftverek fejlesztésének, amelyek alacsony szint kockázat. Az XP a következő módokon különbözik a többi módszertől.

A rendkívül rövid fejlesztési ciklusok használatával az XP gyors, valódi és mindig bekapcsolt állapotot kínál visszacsatolás.

Az XP növekményes tervezést használ, aminek eredményeképpen egy átfogó projektterv meglehetősen gyorsan elkészül, de nyilvánvaló, hogy ez a terv a projekt teljes élettartama során fejlődik.

Az XP rugalmas ütemezést alkalmaz egy-egy funkcionalitás megvalósítására, ami javítja az üzlet változó jellegére és az ezzel kapcsolatos változó vevői igényekre való reagálást.

Az XP a programozók és az ügyfelek által kifejlesztett automatizált teszteken alapul. Ezeknek a teszteknek köszönhetően lehetőség nyílik a fejlesztési folyamat nyomon követésére, a rendszer megfelelő fejlődésére, valamint a rendszerben meglévő hibák azonnali észlelésére.

Az XP szóbeli kommunikáción, teszteken és forráskódon alapul. Ez a három eszköz a rendszer felépítésével és viselkedésével kapcsolatos információcserére szolgál.

Az XP egy fejlődő tervezési folyamaton alapul, amely mindaddig tart, amíg maga a rendszer létezik.

Az XP a leggyakoribb készségekkel és képességekkel rendelkező programozók közötti szoros együttműködésen alapul.

Az XP olyan technikákon alapul, amelyek kielégítik az egyes programozók rövid távú ösztöneit és a teljes projekt hosszú távú érdekeit.

Az XP egy szoftverfejlesztési tudományág. Ez egy fegyelem, mert az XP-n belül vannak bizonyos dolgok, amelyeket meg kell tennie, ha XP-t akar használni. Nem szabad döntened, hogy írsz-e teszteket vagy sem, mert ha nem, akkor a programozás, amit csinálsz, nem extrém: a vita vége.

Az XP módszertan olyan projekteken való munkavégzésre szolgál, amelyeken két-tíz programozó dolgozhat, akik nincsenek beszorulva a meglévő számítógépes környezet merev keretei közé, és amelyekben minden szükséges munkát a kapcsolódó tesztelés egy napon belül elvégezhető.

Az XP megijeszt vagy irritál néhány embert, aki először találkozik ezzel a technikával. Az XP mögött azonban egyetlen ötlet sem új. A HR módszertan bizonyos értelemben konzervatív – a keretein belül alkalmazott valamennyi technikát több évtizedes (végrehajtási stratégia), sőt évszázados (menedzsmentstratégia tekintetében) is tesztelték.

Az XP újításai a következő funkciókat tartalmazzák:

Mindezek a régóta ismert technikák egy fedél alatt vannak összegyűjtve;

Az intenzitás, amellyel ezeket a technikákat bevezetik a napi munkába, a szélsőségesek;

Az alkalmazott technikák a lehető legnagyobb mértékben támogatják egymást.

Megfelelőség

Műveiben Az erdei nép és a hegy (People Mountain Peoples) Colin Turnbull antropológus két nagyon különböző társadalmat ír le. A hegyekben az élethez szükséges erőforrások szűkösek, az emberek mindig az éhezés szélén állnak. Az ilyen körülmények között kialakult kultúra félelmetesnek tűnik. Az anyák elhagyják gyermekeiket, hogy túléljék magukat. Az élelmiszer halált okozhat. A kegyetlenség, az állatiasság és az árulás gyakori és mindennapos.

A hegyekkel ellentétben az erdő gazdag erőforrásokban. Ahhoz, hogy egy embernek egész nap élelmet biztosítson, csak körülbelül fél órát kell eltöltenie. Az erdei kultúra a hegyi kultúra fordított tükre. A felnőttek részt vesznek a közös gyermekek nevelésében és nevelésében, akik szeretetben és törődésben nőnek fel, amíg nem lesz elég kompetens ahhoz, hogy gondoskodjon önmagukról. Ha valaki véletlenül megöl egy másikat (az előre megfontolt gyilkosság nem ismerős ezeknek az embereknek), kiszorul a társadalomból. Ebben az esetben azonban a száműzöttnek egyszerűen vissza kell vonulnia az erdőbe, és ott több hónapot el kell töltenie, és a törzs egyes tagjai akkor is hoznak neki élelmet és ajándékokat.

Az XP arra a kérdésre próbál válaszolni: Hogyan programoznál személyesen, ha lenne elég időd? Valójában nincs több időd, mert végül is a programozás egy üzlet. Minden üzletben az nyer, aki gyorsabban végzi el a munkát. Viszont ha lenne időd, valószínűleg a tesztfejlesztésre is odafigyelnél; valószínűleg újra áttervezné a rendszer architektúráját, ha arra a következtetésre jutna, hogy ez szükséges; valószínűleg többet kommunikálna programozótársaival, valamint az ügyféllel.

Egy ilyen elégséges érzés humánusabbnak tűnik, ellentétben azokkal a helyzetekkel, amikor a programozók minden erejükkel igyekeznek a megadott időkereten belül maradni, lemaradnak az ütemtervről, és nem tudnak nagy mennyiségű rendkívüli feladatot teljesíteni. fontos munka csak azért, hogy a projektet időben teljesíteni tudjam. A kapkodás megakadályozza a programozókat abban, hogy teljes mértékben kinyilvánítsák tehetségüket és élvezzék munkájukat. Amikor azonban elkezdi tanulmányozni az XP-t, meg kell értenie, hogy az elégtétel egyben jó üzlet is. Az elegendőség érzése a hatékonyság forrásává válik, ahogyan a hiányérzet kudarcokat okoz a munkában, ami hibákhoz, alacsonyabb minőséghez és végső soron alacsonyabb termelékenységhez vezet.

Könyvvázlat

A könyv úgy van megírva, mintha te és én együtt alkotnánk meg a szoftverfejlesztés új tudományágát. Kezdjük azzal, hogy megvizsgáljuk a szoftverfejlesztéssel kapcsolatos alapvető ismereteinket. Ezt követően tulajdonképpen egy új tudományágat hozunk létre. Ezután megvizsgáljuk, milyen következményekkel jár az, amit létrehoztunk – hogyan lehet megvalósítani és használni a gyakorlatban, mikor nem szabad használni, és milyen lehetőségeket kínál a vállalkozások számára.

A könyv három részre oszlik.

Probléma: től kezdődő fejezetekben Kockázat: a fő problémaés véget ér Vissza az alapokhoz, meghatározzák azt a problémát, amelyet az extrém programozás próbál megoldani, és olyan kritériumokat állítanak fel, amelyek alapján a megoldás minősége értékelhető. Ebben a részben általános képet kap az extrém programozási módszertanról.

Megoldás: től kezdődő fejezetekben Rövid áttekintés és véget ér Tesztelési stratégia, a könyv első részében bemutatott absztrakt ötletek tudományág-specifikus technikák halmazává alakulnak. Ez a fejezet nem tartalmaz információt arról, hogy pontosan hogyan alkalmazhatja a leírt technikákat a gyakorlatban. Ehelyett az egyes technikák általános formájáról van szó. Az egyes technikák tárgyalása során a könyv első részében tárgyalt kérdésekhez és elvekhez kapcsolom őket.

XP megvalósítás: től kezdődő fejezetekben XP megvalósításés véget ér XP munka közben, számos, az XP megvalósításával kapcsolatos kérdés kerül megvitatásra – hogyan kell az XP-t implementálni, mit kell várni az XP projektben részt vevő különböző személyektől, milyen felfogása van az XP-ről az üzleti világban.

Köszönetnyilvánítás

Első személyben szólok az olvasókhoz, nem azért, mert a könyv a saját ötleteimet mutatja be, hanem azért, mert elmondom, hogyan vélekedek ezekről az elképzelésekről. Az XP-n belül használt technikák többsége egyidős az összes programozással.

Ward Cunningham a könyv anyagának elsődleges forrása. Különben is, az elmúlt tizenöt évet azzal töltöttem, hogy elmagyarázzam másoknak, mit csinál Ward gyakorlatilag hosszú ideje. Köszönet Ron Jeffries-nek is, hogy ezt is kipróbálta, majd sokkal jobbá tette. Köszönet Martin Fowlernek, hogy mindezt egyszerű, gyengéd nyelvezeten és banktörés nélkül elmagyarázta. Köszönet Erich Gammának a hosszú beszélgetésekért és a hattyúkon való elmélkedésért Lymmben, és azt is, hogy nem engedte meg, hogy rossz gondolatokkal a fejemben távozzam. És persze mindez nem történt volna meg az életemben, ha nem lett volna olyan példaképem, mint apám, Doug Beck, aki hosszú éveken át csiszolta programozási tudását.

Köszönöm a Chrysler C3 csapatának, hogy végigvezettek a kutatásom során. És külön köszönet menedzsereinknek, Sue Ungernek és Ron Savage-nek, hogy volt bátorságuk kipróbálni minket.

Köszönet a Daedalos Consultingnak a könyv megírásában nyújtott segítségéért.

A megtekintési anyag bajnoki díját Paul Chisholm kapja bőséges, tömör, aprólékos és gyakran kifejezetten bosszantó megjegyzéseiért. Az ő segítsége nélkül ez a könyv feleannyira sem lett volna népszerű.

Nagyon élveztem kommunikálni mindazokkal, akik végrehajtották előnézet amit írtam.

Munkájuk nagy segítségemre volt. Nem találok hálás szavakat azért, hogy volt türelmük végigolvasni ezt a sok prózát, sokuk számára idegen nyelven.

Köszönet: Greg Hutchinsonnak, Massimo Arnoldinak, Dave Clealnek, Sames Schusternek, Don Wellsnek, Josha Kerievskynek, Thorsten Dittmarnak, Moritz Beckernek, Daniel Gublernek, Christoph Henricinek, Thomas Zangnak, Dierknek (nem sorrendben, ahogyan tőlük kaptam megjegyzéseket). Koenig, Miroslav Miroslav Novak, Rodney Rayan, Frank Westphal, Paul Trunz, Steve Hayes, Kevin Bradtke, Jeanine De Guzman, Tom Kubit, Falk Bruegmann, Hasko Heinecke, Peter Merel, Rob Mee, Pete McBreen, Thomas Ernst, Guido Guido Haechler, Dieter Holz, Martin Knecht, Dierk Krampe, Patrick Lisser, Elisabeth Maier, Thomas Mancini, Alexio Moreno (Alexio Moreno), Rolf Pfenninger és Matthias Ressel.

A kiadótól

Észrevételeit, javaslatait, kérdéseit a következő címre küldje: email [e-mail védett](Péter kiadó, számítógépes kiadás).

Szeretnénk hallani a véleményét!

A könyvben szereplő összes forrásszöveg megtalálható a címen http://www.piter.com/download.

A kiadó honlapján http://www.piter.com megtalálja részletes információkat könyveinkről.

Probléma

A könyvnek ez a része meghatározza az extrém programozás színterét. Leírja a probléma különböző aspektusait, amelyeket a szoftverfejlesztés új tudományágának kialakításával kell megoldani.

Ez a rész azokat az alapvető feltételezéseket tárgyalja, amelyeket figyelembe kell vennünk a szoftverfejlesztési gyakorlatok kiválasztásakor - az autóvezetés metaforáját, a négy jelentést, az ezekből a jelentésekből kialakított elveket, valamint azokat a tevékenységeket, amelyeket a szoftverfejlesztés új tudományágán belül kell strukturálni.

Kockázat: a fő probléma

A meglévő szoftverfejlesztési tudományágak nem működnek, és nem hozzák meg a kívánt gazdasági hatást. Ennek a problémának óriási gazdasági és humanitárius jelentősége van. A szoftverfejlesztés új módszerére van szükségünk.

A szoftverfejlesztés fő problémája az kockázat.

Íme néhány példa a kockázatra.

Grafikon eltolás– eljön a munka esedékes napja, és kénytelen tájékoztatni a megrendelőt, hogy a fejlesztés alatt álló rendszer még hat hónapig nem lesz kész.

A projekt lezárása– többszöri ütemezési eltolódást és a szállítási határidő elhalasztását követően a projektet úgy zárják le, hogy még a munkakörülmények közötti tesztelés szakaszába sem kerül.

A rendszer elveszti hasznosságát– a kifejlesztett szoftver sikeresen települ valós termelési munkakörnyezetben, de pár éves használat után a változtatások költsége és/vagy a hibák száma annyira megnő, hogy olcsóbbá válik a rendszer cseréje fejlesztés.

– a szoftverrendszer valós termelési munkakörnyezetbe van telepítve, de a hibák és hiányosságok száma olyan nagy, hogy a rendszert nem használják.

– Valódi termelési munkakörnyezetbe telepítenek egy szoftverrendszert, de kiderül, hogy valójában nem oldja meg azt az üzleti problémát, amelyet eredetileg megoldani szántak.

Az üzlet természetének megváltozása– Valódi termelési munkakörnyezetbe telepítenek szoftverrendszert, de az elmúlt fél évben a probléma, aminek a megoldására a rendszert tervezték, irrelevánssá vált, és ehelyett új, még súlyosabb problémával szembesült a vállalkozás.

Lehetőségek hiánya– A szoftverrendszer számos potenciálisan érdekes funkcióval rendelkezik, amelyek mindegyikét öröm volt programozni, de kiderült, hogy ezek közül egyik sem hoz túl sok hasznot az ügyfél számára.

Személyi fluktuáció– két éven belül a projekten dolgozó jó programozók egymás után gyűlölték a fejlesztés alatt álló terméket szoftver rendszerés elment egy másik munkára.

Ennek a könyvnek az oldalain az extrém programozásról olvashat ( extrém programozás, XP) egy szoftverfejlesztési tudományág, amely a kockázat csökkentésére összpontosít a fejlesztési folyamat minden szintjén. Az XP jelentősen növeli a termelékenységet és javítja a kifejlesztett programok minőségét, emellett egy nagyon szórakoztató gyakorlat, amely minden résztvevőnek sok örömet okoz.

Hogyan csökkenti az XP a korábban felsorolt ​​kockázatokat?

Grafikon eltolás– Az XP nagyon rövid kiadási időt javasol minden új verzióhoz. Feltételezhető, hogy a rendszer minden egymást követő használatra kész verzióját legfeljebb néhány hónapon belül kifejlesztik. Így az egyes verziókon belüli munkakör korlátozott, ami azt jelenti, hogy ha műszak van, az kevésbé jelentős. Minden kiadás az ügyfelek által kért funkciók többszöri iterációját tartalmazza, mindegyik iteráció kifejlesztése egy-négy hetet vesz igénybe. Ez rugalmas és reagáló visszajelzést biztosít az ügyfélnek, aminek köszönhetően képet kap a munka aktuális folyamatáról. Az egyes iterációkon belül az XP szerinti tervezés több olyan feladat tekintetében is megtörténik, amelyeket meg kell oldani a következő iteráció eléréséhez. Minden feladatot egytől három napig osztanak ki. Ennek eredményeként a csapat még iteráció közben is képes észlelni és kijavítani a problémákat. Végül, az XP azt jelenti, hogy először a legmagasabb prioritású funkciókat kell megvalósítani. Így minden olyan szolgáltatás, amelyet nem lehet megvalósítani a szoftvertermék következő verziójában, alacsonyabb prioritású.

A projekt lezárása– az XP keretein belül a megrendelőnek meg kell határoznia azt a legkisebb elfogadható képességkészletet, amellyel a program legalább működőképes, üzleti problémák megoldása szempontjából értelmes verziója rendelkezzen. Így a programozóknak minimális erőfeszítést kell tenniük annak biztosítására, hogy az ügyfél megértse, szüksége van-e erre a projektre vagy sem.

A rendszer elveszti hasznosságát– az XP-n belül hatalmas számú tesztet készítenek és tartanak karban, amelyek minden rendszerváltozás után (naponta többször) elindulnak és újraindulnak, ennek köszönhetően gondosan nyomon lehet követni a kifejlesztett program minőségét. Az XP mindig kiváló állapotban tartja a rendszert. A hibáknak egyszerűen nem szabad felhalmozódniuk.

A hibák és hiányosságok száma– az XP-n belül a fejlesztés alatt álló rendszert mind a programozók tesztelik, akik minden egyes fejlesztés alatt álló funkcióhoz teszteket készítenek, mind pedig az ügyfelek, akik teszteket készítenek a rendszer minden egyes implementált funkciójához.

Inkonzisztencia a megoldandó problémával– XP-n belül az ügyfél a projekten dolgozó csapat szerves része. A projektspecifikációt a projekt teljes időtartama alatt folyamatosan felülvizsgálják, aminek köszönhetően az ügyfél által a fejlesztőcsapat felé közölt pontosítások és felfedezések azonnal megjelennek a kidolgozott programban.

Extrém programozás: tesztvezérelt fejlesztés

Cindynek szenteltem: lelkem szárnyai

A kiadói jogokat az Addison-Wesley Longmannel kötött megállapodás alapján szerezték meg. Minden jog fenntartva. A könyv egyetlen része sem reprodukálható semmilyen formában a szerzői jogok tulajdonosainak írásos engedélye nélkül.

A könyvben található információk a kiadó által megbízhatónak ítélt forrásokból származnak. Figyelembe véve azonban az esetleges emberi vagy technikai hibákat, a kiadó nem tudja garantálni a közölt információk abszolút pontosságát és teljességét, és nem vállal felelősséget a lehetséges hibákat a könyv használatával kapcsolatos.

ISBN 978-0321146533 angol

ISBN 978-5-496-02570-6

© 2003, Pearson Education, Inc.

© Fordítás orosz nyelvre LLC "Piter" Kiadó, 2017

© Orosz nyelvű kiadás, tervezte: Peter Publishing House LLC, 2017

© „Programozói könyvtár” sorozat, 2017

Előszó

Tiszta kód, ami működik„Tiszta kód, amely működik” – ez a rövid, de értelmes kifejezés, amelyet Ron Jeffries alkotott meg, a tesztvezérelt fejlesztés (TDD) teljes jelentését magába foglalja. A működő tiszta kód olyan cél, amelyre érdemes törekedni, mert

Ez a programok kidolgozásának kiszámítható módja. Tudja, mikor tekinthető egy munka befejezettnek anélkül, hogy a hibák hosszú sorozata miatt kellene aggódnia;

Lehetőséget ad a kód által tanított leckék megtanulására. Ha az első eszébe jutó ötletet használja, esélye sem lesz a második, jobb ötlet megvalósítására;

Javítja a programok felhasználóinak életét;

Lehetővé teszi, hogy kollégái számíthassanak Önre, Ön pedig számítson rájuk;

Élvezetesebb ilyen kódot írni.

De hogyan juthat tiszta kódhoz, amely működik? Sok erő megakadályozza, hogy tiszta kódot kapjunk, és néha még csak működő kódot sem kaphatunk. Számos probléma elkerülése érdekében automatizált tesztelés alapján fejlesztjük a kódot. Ezt a programozási stílust tesztvezérelt fejlesztésnek nevezik. Ennek a technikának megfelelően

Az új kód csak egy sikertelen automatikus teszt megírása után íródik;

Minden párhuzamosság megszűnik.

Két egyszerű szabályok, nem igaz? Azonban összetett egyéni és csoportos viselkedést generálnak, számos technikai következménnyel:

A tervezési folyamat során folyamatosan futtatjuk a kódot, és képet kapunk a működéséről, ez segít a helyes döntések meghozatalában;

Saját teszteket írunk, mert alig várjuk, hogy valaki más írjon teszteket helyettünk;

Fejlesztői környezetünknek gyorsan kell reagálnia a kis kódmódosításokra;

A programtervezésnek sok önálló, lazán csatolt komponens használatán kell alapulnia, hogy a kód könnyebben tesztelhető legyen.

Az említett két TDD-szabály határozza meg a programozási lépések sorrendjét.

1. Piros - Írj egy kis tesztet, ami nem működik, és talán nem is fordítható le.

2. Zöld – a lehető leggyorsabban futtassa le a tesztet, anélkül, hogy aggódnia kellene a tervezés helyességéért és a kód tisztaságáért. Írjon csak annyi kódot, hogy a teszt működjön.

3. Újrafaktorálás – szüntesse meg a duplikációkat az írott kódból.

A piros – zöld – refaktorálás a TDD mantrája.

Ha feltételezzük, hogy ez a programozási stílus lehetséges, akkor feltételezhetjük, hogy használatának köszönhetően a kód lényegesen kevesebb hibát tartalmaz majd, ráadásul a munka célja mindenki számára egyértelmű lesz, aki részt vesz benne. Ha igen, akkor csak a tesztek teljesítéséhez szükséges kód fejlesztése társadalmi következményekkel is jár:

Ha a hibasűrűség elég alacsony, a minőségbiztosítási (QA) csapat képes lesz a hibákra való reagálásról a megelőzésre;

Kevesebb kellemetlen meglepetéssel a projektmenedzserek pontosabban becsülhetik meg a munkaerőköltségeket, és vonhatják be az ügyfeleket a fejlesztési folyamatba;

Ha a technikai megbeszélések témái egyértelműen meghatározottak, akkor a programozók képesek lesznek folyamatosan kommunikálni egymással, nem pedig naponta vagy hetente egyszer;

Ismét kellően alacsony hibasűrűséggel tudunk majd minden nap egy integrált munkaterméket előállítani, amelyhez új funkcionalitást egészítünk ki, amivel teljesen új típusú üzleti kapcsolatot létesíthetünk ügyfeleinkkel.

Az ötlet tehát egyszerű, de mi az érdekünk? Miért kell egy programozónak vállalnia az automatizált tesztek írásának további felelősségét? Miért lépne előre egy programozó apró lépésekben, ha az agya képes egy sokkal összetettebb tervezési struktúrán keresztül gondolkodni? Bátorság.

A TDD a félelem kezelésének módja a programozási folyamatban. Nem arra gondolok, hogy leesik a székről, vagy attól, hogy a főnöke előtt áll. Úgy értem, hogy félek egy olyan problémával szembenézni, „olyan nehéz, hogy még fogalmam sincs, hogyan oldjam meg”. A fájdalom az, amikor a természet azt mondja: „Állj!”, a félelem pedig az, amikor a természet azt mondja: „Légy óvatos!” Az óvatosság egyáltalán nem rossz, de az előnyök mellett a félelem negatív hatással is van ránk:

A félelem arra kényszerít bennünket, hogy előre és alaposan átgondoljuk, mihez vezethet ez vagy az a cselekvés;

A félelem miatt kevesebbet kommunikálunk;

A félelemtől félünk a munkánk értékelésétől;

A félelem ingerlékenysé tesz bennünket.

Ezek egyike sem segít a programozási folyamatban, különösen, ha összetett problémán dolgozik. Tehát azzal a kérdéssel kell szembenéznünk, hogyan lehet kikerülni nehéz helyzetÉs

Ne próbálja megjósolni a jövőt, hanem azonnal kezdje el a probléma gyakorlati tanulmányozását;

Ne szigetelje el magát a világ többi részétől, hanem növelje a kommunikáció szintjét;

Ne kerülje el a válaszokat, hanem éppen ellenkezőleg, hozzon létre megbízható visszajelzést, és segítségével gondosan kövesse nyomon cselekedeteinek eredményeit;

(az irritációt magának kell kezelnie).

Hasonlítsuk össze a programozást egy vödör kiemelésével a kútból. A vödröt megtelik vízzel, elforgatod a kart, tekered a láncot a gallér köré és emeled fel a vödröt. Ha kicsi a vödör, akkor egy rendes, szabadon forgó kapu is megfelel. De ha a vödör nagy és nehéz, akkor fáradt lesz, mielőtt felemeli. Ahhoz, hogy a kar elfordításai között pihenni tudjon, egy racsnis mechanizmusra van szükség, amely lehetővé teszi a kar reteszelését. Minél nehezebb a kanál, annál gyorsabban kell követnie a fogaskereket a racsnis fogaskereken.

A TDD tesztjei olyanok, mint a racsnis fogaskerekek fogai. A teszt működését követően tudjuk, hogy a teszt most működik, most és mindörökké. Egy lépéssel közelebb vagyunk a befejezéshez, mint a teszt éles indítása előtt. Ezt követően a második tesztet, majd a harmadikat, negyediket stb. működtessük. Minél összetettebb a programozó problémája, annál kevésbé funkcionalitás minden tesztet le kell fednie.

Könyvolvasók Extrém programozás Magyarázd el Lehet, hogy észrevette az extrém programozás (XP) és a tesztvezérelt fejlesztés (TDD) hangszínének különbségét. Az XP-vel ellentétben a TDD módszertana nem abszolút. Az XP azt mondja: "Ahhoz, hogy továbbléphess, el kell sajátítanod ezt és ezt." A TDD egy kevésbé specifikus technika. A TDD feltételezi, hogy van egy intervallum a döntéshozatal és az eredmények között, és eszközöket biztosít ezen intervallum hosszának kezelésére. „Mi lenne, ha egy hetet töltenék azzal, hogy megtervezek egy algoritmust papíron, majd kódot írok egy teszt-első megközelítéssel? Ez TDD-kompatibilis lesz?” Természetesen lesz. Ismeri a döntés meghozatala és az eredmények értékelése közötti intervallum nagyságát, és ezt az intervallumot tudatosan szabályozza.

A legtöbb ember, aki elsajátította a TDD-t, azt mondja, hogy programozási gyakorlata jobbra változott. Vizsgálatok által fertőzött(tesztfertőzött) – ezt a meghatározást Erich Gamma alkotta meg ennek a változásnak a leírására. Miután elsajátítottad a TDD-t, sokkal több tesztet írsz, mint korábban, és olyan apró lépésekkel haladsz előre, amelyek korábban értelmetlennek tűntek volna. Másrészt néhány programozó, miután megismerkedett a TDD-vel, úgy dönt, hogy visszatér a korábbi gyakorlatokhoz, és fenntartja a TDD-t különleges alkalmakkor amikor a hagyományos programozás nem vezet a kívánt előrelépéshez.

Mindenképpen vannak olyan problémák, amelyeket (legalábbis jelenleg) nem lehet önmagában tesztekkel megoldani. A TDD különösen nem teszi lehetővé a kifejlesztett kód megfelelőségének mechanikus bemutatását az adatbiztonság és a párhuzamos műveletek megbízhatósága szempontjából. Természetesen a biztonság alapja a hibamentes kód, de az adatvédelmi eljárásokban való emberi részvételen is. A finom párhuzamossági problémákat nem lehet biztosan reprodukálni egy kód egyszerű futtatásával.