Kent Beck - Extrémne programovanie. Testom riadený vývoj

Žáner: ,

Séria:
Vekové obmedzenia: +
Jazyk:
Pôvodný jazyk:
Prekladatelia:
Vydavateľ:
Mesto vydania: Saint Petersburg
Rok vydania:
ISBN: 978-5-496-02570-6 Veľkosť: 382 kB

Držitelia autorských práv!

Prezentovaný fragment práce je zverejnený po dohode s distribútorom legálneho obsahu, liter LLC (nie viac ako 20% pôvodného textu). Ak sa domnievate, že uverejnenie materiálu porušuje práva niekoho iného, potom.

Čitatelia!

Zaplatili ste, no neviete ako ďalej?

Pozor! Sťahujete úryvok povolený zákonom a držiteľom autorských práv (nie viac ako 20 % textu).
Po kontrole budete vyzvaní, aby ste prešli na webovú stránku držiteľa autorských práv a zakúpili plná verzia Tvorba.

Popis knihy

Návrat slávneho bestselleru. Elegantný, flexibilný a zrozumiteľný kód, ktorý sa ľahko upravuje, funguje korektne a na svojich tvorcov neprináša nepríjemné prekvapenia. Je to naozaj možné? Ak chcete dosiahnuť svoj cieľ, skúste program pred napísaním otestovať. Práve táto paradoxná myšlienka tvorí základ metodiky TDD (Test-Driven-Development). Nezmysel? Neponáhľajte sa robiť unáhlené závery. Vzhľadom na použitie TDD na príklade vývoja skutočného programového kódu autor demonštruje jednoduchosť a silu tejto techniky. Kniha obsahuje dva softvérové projekty, ktoré boli úplne implementované pomocou TDD. Po príkladoch nasleduje rozsiahly katalóg techník v štýle TDD, vzorov a refaktorov relevantných pre TDD. Kniha bude užitočná pre každého programátora, ktorý chce zvýšiť svoju produktivitu a mať z programovania radosť.

Posledný dojem z knihy

SharerSharpened:
16-12-2018, 02:17

Pred čítaním tejto knihy som sa snažil písať testy na základe prečítaných článkov, no až s touto knihou som sa v tom začal orientovať.

Prečítal som si to dvakrát. Prvýkrát som to len čítal.

Ničomu nerozumel. Druhýkrát som písal kód pri čítaní knihy a potom mi konečne svitlo, čo je čo, a hlavne som cítil veľkosť kroku, ktorým môžem zmeniť kód bez toho, aby som nad tým stratil kontrolu. Potešila ma druhá kapitola, kde som spolu s autorom napísal vlastný systém testovania jednotiek v Pythone, bolo to ako keby ste si robili operáciu na vlastnom mozgu (v skutočnosti je to presne to prirovnanie, ktoré urobil sám autor) - jeden neopatrný pohyb a nič nefunguje, treba sa pohybovať po veľmi malých krokoch. Tretiu kapitolu som čítala selektívne, možno ju niekedy dokončím.

kolaps

⬇ Ostatné komentáre

Toto je kniha o extrémnom programovaní. Extrémne programovanie, často skracované ako „XP“, je zjednodušená produkčná metodika pre malé až stredne veľké vývojové tímy. softvérový produkt vzhľadom na nejasné alebo rýchlo sa meniace požiadavky. Táto kniha je navrhnutá tak, aby vám pomohla určiť, či je XP vhodný pre vašu situáciu...

O sérii XP

Extrémne programovanie, často označované skratkou XP, je vývojová disciplína softvér a podnikanie v oblasti tvorby softvérových produktov, ktoré sústreďuje úsilie oboch strán (programátorov aj obchodníkov) na spoločné, úplne dosiahnuteľné ciele. Tímy používajúce XP produkujú kvalitný softvér veľmi rýchlym tempom. Techniky, ktoré tvoria disciplínu HR opísanú v tejto knihe, sú zvolené preto, lebo sú založené na ľudskej kreativite a uznaní, že ľudia sú nestále a omylné stvorenia.

XP sa často prezentuje ako súbor techník, ale samotné XP nie sú cieľovou čiarou. Na to, aby ste na konci procesu získali tú dlho očakávanú zlatú hviezdu, nemusíte byť stále lepší v praktizovaní a rozvoji HR. Naopak, štartovacia čiara je XP. XP si kladie otázku: „Aké minimálne môže byť naše úsilie, aby sme mohli pokračovať vo výrobe kvalitného softvéru?

Začiatok odpovede na otázku znie takto: ak chceme vyvíjať kvalitné programy bez turbulencií a zmätkov, musíme byť ochotní v našom tíme plne implementovať niekoľko techník, ktoré sa chystáme využiť naplno. Ak použijeme tieto techniky napoly, problémy zostanú a na ich vyriešenie bude potrebné prejsť k využívaniu techník v plnej miere. Ak sa obmedzíme na polovičné miery, časom sa v nich tak zamotáme, že nedokážeme pochopiť, že to hlavné, čo vzniká prácou programátorov, vzniká práve vďaka programovaniu.

Povedal som "začiatok odpovede na", pretože pokračovanie v skutočnosti neexistuje. Ľudia, ktorí vytvorili a implementovali XP, mysleli aj na vyriešenie tohto problému. Keď sa pokúsili použiť XP, prekročili prah a vstúpili do neznáma. Keď sa vrátili, vyrozprávali svoj príbeh. Myšlienky, ktoré vyjadrili, sú nápisy umiestnené pozdĺž cesty: „Tu žijú draci“, „Otvorené o 15 km dobrý výhľad", "Táto oblasť je nebezpečná, keď prší."

Prepáčte, ale je čas, aby som sa pustil do programu.

Predslov

extrémne programovanie (

Extrémne programovanie

XP) definuje kódovanie ako kľúčovú a základnú činnosť pri práci na softvérovom projekte. Toto môže byť nesprávne!

Myslím, že stojí za to zamyslieť sa nad mojimi skúsenosťami s vývojom softvéru. Pracujem v prostredí, kde je neustále vyvíjaný produkt v pracovnom stave, a zároveň sa v ňom neustále robia zmeny. Termín vydania ďalšej pracovnej verzie je strašne stlačený a zároveň nad tým všetkým visí obrovské technické riziko. V takomto prostredí je schopnosť korigovať kolegu umenie, bez ktorého sa nedá prežiť. Výmena informácií v rámci tímu aj medzi viacerými tímami, ktoré sú často geograficky oddelené, sa uskutočňuje pomocou kódu. Čítame kód, aby sme pochopili návrh nových alebo upravených rozhraní systémového softvéru. Životný cyklus a správanie komplexné objekty sú definované pomocou testovacích prípadov, teda opäť pomocou kódu. Hlásenia problémov sú sprevádzané testovacími prípadmi demonštrujúcimi problém, opäť pomocou kódu. Nakoniec sme neustále zaneprázdnení zlepšovaním existujúceho kódu, aby bol výkonnejší, flexibilnejší a zrozumiteľnejší. Je zrejmé, že v podobné podmienky Vývoj softvéru je takmer výlučne založený na kódovaní, napriek tomu sme schopní úspešne dokončiť projekty včas tento prístup celkom životaschopné.

Nepredpokladajte, že všetko, čo potrebujete na úspešnú implementáciu softvérového projektu, je bezohľadné, divoké programovanie. Vývoj softvéru je veľmi náročný a vývoj kvalitného softvéru a dokončenie práce načas je ešte náročnejšie. Aby prístup, ktorý som opísal, fungoval, je nevyhnutný konzistentná aplikácia dôležité dodatočné pravidlá a techniky. Toto je miesto, kde Kent Beck začína svoju knihu o HR, ktorá vás núti zamyslieť sa.

Spolupracoval som s Kentom a použil som epizódy opísané v XP pri práci na malom, ale známom projekte s názvom JUnit

Úvod

Táto kniha je o extrémnom programovaní (

Extrémne programovanie

XP). Extreme Programming je zjednodušená produkčná metodika pre malé a stredné tímy špecialistov vyvíjajúcich softvérový produkt v podmienkach nejasných alebo rýchlo sa meniacich požiadaviek. Táto kniha je navrhnutá tak, aby vám pomohla určiť, či je XP vhodný pre vašu situáciu.

Pre mnohých vyzerá HR ako súbor úplne prijateľných a opodstatnených z pohľadu zdravého rozumu metód organizácie práce. Prečo sa potom programovanie v súlade s metódami XP nazýva extrémne? Ide o to, že XP posúva mnohé bežné a široko používané princípy programovania do extrémnych úrovní.

Ak je kontrola kódu dobrá, potom budeme kód kontrolovať neustále (párové programovanie);

Ak je testovanie dobré, každý účastník projektu bude neustále testovať programový kód (testovanie jednotiek), dokonca aj zákazníci ( funkčné testovanie);

Ak je dizajn dobrý, potom by mal byť dizajn neoddeliteľnou súčasťou každodennej práce každého z účastníkov projektu (prepracovanie kódu);

Extrémne programovanie

Venované môjmu otcovi a tiež vďaka Cindee Andres, mojej manželke a partnerke, za to, že som ju odignoroval a písal. Ďakujem Bethany, Lincolnovi, Forrestovi, že ma neprerušili a nechali ma písať.

O sérii XP

Extrémne programovanie, často označované skratkou XP, je disciplína vývoja softvéru a softvérového biznisu, ktorá zameriava úsilie oboch strán (programátorov a obchodníkov) na spoločné, dosiahnuteľné ciele. Tímy používajúce XP produkujú kvalitný softvér veľmi rýchlym tempom. Techniky, ktoré tvoria disciplínu HR opísanú v tejto knihe, boli vybrané, pretože sú založené na ľudskej kreativite a uznaní, že ľudia sú nestále a omylné stvorenia.

Povedal som "začiatok odpovede na", pretože pokračovanie v skutočnosti neexistuje. Ľudia, ktorí vytvorili a implementovali XP, mysleli aj na vyriešenie tohto problému. Keď sa pokúsili použiť XP, prekročili prah a vstúpili do neznáma. Keď sa vrátili, vyrozprávali svoj príbeh. Myšlienky, ktoré vyjadrili, sú nápisy umiestnené pozdĺž cesty: „Žijú tu draci“, „Po 15 km je dobrý výhľad“, „Tento úsek je nebezpečný, keď prší.“

Prepáčte, ale je čas, aby som išiel programovať.

Kent Beck, poradca série

Predslov

extrémne programovanie ( Extrémne programovanie,XP) identifikuje kódovanie ako kľúčovú a základnú aktivitu pri práci na softvérovom projekte. Toto môže byť nesprávne!

Myslím, že stojí za to zamyslieť sa nad mojimi skúsenosťami s vývojom softvéru. Pracujem v prostredí, kde je vyvíjaný produkt neustále vo funkčnom stave a zároveň sa na ňom neustále robia zmeny. Termín vydania ďalšej pracovnej verzie je strašne stlačený a zároveň nad tým všetkým visí obrovské technické riziko. V takomto prostredí je schopnosť korigovať kolegu umenie, bez ktorého sa nedá prežiť. Výmena informácií v rámci tímu aj medzi viacerými tímami, ktoré sú často geograficky oddelené, sa uskutočňuje pomocou kódu. Čítame kód, aby sme pochopili návrh nových alebo upravených rozhraní systémového softvéru. Životný cyklus a správanie zložitých objektov sa určuje pomocou testovacích prípadov, teda opäť pomocou kódu. Hlásenia problémov sú sprevádzané testovacími prípadmi demonštrujúcimi problém, opäť pomocou kódu. Nakoniec sme neustále zaneprázdnení zlepšovaním existujúceho kódu, aby bol výkonnejší, flexibilnejší a zrozumiteľnejší. Je zrejmé, že v takomto prostredí je vývoj softvéru takmer výlučne založený na kódovaní, ale zároveň sme schopní úspešne dokončiť projekty načas, takže tento prístup je celkom životaschopný.

Nepredpokladajte, že všetko, čo potrebujete na úspešnú implementáciu softvérového projektu, je bezohľadné, divoké programovanie. Vývoj softvéru je veľmi náročný a vývoj kvalitného softvéru a dokončenie práce načas je ešte náročnejšie. Aby prístup, ktorý som opísal, fungoval, musia sa dôsledne uplatňovať dôležité dodatočné pravidlá a techniky. Toto je miesto, kde Kent Beck začína svoju knihu o HR, ktorá vás núti zamyslieť sa.

Kent patril medzi vedúcich pracovníkov Tektronix, ktorí rozpoznali obrovský potenciál spojených programovacích techník pre vývoj zložitých inžinierskych aplikácií v prostredí Smalltalk. Spolu s Wardom Cunninghamom Kent inšpiroval vývoj programovania vzorov (nazývaného aj programovanie vzorov). programovanie vzorov, čo výrazne ovplyvnilo moju vlastnú kariéru. XP popisuje prístup k vývoju softvéru, ktorý kombinuje techniky používané mnohými úspešnými vývojármi, ktorí si preštudovali množstvo literatúry o organizácii práce programátorov a v praxi vyskúšali mnohé metódy a postupy na vývoj softvérového produktu. Podobne ako programovanie vzorov, aj XP vytvára súbor najefektívnejších techník, ako je testovanie softvérové moduly, programovanie párov a recyklácia kódu. V rámci XP sa tieto techniky kombinujú tak, aby sa navzájom dopĺňali a často kontrolovali. Hlavným účelom tejto knihy je hovoriť o interakcii a spoločnom používaní rôznych techník. Všetky programovacie techniky majú jeden cieľ – vytvoriť softvérový produkt s danou funkcionalitou do daného termínu. Veľmi úspešný proces Just In Time Software od OTI nie je XP in čistej forme medzi týmito dvoma prístupmi je však veľa spoločného.

Spolupracoval som s Kentom a používal som epizódy opísané v XP pri práci na malom, ale známom projekte s názvom JUnit. Jeho názory a prístupy k vývoju softvéru ma vždy prinútili zamyslieť sa nad tým, ako som ja osobne pracoval na softvérovom projekte. XP nepochybne spochybňuje mnohé z tradičných prístupov používaných v programovacom priemysle. Po prečítaní tejto knihy sa budete môcť sami rozhodnúť, či potrebujete pri svojej práci používať XP alebo nie.

Extrémne programovanie

O sérii XP

Povedal som "začiatok odpovede na", pretože pokračovanie v skutočnosti neexistuje. Ľudia, ktorí vytvorili a implementovali XP, mysleli aj na vyriešenie tohto problému. Keď sa pokúsili použiť XP, prekročili prah a vstúpili do neznáma. Keď sa vrátili, vyrozprávali svoj príbeh. Myšlienky, ktoré vyjadrili, sú nápisy umiestnené pozdĺž cesty: „Žijú tu draci“, „Po 15 km je dobrý výhľad“, „Tento úsek je nebezpečný, keď prší.“

Prepáčte, ale je čas, aby som išiel programovať.

Kent Beck, poradca série

Predslov

extrémne programovanie ( Extrémne programovanie,XP) identifikuje kódovanie ako kľúčovú a základnú aktivitu pri práci na softvérovom projekte. Toto môže byť nesprávne!

Nepredpokladajte, že všetko, čo potrebujete na úspešnú implementáciu softvérového projektu, je bezohľadné, divoké programovanie. Vývoj softvéru je veľmi náročný a vývoj kvalitného softvéru a dokončenie práce načas je ešte náročnejšie. Aby prístup, ktorý som opísal, fungoval, musia sa dôsledne uplatňovať dôležité dodatočné pravidlá a techniky. Toto je miesto, kde Kent Beck začína svoju knihu o HR, ktorá vás núti zamyslieť sa.

Kent patril medzi vedúcich pracovníkov Tektronix, ktorí rozpoznali obrovský potenciál spojených programovacích techník pre vývoj zložitých inžinierskych aplikácií v prostredí Smalltalk. Spolu s Wardom Cunninghamom Kent inšpiroval vývoj programovania vzorov (nazývaného aj programovanie vzorov). programovanie vzorov, čo výrazne ovplyvnilo moju vlastnú kariéru. XP popisuje prístup k vývoju softvéru, ktorý kombinuje techniky používané mnohými úspešnými vývojármi, ktorí si preštudovali množstvo literatúry o organizácii práce programátorov a v praxi vyskúšali mnohé metódy a postupy na vývoj softvérového produktu. Rovnako ako programovanie vzorov, XP vytvára súbor osvedčených postupov, ako je testovanie softvérových modulov, programovanie párov a prepracovanie kódu. V rámci XP sa tieto techniky kombinujú tak, aby sa navzájom dopĺňali a často kontrolovali. Hlavným účelom tejto knihy je hovoriť o interakcii a spoločnom používaní rôznych techník. Všetky programovacie techniky majú jeden cieľ – vytvoriť softvérový produkt s danou funkcionalitou do daného termínu. Veľmi úspešný proces Just In Time Software od OTI nie je čistý XP, ale medzi týmito dvoma prístupmi je veľa podobností.

Spolupracoval som s Kentom a používal som epizódy XP na malom, ale známom projekte s názvom JUnit. Jeho názory a prístupy k vývoju softvéru ma vždy prinútili zamyslieť sa nad tým, ako som ja osobne pracoval na softvérovom projekte. XP nepochybne spochybňuje mnohé z tradičných prístupov používaných v programovacom priemysle. Po prečítaní tejto knihy sa budete môcť sami rozhodnúť, či potrebujete pri svojej práci používať XP alebo nie.

Erich Gamma

Úvod

Táto kniha je o extrémnom programovaní ( Extrémne programovanie, XP). Extreme Programming je zjednodušená produkčná metodika pre malé a stredné tímy špecialistov vyvíjajúcich softvérový produkt v podmienkach nejasných alebo rýchlo sa meniacich požiadaviek. Táto kniha je navrhnutá tak, aby vám pomohla určiť, či je XP vhodný pre vašu situáciu.

Ak je kontrola kódu dobrá, potom budeme kód kontrolovať neustále (párové programovanie);

Ak je testovanie dobré, každý účastník projektu bude neustále testovať programový kód (testovanie jednotiek), dokonca aj zákazníci (funkčné testovanie);

Ak je dizajn dobrý, potom by mal byť dizajn neoddeliteľnou súčasťou každodennej práce každého z účastníkov projektu (prepracovanie kódu);

Ak je jednoduchosť dobrá, potom by sme mali udržiavať systém v najjednoduchšom dizajne, ktorý poskytuje aktuálnu požadovanú úroveň funkčnosti (najjednoduchšia vec, ktorá s najväčšou pravdepodobnosťou funguje); ak je architektúra dôležitá, potom každý z účastníkov projektu bude neustále pracovať na definovaní a revízii architektúry (metafory);

Ak je testovanie integrácie dôležité, potom je potrebné vyvíjaný systém niekoľkokrát denne zostaviť a otestovať (priebežná integrácia);

Ak sú malé iterácie dobré, musíte urobiť iterácie veľmi, veľmi malé - sekundy, minúty, možno hodiny, ale nie týždne a mesiace a v žiadnom prípade nie roky (hra na plánovanie).

Keď som sa prvýkrát rozhodol sformulovať podstatu XP pre seba, predstavil som si sadu gombíkov na ovládacom paneli. Každá rukoväť zodpovedala určitej technike, o ktorej, od jej vlastnej osobná skúsenosť Vedel som, že je to celkom efektívne. Každý gombík do určitej miery umožňoval použitie konkrétnej techniky: od 1 do 10. Skúsil som nastaviť všetky gombíky do maximálnej možnej polohy (10) a bol som prekvapený, keď som zistil, že celý súbor techník, ktoré som považoval, zostal stabilný a predvídateľný. a flexibilné.

XP generuje dve sady prísľubov:

XP sľubuje programátorom, že každý z nich bude pracovať na riešení skutočne dôležitých problémov každý pracovný deň. Každý z nich sa nikdy neocitne v ťažkej situácii sám. Každý z nich bude môcť urobiť všetko, čo je v jeho silách, aby bol vyvíjaný systém úspešný. Každý z nich sa bude môcť rozhodnúť presne v tej oblasti, v ktorej je kompetentný, a ak v niektorej oblasti nebude dostatočne kompetentný, nebude sa podieľať na rozhodovaní.

XP sľubuje zákazníkom a manažérom, že z každého týždňa práce na projekte získajú maximálnu možnú návratnosť. Každých pár týždňov budú môcť vidieť pokrok smerom k cieľom, ktoré si stanovili. Budú môcť zmeniť smerovanie projektu v polovici vývoja bez obáv z dodatočných mimoriadnych nákladov.

Stručne povedané, XP sľubuje zníženie projektového rizika, zlepšenie schopnosti reagovať na obchodné zmeny, zlepšenie projektovej produktivity a spríjemnenie procesu vývoja softvéru – to všetko súčasne. Nerobím si srandu, prestaň sa smiať. Stačí si prečítať túto knihu a sami uvidíte, či som blázon.

Táto kniha

Táto kniha hovorí o veciach súvisiacich s technikou XP – jej koreňmi, filozofiou, rôznymi príbehmi a mýtmi. Kniha je navrhnutá tak, aby vám pomohla urobiť informované rozhodnutie o tom, či vo svojom počítači používať XP vlastný projekt. Ak sa po prečítaní tejto knihy rozhodnete nepoužiť XP vo svojom projekte, budem považovať hlavný cieľ za dosiahnutý rovnakým spôsobom, ako keby ste sa po prečítaní tejto knihy rozhodli, že XP je to, čo potrebujete. Druhým účelom knihy je pomôcť tým z vás, ktorí už XP používajú. Po prečítaní knihy budú takíto čitatelia schopní lepšie pochopiť túto techniku.

Táto kniha neposkytuje presné pokyny, ako presne by sa mal proces extrémneho programovania vykonávať. Neuvidíte v ňom veľa príkladov, algoritmov či programátorských príbehov. Ak chcete získať toto všetko, môžete hľadať na internete, porozprávať sa s niektorými účastníkmi projektov, počkať, kým sa objavia knihy na túto tému, alebo si takýto materiál vytvoriť sami.

Budúci osud disciplíny vývoja softvéru XP, ktorú som opísal, leží v rukách skupiny ľudí (možno ste jedným z nich), ktorí sú nespokojní s existujúcim tento moment tradičné metódy organizácie práce programátorov. potrebuješ najlepšia cesta vývoj softvéru, chcete rozvíjať produktívnejšie a priateľskejšie vzťahy so svojimi zákazníkmi, chcete, aby programátori pracujúci pod vaším vedením boli šťastnejší, lojálnejší a produktívnejší. Skrátka, chcete získať výraznú výhodu a nebojíte sa použiť nové nápady na získanie tejto výhody. Predtým, ako zariskujete, sa však chcete uistiť, že aspoň nie ste úplný hlupák.

XP vám dáva pokyn robiť prácu úplne iným spôsobom, ako ste zvyknutí. V niektorých prípadoch sú odporúčania XP úplne v rozpore so všeobecne uznávanými normami. Zapnuté tento moment Verím, že XP budú môcť používať iba tí, ktorí majú presvedčivé dôvody zmeniť existujúci poriadok vecí. Ak však takéto dôvody existujú, môžete začať používať XP práve teraz. Túto knihu som napísal, aby ste sa o týchto dôvodoch dozvedeli viac.

čo je XP?

čo je XP? XP je zjednodušený, efektívny, flexibilný, predvídateľný, vedecky podložený a veľmi príjemný spôsob vývoja softvéru, ktorý obsahuje nízky level riziko. XP sa líši od ostatných metód nasledujúcimi spôsobmi.

Použitím extrémne krátkych vývojových cyklov ponúka XP rýchle, skutočné a vždy zapnuté spätná väzba.

XP používa prírastkové plánovanie, ktorého výsledkom je pomerne rýchly vznik celkového plánu projektu, ale je zrejmé, že tento plán sa vyvíja počas životnosti projektu.

XP využíva flexibilný harmonogram implementácie tej či onej funkcionality, ktorý zlepšuje reakciu na meniaci sa charakter podnikania a s tým súvisiace meniace sa požiadavky zákazníkov.

XP je založený na automatizovaných testoch vyvinutých programátormi aj zákazníkmi. Vďaka týmto testom je možné sledovať vývojový proces, zabezpečiť správny vývoj systému a promptne odhaľovať chyby existujúce v systéme.

XP je založený na ústnej komunikácii, testoch a zdrojovom kóde. Tieto tri nástroje sa používajú na výmenu informácií o štruktúre a správaní systému.

XP je založený na vyvíjajúcom sa dizajnovom procese, ktorý pokračuje, kým samotný systém existuje.

XP je založený na úzkej interakcii medzi programátormi s najbežnejšími zručnosťami a schopnosťami.

XP je založený na technikách, ktoré uspokojujú ako krátkodobé inštinkty jednotlivých programátorov, tak aj dlhodobé záujmy celého projektu.

XP je disciplína vývoja softvéru. Toto je disciplína, pretože v rámci XP existujú určité veci, ktoré musíte urobiť, ak chcete používať XP. Nemali by ste si vyberať, či budete alebo nebudete písať testy, pretože ak to neurobíte, programovanie, ktoré robíte, nie je extrémne: koniec diskusie.

Metodika XP je navrhnutá tak, aby pracovala na projektoch, na ktorých môžu pracovať dvaja až desiati programátori, ktoré nie sú obmedzené pevnými hranicami existujúceho počítačového prostredia a v ktorých je možné vykonať všetky potrebné testovacie práce v priebehu jedného dňa.

XP desí alebo dráždi niektorých ľudí, ktorí sa s touto technikou stretávajú prvýkrát. Avšak ani jedna myšlienka, ktorá je základom XP, nie je nová. Metodika HR je v istom zmysle konzervatívna – všetky techniky používané v jej rámci sú odskúšané desaťročiami (s ohľadom na stratégiu implementácie) a dokonca storočiami (s ohľadom na stratégiu riadenia) praxou.

Inovácie v XP zahŕňajú nasledujúce funkcie:

Všetky tieto dlho známe techniky sú zhromaždené pod jednou strechou;

Intenzita, s akou sa tieto techniky zavádzajú do každodennej práce, je dohnaná do extrému;

Použité techniky sa navzájom podporujú v maximálnej možnej miere.

Primeranosť

Vo svojich dielach Lesní ľudia a hora (People Mountain Peoples) Antropológ Colin Turnbull opisuje dve veľmi odlišné spoločnosti. V horách sú zdroje potrebné na život vzácne a ľudia sú vždy na pokraji hladu. Kultúra, ktorá v takýchto podmienkach vznikla, vyzerá hrôzostrašne. Matky opúšťajú svoje deti, aby prežili samy seba. Jedlo môže spôsobiť smrť. Krutosť, sodomia a zrada sú bežné a každodenné.

Na rozdiel od hôr je les bohatý na zdroje. Na to, aby si človek zabezpečil jedlo na celý deň, potrebuje stráviť asi pol hodiny. Lesná kultúra je spätným odrazom horskej kultúry. Dospelí sa podieľajú na výchove a výchove spoločných detí, ktoré vyrastajú v láske a starostlivosti, kým sa nestanú dostatočne kompetentnými postarať sa o seba. Ak jeden človek náhodou zabije druhého (úmyselnú vraždu títo ľudia nepoznajú), je vylúčený zo spoločnosti. V tomto prípade sa však vyhnanec jednoducho musí stiahnuť do lesa a stráviť tam niekoľko mesiacov, a aj tak mu niektorí členovia kmeňa nosia jedlo a dary.

XP je pokus o odpoveď na otázku: Ako by ste vy osobne programovali, keby ste mali dostatok času? V skutočnosti nemáte žiadny čas navyše, pretože programovanie je predsa biznis. V každom biznise vyhráva ten, kto robí prácu rýchlejšie. Ak by ste však mali čas, pravdepodobne by ste venovali pozornosť vývoju testov; pravdepodobne by ste znova prepracovali systém, ak by ste dospeli k záveru, že je to potrebné; asi by si viac komunikoval s kolegami programatormi, aj so zakaznikom.

Tento pocit dostatku sa zdá byť humánnejší, na rozdiel od situácií, keď sa programátori snažia zo všetkých síl dodržať daný časový rámec, meškajú s plánom a nedokážu dokončiť veľké množstvo mimoriadne dôležitej práce len preto, aby projekt dodali včas. Haste bráni programátorom naplno prejaviť svoj talent a užívať si prácu. Keď však začnete študovať XP, mali by ste pochopiť, že cítiť dostatok je tiež dobrý biznis. Pocit dostatku sa stáva zdrojom efektívnosti, rovnako ako pocit nedostatku vytvára neúspechy v práci, čo vedie k poruchám a nižšej kvalite a v konečnom dôsledku k nižšej produktivite.

Náčrt knihy

Kniha je napísaná tak, ako keby sme spolu vytvárali novú disciplínu vývoja softvéru. Začneme skúmaním nášho základného chápania vývoja softvéru. Potom vlastne vytvárame novú disciplínu. Potom skúmame dôsledky toho, čo sme vytvorili – ako sa to dá implementovať a použiť v praxi, kedy by sa to nemalo používať a aké príležitosti to predstavuje pre podniky.

Kniha je rozdelená do troch častí.

Problém: v kapitolách začínajúcich od Riziko: hlavný problém a končí Spať k základom, definuje sa problém, ktorý sa extrémne programovanie snaží vyriešiť, a stanovia sa kritériá, podľa ktorých možno posúdiť kvalitu riešenia. V tejto časti získate všeobecnú predstavu o metodológii extrémneho programovania.

Riešenie: v kapitolách začínajúcich od Krátka recenzia a končí Stratégia testovania, abstraktné myšlienky prezentované v prvej časti knihy sú transformované do súboru odborne špecifických techník. Táto kapitola neobsahuje žiadne informácie o tom, ako presne môžete použiť opísané techniky v praxi. Namiesto toho ide o všeobecnú formu každej techniky. Keď diskutujem o každej technike, dávam ju do súvislosti s problémami a princípmi, o ktorých sa hovorí v prvej časti knihy.

implementácia XP: v kapitolách začínajúcich od implementácia XP a končí XP v práci, diskutuje sa o mnohých otázkach súvisiacich s implementáciou XP - ako by sa mal XP implementovať, čo by sa malo očakávať od rôznych ľudí zapojených do projektu XP, ako vnímajú XP ľudia vo svete podnikania.

Poďakovanie

K čitateľom sa prihováram v prvej osobe nie preto, že kniha prezentuje moje vlastné myšlienky, ale preto, že vám hovorím o svojich vlastných vnímaniach týchto myšlienok. Väčšina techník používaných v XP je taká stará ako všetko programovanie.

Ward Cunningham je mojím primárnym zdrojom materiálu v tejto knihe. Každopádne, posledných pätnásť rokov som sa len snažil vysvetliť ostatným ľuďom, čo Ward prakticky robil už dlho. Ďakujem aj Ronovi Jeffriesovi, že to tiež vyskúšal a potom to urobil oveľa lepším. Ďakujem Martinovi Fowlerovi za to, že to všetko vysvetlil jednoduchým, jemným jazykom a bez toho, aby ste zruinovali banku. Ďakujem Erichovi Gamovi za dlhé rozhovory spojené s rozjímaním o labutiach v Lymme a tiež za to, že mi nedovolili odísť so zlými myšlienkami v hlave. A samozrejme, nič z toho by sa v mojom živote nestalo, keby som nemal vzor ako môj otec Doug Beck, ktorý si svoje programátorské schopnosti zdokonaľoval dlhé roky.

Ďakujem tímu C3 v spoločnosti Chrysler za to, že ma sprevádzal mojím výskumom. A špeciálne ďakujeme našim manažérom Sue Unger a Ronovi Savageovi, že mali odvahu nás vyskúšať.

Ďakujem spoločnosti Daedalos Consulting za pomoc pri písaní tejto knihy.

Cena šampióna za prezeranie materiálu patrí Paulovi Chisholmovi za jeho výdatné, stručné, pedantné a často priam otravné komentáre. Bez jeho pomoci táto kniha nebude z polovice taká populárna.

Veľmi sa mi páčilo komunikovať so všetkými, ktorí to realizovali Náhľadčo som napísal.

Ich práca mi bola veľkou pomocou. Nenachádzam slová vďačnosti za to, že mali trpezlivosť prečítať všetky tieto prózy až do konca, pretože mnohé z nich boli napísané v cudzom jazyku.

Vďaka (bez uvedenia poradia, v akom som od nich dostal komentáre) Gregovi Hutchinsonovi, Massimo Arnoldi, Dave Cleal, Sames Schuster, Don Wells, Josha Kerievsky, Thorsten Dittmar, Moritz Becker, Daniel Gubler, Christoph Henrici, Thomas Zang, Dierk Koenig, Miroslav Miroslav Novák, 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 a Matthias Ressel.

Od vydavateľa

Svoje pripomienky, návrhy, otázky posielajte na: Email [e-mail chránený](Vydavateľstvo Peter, počítačové vydanie).

Radi by sme počuli váš názor!

Všetky zdrojové texty uvedené v knihe nájdete na http://www.piter.com/download.

Na stránke vydavateľstva http://www.piter.com nájdete podrobné informácie o našich knihách.

Problém

Táto časť knihy nastavuje scénu, na ktorej má vzniknúť extrémne programovanie. Opisuje rôzne aspekty problému, ktorý sa má vyriešiť vytvorením novej disciplíny softvérového inžinierstva.

Táto časť rozoberá základné predpoklady, ktoré musíme zvážiť pri výbere postupov vývoja softvéru – metafora riadenia auta, štyri významy, princípy vytvorené z týchto významov a činnosti, ktoré je potrebné štruktúrovať v rámci novej disciplíny vývoja softvéru.

Riziko: hlavný problém

Existujúce disciplíny vývoja softvéru nefungujú a neprinášajú želaný ekonomický efekt. Tento problém má obrovský ekonomický a humanitárny význam. Potrebujeme nový spôsob vývoja softvéru.

Hlavným problémom pri vývoji softvéru je riziko.

Tu je niekoľko príkladov rizika.

Posun grafu– príde deň, kedy má byť vykonaná práca, a vy ste nútení informovať zákazníka, že vyvíjaný systém bude pripravený až za šesť mesiacov.

Uzavretie projektu– po niekoľkých posunoch harmonogramu a posunutí termínu dodania je projekt uzavretý bez toho, aby bol čo i len privedený do štádia testovania v pracovných podmienkach.

Systém stráca svoju užitočnosť– vyvinutý softvér sa úspešne nainštaluje v reálnom produkčnom pracovnom prostredí, ale po niekoľkých rokoch používania sa náklady na jeho zmeny a/alebo počet defektov zvýšia natoľko, že je lacnejšie nahradiť systém novým rozvoj.

– softvérový systém je nainštalovaný v reálnom produkčnom pracovnom prostredí, ale množstvo defektov a nedostatkov je také veľké, že sa systém nepoužíva.

– Softvérový systém je nainštalovaný v reálnom produkčnom pracovnom prostredí, ale ukazuje sa, že v skutočnosti nerieši obchodný problém, ktorý mal pôvodne riešiť.

Meniaci sa charakter podnikania– Softvérový systém sa inštaluje v reálnom produkčnom pracovnom prostredí, ale za posledných šesť mesiacov sa problém, ktorý mal systém vyriešiť, stal irelevantným a podnik namiesto toho čelí novému, ešte vážnejšiemu problému.

Nedostatok príležitostí– Softvérový systém má veľa potenciálne zaujímavých funkcií, z ktorých každá bola radosť programovať, no ukazuje sa, že žiadna z týchto funkcií neprináša zákazníkovi veľký úžitok.

Personálna fluktuácia– všetko do dvoch rokov práce dobrí programátori ktorí na projekte pracovali, jeden po druhom nenávidel vývoj softvérový systém a odišiel do inej práce.

Na stránkach tejto knihy sa dočítate o extrémnom programovaní ( Extrémne programovanie, XP) je disciplína vývoja softvéru, ktorá je zameraná na znižovanie rizika na všetkých úrovniach procesu vývoja. XP pomáha výrazne zvyšovať produktivitu a zlepšovať kvalitu vyvíjaných programov, navyše je to veľmi zábavná prax, ktorá prináša veľa potešenia všetkým jej účastníkom.

Ako XP znižuje riziká uvedené vyššie?

Posun grafu– XP odporúča použiť veľmi krátka doba vydanie každej nasledujúcej verzie. Predpokladá sa, že každá nasledujúca hotová verzia systému je vyvinutá maximálne do niekoľkých mesiacov. Rozsah prác v rámci každej verzie je teda obmedzený, čo znamená, že ak dôjde k posunu, je menej výrazný. Každé vydanie obsahuje viacero iterácií funkcií požadovaných zákazníkom, pričom vývoj každej iterácie trvá jeden až štyri týždne. Zákazníkovi je tak zabezpečená flexibilná a citlivá spätná väzba, vďaka ktorej získa predstavu o aktuálnom postupe prác. V rámci každej iterácie sa uskutočňuje plánovanie v súlade s XP v zmysle niekoľkých úloh, ktoré je potrebné vyriešiť, aby ste získali ďalšiu iteráciu. Každá úloha je pridelená na jeden až tri dni. Výsledkom je, že tím dokáže odhaliť a opraviť problémy aj počas iterácie. Napokon, XP znamená, že príležitosti s najvyššia priorita budú implementované ako prvé. Všetky funkcie, ktoré nebolo možné implementovať v tejto ďalšej verzii softvérového produktu, majú teda nižšiu prioritu.

Uzavretie projektu– v rámci XP si zákazník musí určiť najmenšiu akceptovateľnú sadu schopností, ktorú by mala mať minimálna fungujúca verzia programu, ktorá má zmysel z hľadiska riešenia obchodných problémov. Programátori teda budú musieť vynaložiť minimálne úsilie, aby zabezpečili, že zákazník pochopí, či tento projekt potrebuje alebo nie.

Systém stráca svoju užitočnosť– v rámci XP sa vytvára a udržiava obrovské množstvo testov, ktoré sa spúšťajú a reštartujú po akejkoľvek zmene v systéme (niekoľkokrát denne), vďaka tomu je možné starostlivo sledovať kvalitu vyvíjaného programu. XP udržiava systém neustále vo výbornom stave. Chyby sa jednoducho nesmú hromadiť.

Množstvo chýb a nedostatkov– v rámci XP testujú vyvíjaný systém tak programátori, ktorí vytvárajú testy pre každú jednotlivú vyvíjanú funkciu, ako aj zákazníci, ktorí vytvárajú testy pre každú jednotlivú implementovanú vlastnosť systému.

Nesúlad s riešeným problémom– v rámci XP je zákazník neoddeliteľnou súčasťou tímu, ktorý na projekte pracuje. Špecifikácia projektu je neustále revidovaná počas celej doby trvania projektu, vďaka čomu sa akékoľvek spresnenia a objavy, ktoré zákazník oznámi vývojovému tímu, okamžite premietnu do vyvíjaného programu.

Extrémne programovanie: testom riadený vývoj

Venované Cindy: krídla mojej duše

Vydavateľské práva boli získané na základe dohody s Addison-Wesley Longman. Všetky práva vyhradené. Žiadna časť tejto knihy nesmie byť reprodukovaná v žiadnej forme bez písomného súhlasu držiteľov autorských práv.

Informácie obsiahnuté v tejto knihe boli získané zo zdrojov, ktoré vydavateľ považuje za spoľahlivé. S prihliadnutím na možné ľudské alebo technické chyby však vydavateľ nemôže zaručiť absolútnu presnosť a úplnosť poskytnutých informácií a nezodpovedá za prípadné chyby spojené s použitím knihy.

ISBN 978-0321146533 anglicky

ISBN 978-5-496-02570-6

Predslov

Čistý kód, ktorý funguje„čistý kód, ktorý funguje“, táto krátka, ale zmysluplná fráza, ktorú vytvoril Ron Jeffries, zahŕňa celý význam testom riadeného vývoja (TDD). Čistý kód, ktorý funguje, je cieľom, o ktorý sa oplatí usilovať, pretože

Toto je predvídateľný spôsob vývoja programov. Viete, kedy možno prácu považovať za dokončenú bez obáv z dlhého radu chýb;

Dáva vám šancu naučiť sa lekcie, ktoré kód učí. Ak použijete prvý nápad, ktorý vám príde na myseľ, nebudete mať šancu zrealizovať druhý, lepší nápad;

Zlepšuje život používateľov vašich programov;

Umožňuje vašim kolegom počítať s vami a vy s nimi;

Je príjemnejšie písať kód takto.

Ale ako získate čistý kód, ktorý funguje? Mnoho síl nám bráni získať čistý kód a niekedy ani nedokážeme získať kód, ktorý jednoducho funguje. Aby sme sa zbavili mnohých problémov, vyvinieme kód na základe automatizovaného testovania. Tento štýl programovania sa nazýva testom riadený vývoj. Podľa tejto techniky

Nový kód sa zapíše až po napísaní automatizovaného testu, ktorý zlyhá;

Akákoľvek duplicita je eliminovaná.

Dva jednoduché pravidlá, nieje to? Vytvárajú však zložité individuálne a skupinové správanie s mnohými technickými dôsledkami:

Počas procesu návrhu neustále spúšťame kód a získavame predstavu o tom, ako funguje, čo nám pomáha robiť správne rozhodnutia;

Píšeme si vlastné testy, pretože nemôžeme čakať, kým za nás testy napíše niekto iný;

Naše vývojové prostredie musí rýchlo reagovať na malé úpravy kódu;

Návrh programu by mal byť založený na použití mnohých samostatných, voľne spojených komponentov, aby sa kód ľahšie testoval.

Spomínané dve pravidlá TDD určujú poradie krokov programovania.

1. Červená - Napíšte malý test, ktorý nefunguje a možno sa ani nezloží.

2. Zelená - urobte test čo najrýchlejšie, bez obáv o správnosť návrhu a čistotu kódu. Napíšte len toľko kódu, aby test fungoval.

3. Refaktoring – eliminuje duplicitu z písaného kódu.

Červená – zelená – refaktoring je mantrou TDD.

Ak predpokladáme, že tento štýl programovania je možný, môžeme predpokladať, že vďaka jeho použitiu bude kód obsahovať podstatne menej defektov, navyše účel práce bude jasný každému, kto sa na nej podieľa. Ak áno, potom vývoj iba kódu potrebného na úspešné absolvovanie testov má aj sociálne dôsledky:

Ak je hustota defektov dostatočne nízka, tím zabezpečenia kvality (QA) bude schopný prejsť od reagovania na chyby k predchádzaniu im;

S menším počtom nepríjemných prekvapení budú projektoví manažéri schopní presnejšie odhadnúť mzdové náklady a zapojiť zákazníkov do procesu vývoja;

Ak sú témy technických diskusií jasne definované, programátori budú môcť medzi sebou neustále interagovať, a nie raz za deň alebo raz za týždeň;

Opäť, s dostatočne nízkou hustotou defektov, budeme môcť každý deň vyrábať integrovaný pracovný produkt s novou funkcionalitou, ktorá nám umožní vstúpiť do úplne nového typu obchodného vzťahu s našimi zákazníkmi.

Myšlienka je teda jednoduchá, ale aký je náš záujem? Prečo by mal programátor prevziať dodatočnú zodpovednosť za písanie automatických testov? Prečo by sa programátor posúval vpred malými krokmi, keď je jeho mozog schopný premýšľať cez oveľa zložitejšiu štruktúru návrhu? Statočnosť.

Statočnosť

TDD je spôsob zvládania strachu v procese programovania. Nemyslím tým strach, že spadnete zo stoličky alebo strach byť pred šéfom. Mám na mysli strach čeliť problému „tak ťažkému, že zatiaľ netuším, ako ho vyriešiť“. Bolesť je, keď nám príroda hovorí: "Prestaň!", a strach je, keď nám príroda hovorí: "Buď opatrný!" Opatrnosť nie je vôbec zlá vec, ale okrem svojich výhod má na nás strach aj niektoré negatívne účinky:

Strach nás núti premýšľať dopredu a starostlivo o tom, k čomu môže tá alebo oná akcia viesť;

Strach nás núti komunikovať menej;

Strach v nás vyvoláva strach z recenzií našej práce;

Strach nás robí podráždenými.

Nič z toho nie je užitočné pre proces programovania, najmä ak na tom pracujete náročná úloha. Stojíme teda pred otázkou, ako sa dostať z ťažkej situácie a

Nesnažte sa predpovedať budúcnosť, ale okamžite začnite s praktickým štúdiom problému;

Neizolujte sa od zvyšku sveta, ale zvýšte úroveň komunikácie;

Nevyhýbajte sa odpovediam, ale naopak vytvorte spoľahlivú spätnú väzbu a s jej pomocou pozorne sledujte výsledky svojich činov;

(s podráždením sa musíte vyrovnať sami).

Prirovnajme programovanie k zdvíhaniu vedra zo studne. Vedro sa naplní vodou, otočíte pákou, naviniete reťaz okolo obojku a zdvihnete vedro nahor. Ak je vedro malé, dobre poslúži bežná, voľne sa otáčajúca brána. Ale ak je vedro veľké a ťažké, budete unavení skôr, ako ho zdvihnete. Aby bolo možné medzi otáčkami páky odpočívať, je potrebný západkový mechanizmus, ktorý umožní páku uzamknúť. Čím je vedro ťažšie, tým rýchlejšie by mali nasledovať zuby na račni.

Testy v TDD sú ako zuby na račni. Po vykonaní testu vieme, že test teraz funguje, teraz a navždy. Sme o krok bližšie k dokončeniu, ako sme boli pred spustením testu. Potom spracujeme druhý test, potom tretí, štvrtý atď. Čím zložitejší je problém, ktorému programátor čelí, tým menej funkčnosť by mal pokrývať každý test.

Čitatelia knihy Extrémne programovanie vysvetliť Možno ste si všimli rozdiel v tóne medzi Extreme Programming (XP) a Test-Driven Development (TDD). Na rozdiel od XP nie je technika TDD absolútna. XP hovorí: „Aby ste sa pohli vpred, musíte zvládnuť toto a tamto“. TDD je menej špecifická technika. TDD predpokladá, že medzi rozhodovaním a výsledkami existuje určitý interval a poskytuje nástroje na riadenie dĺžky tohto intervalu. „Čo keby som strávil týždeň navrhovaním algoritmu na papieri a potom písaním kódu pomocou prístupu test-first? Bude to v súlade s TDD?" Samozrejme, že bude. Poznáte veľkosť intervalu medzi rozhodnutím a hodnotením výsledkov a vedome tento interval riadite.

Väčšina ľudí, ktorí zvládli TDD, hovorí, že ich programovacie postupy sa zmenili k lepšiemu. Infikovaný testami(test infikovaný) – toto je definícia, s ktorou prišiel Erich Gamma, aby opísal túto zmenu. Akonáhle zvládnete TDD, zistíte, že píšete podstatne viac testov ako predtým a posúvate sa vpred malými krokmi, ktoré by sa vám predtým zdali zbytočné. Na druhej strane, niektorí programátori, ktorí sa oboznámili s TDD, sa rozhodnú vrátiť k starým praktikám a vyhradia si TDD pre špeciálne prípady, keď konvenčné programovanie nevedie k požadovanému pokroku.

Určite existujú problémy, ktoré sa (aspoň v súčasnosti) nedajú vyriešiť samotnými testami. TDD predovšetkým neumožňuje mechanicky demonštrovať primeranosť vyvinutého kódu z hľadiska bezpečnosti dát a spoľahlivosti paralelných operácií. Bezpečnosť je samozrejme založená na kóde, ktorý musí byť bez chýb, ale je tiež založená na ľudskej účasti na postupoch ochrany údajov. Jemné problémy so súbežnosťou nemožno s istotou reprodukovať jednoduchým spustením nejakého kódu.