Kent Beck - extrémní programování. Vývoj prostřednictvím testování

Žánr:

Série:
Věková omezení: +
Jazyk:
Originální jazyk:
Překladatel (y):
Vydavatel:
Město publikace: Petrohrad
Rok publikování:
ISBN: 978-5-496-02570-6 Velikost: 382 kb.

Právo držitelé!

Předložený fragment práce je zveřejněn v koordinaci s distributorem právního obsahu LLC "litrů" (ne více než 20% zdrojového textu). Pokud si myslíte, že umístění materiálu porušuje něčí práva.

Čtenáři!

Zaplaceno, ale nevíte, co dělat dál?

Pozornost! Stáhnete si excerpt povolený zákonem a správným držitelem (ne více než 20% textu).
Po přečtení budete požádáni, abyste šli na stránku správného držitele a zakoupili plnou verzi práce.

Popis knihy

Vrátit slavný bestseller. Elegantní, flexibilní a čistý kód, který je snadno ovladatelný, který funguje správně a které nezvýší své tvůrce nepříjemných překvapení. Je to opravdu možné? Pro dosažení cíle zkuste testovat program ještě před jeho napsáním. Je to takový paradoxní nápad, který je založen na TDD techniku \u200b\u200b(test-řízený vývoj - vývoj založený na testování). Nesmysl? Nespěchejte, abyste provedli brzy závěry. Vzhledem k použití TDD na příkladu vývoje reálného programového kódu, autor demonstruje jednoduchost a moc této techniky. Kniha obsahuje dva programové projekty, úplně a plně implementovány pomocí TDD. Pro zvážení příkladů, rozsáhlý katalog technik v TDD stylu, stejně jako vzory a refaktorování související s TDD. Kniha bude užitečná pro každý programátor, který si přeje zlepšit výkon vaší práce a užívat si programování.

Poslední dojem z knihy

Sharersharpened:
16-12-2018, 02:17

Před čtením této knihy jsem se snažil psát testy na článcích, které jsem četl, ale jen s ní začal dobře.

Četl jsem dvakrát. První čas číst.

Nic nepochopil. Druhý čas jsem napsal kód v průběhu čtení knihy a pak konečně přišlo ke mně, co dělat, co a co je nejdůležitější - cítil jsem svůj krok, ke kterému mohu změnit kód a zároveň bych ne ztratit kontrolu. Byl jsem spokojen s druhou kapitolou, kde spolu s autem napsal můj systém modulárního testování na Pythonu, ten pocit byl, jako kdybyste dělali operaci ve svém vlastním mozku (vlastně, toto srovnání byl autor sám a autor sám) - Jeden neopatrný pohyb sám a nefunguje, musíte přesunout velmi malé kroky. Četl jsem třetí kapitolu selektivně, možná jednou jsem četl.

Otáčet se

⬇ Jiné komentáře

Tato kniha je o extrémní programování. Extrémní programování, často označované zkratkou "XP" - Jedná se o zjednodušenou metodu organizace výroby pro malé a střední developerské týmy softwarový produkt V podmínkách nejasných nebo rychle se měnících požadavků. Tato kniha je navržena tak, aby vám pomohla zjistit, zda je použití XP odůvodněno ve vaší situaci ...

O řadě XP

Extrémní programování (extrémní programování), často označeno zkratkou XP, je vývojová disciplína software a podnikání v oblasti vytváření softwaru, což je zaměřeno úsilí obou stran (programátorů a podnikatelů) o společných, plně dosažitelných účelech. Týmy pomocí XP produkují vysoce kvalitní software s velmi vysokou rychlostí. Techniky, které jsou součástí disciplíny XP popsané v této knize, jsou vybrány v důsledku skutečnosti, že jsou založeny na lidské tvořivosti a přijetí skutečnosti, že osoba je nestabilní a náchylná k chybě.

XP je často reprezentován jako soubor technik, ale samotný HP není cílovou čarou. Nemusíte být lepší a lépe cvičit a vyvíjet XP, abyste získali na konci tohoto procesu dlouho očekávaná zlatá hvězda. Naopak XP je startovní řádek. XR vyvolává otázku: "Jak minimální může být naše úsilí v pořádku, abychom mohli pokračovat v produkci vysoce kvalitního softwaru?"

Začátek odpovědi na otázku zní takto: Pokud chceme rozvíjet vysoce kvalitní programy bez zmatků a zmatků, musíme být dokončeny zcela a plně implementovat v našem týmu několik technik, které budeme plně používat. Pokud tyto techniky používáme na polovinu, budou problémy zůstat a rozhodnout, že bude nutné přistoupit k použití technik naplno. Pokud se v průběhu času omezujeme na poloroz rozměry, pleteme tolik, že nemůžeme pochopit, že je to hlavní věc, která je vytvořena pracujícími programátorů, vzniká pro programování.

Řekl jsem "Začátek odpovědi na" Vzhledem k tomu, že pokračování ve skutečnosti neexistuje. Lidé, kteří vytvořili a představili XP, také přemýšleli o rozhodnutí tohoto problému. Snažil se používat XP, vstoupili přes prahovou hodnotu a navštívili nezmapovanou. Vrácení, řekli svůj příběh. Myšlenky uvedené je ukazatele umístěné podél silnice: "Draci žijí zde," "Otevře se 15 km dobrý výhled"," Tento pozemek je nebezpečný během deště. "

Omlouvám se, ale je čas, abych se naprogramoval.

Předmluva

Extrémní programování (

extrémní programování

XP) Definuje kódování jako klíčové a základní aktivity při práci na softwarovém projektu. Je možné, že je to špatné!

Myslím, že stojí za to si pamatovat své vlastní zkušenosti s vývojovým softwarem. Pracuji v médiu, kde se vyvíjen produkt, je neustále v pracovní podmínkyA zároveň se do něj neustále zavádějí změny. Termíny pro vydání příští funkční verze jsou monstrózně stlačeny a zároveň existuje obrovské technické riziko. V podobném prostředí je schopnost opravit váš spolupracovník umění, bez nichž není přežil. Sdílení informací uvnitř nějakého týmu i mezi několika příkazy, které jsou často oddělené geograficky, se provádí pomocí kódu. Četli jsme kód, abychom pochopili zařízení nových nebo modifikovaných systémových softwarových rozhraní. Životní cyklus a chování komplexní objekty Definováno pomocí zkušebních případů, to je opět s kódy. Zprávy o nových problémech jsou doprovázeny testovacími případy, které ukazují problém, kód se znovu používá. Konečně jsme neustále zapojeni do zlepšování stávajícího kodexu, což je produktivnější, pružnější, srozumitelnější. Samozřejmě, v takových podmínkách je vývoj softwarového produktu téměř zcela založen na kódování, ale zároveň můžeme úspěšně doplňovat projekty podle času, takže tento přístup docela životaschopný.

Neměli bychom dospět k závěru, že vše, co potřebujete pro úspěšnou implementaci programového projektu, je rejocentní divoké programování. Vývoj software je velmi obtížný, ale rozvíjet vysoce kvalitní software a zároveň dokončené práce včas - ještě obtížnější. Aby byl přístup popsaný mne popsán, je nutné důsledně aplikovat důležitá dodatečná pravidla a techniky. Je to z toho, že Kent Beck (Kent Beck) začíná svou pozitivní knihu na XP.

Spolupracoval jsem s Kentem a použil jsem epizody popsané v rámci XP při práci na malém, ale nevyžádaném projektu JUIT

Úvod

Tato kniha o extrémním programování (

extrémní programování

XP). Extrémní programování je zjednodušená metoda organizace výroby pro malé a střední týmy specialistů zapojených do vývoje softwarového produktu v podmínkách nejasných nebo rychle se měnících požadavků. Tato kniha je navržena tak, aby pomohla určit, zda je použití XP odůvodněno ve vaší situaci.

Pro mnoho XP vypadá jako soubor poměrně přijatelných a odůvodněných z hlediska zdravého rozumu metod organizace práce. Proč se programování v souladu s technikami XP nazývá extrémní? Faktem je, že XP přináší použití mnoha obecně přijatých a široce používaných programových principů na extrémní úrovni.

Pokud je revize kódu dobrá, znamená to, že kód budeme neustále revidovat (ve dvojicích);

Testování? funkční testování);

ERSEE DESIGN je dobrý, znamená to, že konstrukce musí být součástí každodenní práce každého z účastníků projektu (recyklace kódu);

Extrémní programování

Věnuje se mému otci a já děkuji Cindy (Cindee Andres), moje žena a partnera, za náročné, že jí nevěnuji pozornost a napsal. Díky Bethany, Lincoln (Lincoln), Forrest (Forrest) a za to, že mě nevrátím a poskytl mi napsat.

O řadě XP

Extrémní programování (extrémní programování), často označováno zkratkou XP, je disciplínou vývoje softwaru a podnikání v oblasti vytváření softwarových produktů, což je zaměřeno úsilí obou stran (programátorů a podnikatelů) o společných, plně dosažitelných účelech. Týmy pomocí XP produkují vysoce kvalitní software s velmi vysokou rychlostí. Techniky, které jsou součástí disciplíny XP popsané v této knize, jsou vybrány v důsledku skutečnosti, že jsou založeny na lidské tvořivosti a přijetí skutečnosti, že osoba je nestabilní a náchylná k chybě.

Řekl jsem "Začátek odpovědi na" Vzhledem k tomu, že pokračování ve skutečnosti neexistuje. Lidé, kteří vytvořili a představili XP, také přemýšleli o rozhodnutí tohoto problému. Snažil se používat XP, vstoupili přes prahovou hodnotu a navštívili nezmapovanou. Vrácení, řekli svůj příběh. Myšlenky uvedené nimi jsou ukazatele umístěny podél silnice: "Draci žijí tady," "15 km otevírá dobrý výhled," toto místo je nebezpečné během deště. "

Omlouvám se, ale je čas, abych se naprogramoval.

Kent Beck, Série konzultant

Předmluva

Extrémní programování ( extrémní programování, XP) Definuje kódování klíčových a základních činností při práci na projektu Program. Je možné, že je to špatné!

Myslím, že stojí za to si pamatovat své vlastní zkušenosti s vývojovým softwarem. Pracuji v médiu, kde se produkt vyvíjel, je neustále v pracovním stavu a změny se do něj neustále zavádějí. Termíny pro vydání příští funkční verze jsou monstrózně stlačeny a zároveň existuje obrovské technické riziko. V podobném prostředí je schopnost opravit váš spolupracovník umění, bez nichž není přežil. Sdílení informací uvnitř nějakého týmu i mezi několika příkazy, které jsou často oddělené geograficky, se provádí pomocí kódu. Četli jsme kód, abychom pochopili zařízení nových nebo modifikovaných systémových softwarových rozhraní. Životní cyklus a chování komplexních objektů se stanoví pomocí zkušebních případů, to je opět s kódy. Zprávy o nových problémech jsou doprovázeny testovacími případy, které ukazují problém, kód se znovu používá. Konečně jsme neustále zapojeni do zlepšování stávajícího kodexu, což je produktivnější, pružnější, srozumitelnější. Je zřejmé, že v takových podmínkách je vývoj softwarového produktu téměř zcela založen na kódování, ale zároveň můžeme úspěšně doplnit projekty podle času, tedy tento přístup je velmi životaschopný.

Kent patřil mezi ty vůdce Tektronix, kteří si uvědomili obrovský potenciál, který byl stanoven v metodice programování v příbuzných dvojicích při vývoji komplexních inženýrských aplikací v mediu Smalltalk. Společně s Bard Cunninghamem (Ward Cunningham), Kent stal se inspirativní vývoj programovacích metod pro vzorky (nazývá se také programování pomocí vzorů - programování vzorů.který velmi ovlivnil svou vlastní kariéru. V rámci XP, přístup k rozvoji softwaru, který kombinuje metody používané mnoha úspěšnými pracovními vývojáři, kteří studovali mnoho literatury na organizaci pracovních programátorů, a snažili se v praxi mnoho metod a postupů pro rozvoj softwarového produktu . Stejně jako ukázkový programování, XP tvoří soubor nejúčinnějších technik, jako jsou testovací softwarové moduly, programování par a recyklaci kódů. V rámci XP jsou tyto techniky kombinovány tak, aby se doplnil a často se navzájem kontrolují. Hlavním účelem této knihy je hovořit o interakci a sdílení různých technik. Ve všech programovacích technikách je jedním z cílů vytvořit softwarový produkt s danou funkčností do určité doby. Navrhovaný OTI je velmi úspěšný jen v časovém softwaru procesu není XP v čistá formaMezi těmito dvěma přístupy však existuje mnoho společných.

Spolupracoval jsem s Kentem a použil jsem epizody popsané v rámci XP při práci na malém, ale nevhodném projektu JUIT. Jeho názory a přístupy k rozvoji programů mě vždy vytvořily, abych přemýšlel o tom, jak osobně jsem pracovali na projektu programu. Bezpochyby, XP představuje otázku mnoha tradičních přístupů používaných v programovacím průmyslu. Po přečtení této knihy se můžete rozhodnout sami, musíte použít XP ve své práci nebo ne.

Extrémní programování

O řadě XP

Řekl jsem "Začátek odpovědi na" Vzhledem k tomu, že pokračování ve skutečnosti neexistuje. Lidé, kteří vytvořili a představili XP, také přemýšleli o rozhodnutí tohoto problému. Snažil se používat XP, vstoupili přes prahovou hodnotu a navštívili nezmapovanou. Vrácení, řekli svůj příběh. Myšlenky uvedené nimi jsou ukazatele umístěny podél silnice: "Draci žijí tady," "15 km otevírá dobrý výhled," toto místo je nebezpečné během deště. "

Omlouvám se, ale je čas, abych se naprogramoval.

Kent Beck, Série konzultant

Předmluva

Extrémní programování ( extrémní programování, XP) Definuje kódování klíčových a základních činností při práci na projektu Program. Je možné, že je to špatné!

Kent patřil mezi ty vůdce Tektronix, kteří si uvědomili obrovský potenciál, který byl stanoven v metodice programování v příbuzných dvojicích při vývoji komplexních inženýrských aplikací v mediu Smalltalk. Společně s Bard Cunninghamem (Ward Cunningham), Kent stal se inspirativní vývoj programovacích metod pro vzorky (nazývá se také programování pomocí vzorů - programování vzorů.který velmi ovlivnil svou vlastní kariéru. V rámci XP, přístup k rozvoji softwaru, který kombinuje metody používané mnoha úspěšnými pracovními vývojáři, kteří studovali mnoho literatury na organizaci pracovních programátorů, a snažili se v praxi mnoho metod a postupů pro rozvoj softwarového produktu . Stejně jako ukázkový programování, XP tvoří soubor nejúčinnějších technik, jako jsou testovací softwarové moduly, programování par a recyklaci kódů. V rámci XP jsou tyto techniky kombinovány tak, aby se doplnil a často se navzájem kontrolují. Hlavním účelem této knihy je hovořit o interakci a sdílení různých technik. Ve všech programovacích technikách je jedním z cílů vytvořit softwarový produkt s danou funkčností do určité doby. Navrhované OTII úspěšné právě v časovém softwaru procesu není ve své čisté formě XP, ale mezi těmito dvěma přístupy existuje mnoho společných.

Erich Gamma (Erich Gamma)

Úvod

Tato kniha o extrémním programování ( extrémní programování, XP). Extrémní programování je zjednodušená metoda organizace výroby pro malé a střední týmy specialistů zapojených do vývoje softwarového produktu v podmínkách nejasných nebo rychle se měnících požadavků. Tato kniha je navržena tak, aby pomohla určit, zda je použití XP odůvodněno ve vaší situaci.

Pokud je revize kódu dobrá, znamená to, že kód budeme neustále revidovat (ve dvojicích);

Testování Eles je dobré, každý účastník projektu bude testovat programový kód neustále (testovací moduly), dokonce i zákazníci (funkční testy);

ERSEE DESIGN je dobrý, znamená to, že konstrukce musí být součástí každodenní práce každého z účastníků projektu (recyklace kódu);

Jednoduchost ESLEY je dobrá, znamená to, že budeme muset udržet nejjednodušší design v systému, který poskytuje současnou požadovanou úroveň funkčnosti (nejjednodušší věc, která bude s největší pravděpodobností pracovat); Pokud je architektura důležitá, znamená to, že každý z účastníků projektu bude průběžně pracovat na definici a revizi architektury (metafora);

Testování integrace ESLEY je důležité, znamená to, že je nutné sbírat a otestovat systém, který je vyvíjen několikrát denně (pokračující integrace);

Esley malé iterace jsou dobré, je nutné provést iterace velmi, velmi malé - sekundy, minuty, možná hodiny, ale ne týdny a měsíce, a v žádném případě (hra v plánování).

Když jsem se poprvé rozhodl formulovat podstatu XP pro sebe, představoval jsem si sadu rukojeti na ovládacím panelu. Každá rukojeť odpovídala určitou metodologii, která z jeho osobní zkušenost Věděl jsem, že to bylo docela efektivní. Každá rukojeť je povolena použít tuto nebo tuto techniku \u200b\u200bdo jisté míry: od 1 do 10. Snažil jsem se nainstalovat všechny rukojeti do maximální možné polohy (10) a byl jsem překvapen, že kompletní soubor metod, které mě považuje za stabilní, předvídatelné a flexibilní.

XP tvoří dvě sady slibů:

Programátoři XP slibuje, že každý z nich bude pracovat na řešení skutečně důležitých úkolů každý pracovní den. Každý z nich nikdy nebude v množství. Každý z nich bude schopen dělat vše v tom záleží na tom, aby byl systém úspěšný. Každý z nich bude schopen učinit rozhodnutí právě v oblasti, ve které je příslušná, a pokud to není v určitém regionu kompetentní, nebude se účastnit rozhodování.

Zákazníci a HR manažeři slibují, že získají maximální možný návrat z každého týdne práce na projektu. Každé několik týdnů budou moci vidět pokrok při dosahování svých cílů. Budou mít možnost změnit směr vývoje projektu ve velmi středu vývoje, bez obav z dalších mimořádných nákladů.

Pokud mluvíte krátké, XP slibuje, že sníží riziko související s rizikem, zlepšit reakci na změnu podnikání, zlepšit výkon projektu a provést proces vývoje softwaru je příjemnější - a to vše současně. Dělám si srandu, dost smát. Přečtěte si tuto knihu a vy sami si můžete zkontrolovat, zda jsem blázen.

Tato kniha

Tato kniha vypráví o věcech souvisejících s metodou XP, jeho kořenů, filozofie, různých druhů příběhů a mýtů. Kniha je navržena tak, aby vám pomohla učinit vážené rozhodnutí o tom, zda je nutné použít XP ve vašem vlastním projektu. Pokud jste po přečtení této knihy rozhodli, že jste nepoužili XP při práci na vašem projektu, zvážím hlavním cílem dosaženým stejným způsobem, jako kdyby po přečtení této knihy přijali rozhodnutí, že XP je to, co potřebujete . Druhým cílem knihy je pomoci těm, kteří již používají XP. Po přečtení knihy budou tyto čtenáři schopni lépe pochopit tuto techniku.

Tato kniha neobsahuje přesné pokyny o tom, jak přesně by měl být proveden proces extrémního programování. Nebudete v něm vidět mnoho příkladů, algoritmů nebo programátorů. Abyste to vše mohli hledat, můžete vyhledávat na internetu, mluvit s některými účastníky projektu, počkejte na vzhled knih věnovaných tomu nebo jak vytvořit takový materiál.

Další osud popsaný ve mně Disciplína vývoje softwaru XP je v rukou skupiny lidí (možná jste jedním z nich), které jsou nespokojeny se stávajícími tento moment Tradiční metody organizování práce programátorů. Potřebujete b. nejlepší způsob Vývoj softwaru, chcete navázat produktivnější a přátelské vztahy se svými zákazníky, chcete provést práci pod programátorem vedení šťastnější, loajální a produktivnější. Stručně řečeno, chcete získat významnou výhodu a nebojíte se využít nových nápadů, abyste tuto výhodu získali. Nicméně, před rizikem, chcete se ujistit, že jste alespoň ne úplný blázen.

XP vám předepisuje, abyste dělali práci zcela jinak, než jste na to zvyklí. V některých případech doporučení XP zcela odporují obecně uznávané normy. Na tento moment Domnívám se, že pouze ti, kteří mají významné důvody pro změnu stávajícího řádu, budou moci používat XP. Pokud však takové důvody existují, můžete začít používat XP právě teď. Napsal jsem tuto knihu, abyste se mohli dozvědět o těchto důvodech více.

Co je XP?

Co je XP? XP je zjednodušená, efektivní, pružná, předvídatelná, vědecky založená a velmi příjemný způsob, jak vytvořit software zajišťující nízká úroveň riziko. Z jiných metod se XP liší v následujících funkcích.

Díky použití extrémně krátkých cyklů nabízí vývoj XP rychlé, reálné a neustále fungující zpětnou vazbu.

V rámci XP, plánování zvyšování, v důsledku toho, obecný plán projektu vzniká docela rychle, ale je zřejmé, že tento plán se vyvíjí po celou dobu životnosti projektu.

V rámci XP se používá pružný harmonogram realizace jedné nebo jiné funkčnosti, čímž se zlepšuje reakci na změnu povahy podnikání a mění požadavky zákazníka.

XP je založen na automatických testech vyvinutých programátory i zákazníky. Díky těmto testům je možné sledovat vývojový proces, aby byl zajištěn správný vývoj systému a neprodleně zjistit defekty existující v systému.

XP je založen na ústní výměně informací, testů a zdrojového kódu. Tři z těchto nástrojů se používají k výměně informací o struktuře systému a jeho chování.

XP je založen na procesu vyvíjejícího se návrhu, který pokračuje, pokud existuje systém sám.

XP je založen na úzké interakci programátorů, kteří mají nejčastější dovednosti a schopnosti.

XP je založen na metodách, které uspokojí jak krátkodobé instinkty jednotlivých programátorů, tak dlouhodobé zájmy celého projektu jako celku.

XP je disciplína vývoje softwaru. To je disciplína, protože v rámci XP existují určité věci, které musíte udělat, pokud chcete použít XP. Nemusíte si vybrat, je nutné nebo ne zapisovat testy, protože pokud to neuděláte, programování, nemůžete být nazýváni extrémní: konec diskuse.

Technika XP je navržena tak, aby pracovala na projektech, které mohou pracovat ze dvou až deset programátorů, kteří nejsou upnuty do tuhého rámce stávajícího počítačového prostředí a ve kterých může být veškerá nezbytná práce související s testováním prováděna během jednoho dne.

XP děsí nebo nepříjemné lidi, kteří tuto techniku \u200b\u200bčelí poprvé. Zároveň není idea podkladová XP není nový. V určitém smyslu je metoda XP konzervativní - všechny techniky používané v jeho rámci jsou testovány po desetiletí (pokud jde o realizační strategii) a dokonce staletí (jako pro strategii řízení).

Inovace v XP jsou následující funkce:

Všechny tyto dlouhodobě známé techniky jsou sestaveny pod jednou střechou;

Intenzita, s nimiž se tyto techniky zavádějí do každodenní práce, je přivedena do extrémů;

Použité techniky jsou podporovány jedním z druhých v co největší míře.

Přiměřenost

Ve svých dílech Lesní lidé (lesní národy) a hory (lidé horské národy) Antropolog Colin Turnbull (Colin Turnbull) popisuje dvě společnosti zcela odlišné od sebe. V horách nezbytných pro život, chybí prostředky a lidé jsou vždy na pokraji hladu. Kultura, která vznikla v takových podmínkách vypadá úžasně. Matky hodí své děti, aby se přežily. Impregnace může způsobit zranění. Krutost, zvěrstva a zrada jsou obyčejný a každý den.

Na rozdíl od hor, les je nasycen zdroji. Aby byla zajištěna sama o celý den, osoba stačí strávit jen asi půl hodiny. Lesní kultura je odrazem těžební kultury. Dospělí se účastní pěstování a vzdělávání společných dětí, které rostou v lásce a péči, dokud se nestolí dostatečně schopnými postarat se o sebe. Pokud jedna osoba zabíjí jinou osobu (záměrná vražda těchto lidí není obeznámen), je vyloučen ze společnosti. Současně by však exil jednoduše měly být odstraněny do lesa a strávit tam několik měsíců, a dokonce i někteří členové kmene mu přinášejí jídlo a dary.

XP je pokus o odpověď na otázku: Jak byste osobně programoval, kdybyste měli dost času? Ve skutečnosti nemáte příliš mnoho času, protože v koncovém programování je podnikání. V každém podnikání vyhraje ten, kdo dělá práci rychleji. Pokud jste však měli čas, pravděpodobně byste věnovali pozornost rozvoji testů; Pravděpodobně byste přepracovali architekturu systému v případě, že by bylo nutné dospět k závěru, že je to nezbytné; Určitě komunikovat s našimi programátorskými soudruhy, stejně jako se zákazníkem.

Podobný pocit dostatečnosti vypadá více humánně na situacích, kdy programátoři z posledních sil se snaží zůstat v daném dočasném rámce, zaklepat z harmonogramu, nemají čas provádět velké množství mimořádně důležité práce pouze v pořádku musejí projít projekt včas. Pospěškařina zabraňuje programátorům plně ukázat svůj talent a užívat si práce. Začínáme prozkoumat XP, musíte pochopit, že pocit dostatečnosti je také dobrým obchodem. Pocit dostatečnosti se stává zdrojem účinnosti stejným způsobem jako pocit nedostatku vede ke vzniku poruch, vede k vzniku vad a snížení kvality a nakonec snížení produktivity práce.

Plánovaná kniha

Kniha je napsána, jako byste se také zapojili do vytváření nové disciplíny vývoje softwaru. Začínáme se studiem našich základních představ o vývoji softwaru. Poté ve skutečnosti vytvoříme novou disciplínu. Pak studujeme důsledky toho, co jsme vytvořili - jak to může být implementováno a používáno v praxi, když by nemělo být použito, a jaké příležitosti se otevírá podnikání.

Kniha je rozdělena do tří částí.

Problém: v kapitolách, počínaje Riziko: Hlavní problém A dokončování Zpět na původProblém je zjištěno, že extrémní programování se snaží vyřešit, a kritéria jsou stanovena, kterým lze odhadnout kvalitu řešení. V této části získáte obecnou představu o metodě extrémního programování.

Rozhodnutí: v kapitolách, počínaje Krátká recenze A dokončování Zkušební strategie, Abstraktní nápady prezentované v první části knihy jsou převedeny na soubor konkrétních technik disciplíny. Tato kapitola neobsahuje žádné informace o přesně, jak můžete použít popsané techniky v praxi. Místo toho mluvíme o obecné formě každého z technik. Hádání o každé techniky, sdružuji to s problémy a principy popsanými v první části knihy.

Realizace XP.: v kapitolách, počínaje Úvod XP. A dokončování XP v práciMnoho otázek souvisejících se zavedením XP jsou diskutovány - jak zavést XP, který by měl být očekáván od různých lidí účastnících se projektu HP, kterou představu o XP se rozvíjí v lidech podnikatelského světa.

dík

Ozývám čtenářům z první osoby, protože kniha představuje mé vlastní nápady, a proto vám říkám o mém vlastním vnímání těchto nápadů. Většina technik používaných v rámci XP je stará jako všechny programování.

Ward Cunningham (Ward Cunningham) je můj hlavní zdroj, ze kterého jsem křičel v knižním materiálu. Jeden nebo druhý, strávil jsem posledních patnáct let, jen se snažil vysvětlit ostatním lidem, jaký Vard byl prakticky angažován téměř dlouho. Děkuji také Ron Jeffries za to, že to také vyzkoušel, a pak se výrazně zlepšil. Díky Martinovi Fowerovi (Martin Fowler) pro vysvětlení to vše jednoduchým měkkým jazykem a bez nervového narušení. Díky Ericha Gamma (Erich Gamma) pro dlouhé konverzace, v kombinaci s rozjímáním labutí v Limme, stejně jako pro ne, aby mi nedovolily nechat ho špatnými myšlenkami v mé hlavě. A samozřejmě, nic by se nestalo v mém životě, kdybych neměl žádný takový imitace, jako můj otec, Doug Beck, který po mnoho let honil své programovací dovednosti.

Díky týmu C3 ve společnosti Chrysler mě v průzkumech doprovázel. A také zvláštní díky našim manažerům na Sue hněv (Ron Savage) za to, že měli dost odvahy, aby nám to zkusil.

Díky daedalos consultingu za pomoc psaní této knihy.

Odměna šampionátu za sledování materiálu jde do rukou Paul Chisholmu (Paul Chisholm) pro své hojné, nemovité, úzkostlivé, a často upřímně nepříjemné komentáře. Bez jeho pomoci tato kniha Nebyl bych sám tak populární.

Opravdu mám velký potěšení z komunikace se všemi těmi, kteří provedli náhled co jsem napsal.

Jejich práce se pro mě stala obrovskou pomoc. Nemůžu najít slova vděčnosti za to, že mají dost trpělivosti číst všechny této prózy, pro mnoho z nich nastínil v cizím jazyce.

Děkuji (v náhodném pořadí, ve kterém jsem obdržel komentáře z nich) Greg Hutchinson, Massimo Arnoldi, Dave Cleal, Sames Schuster, Don Wells, Joshua Kerievsky, Torsten Ditmar (Thorsten Dittmar), Moritz Beber (Daniel Globler), Christofe Henric (Daniel Glob), Christoph Henrici), Thomas Zangu (Dierk Koenig), Miroslav Nováka (Mroslav Novak), Rodney Rodney Rodney, Frank Westphal, Paul Trunz, Steve Hayes (Steve Hayes), Kevin Bradtke, Janny de Guzman (Jeanine de Guzman), Kubit (Jeanine de Guzman), Tom Kubit), Falkmann, Hasko Heinec (Peter Merel), Rob MC (Rob Mell), McBreen, Tomas Ernstu (Thomas Ernst), Guido Hchelle (Guido Hachler), Dieter Holz, Martin Knecht, Dirka Krampe ( Dierk Krampe), Patrick Lisser (Patrick Lisser), Elisabeth Maier, Thomas Mancini (Thomas Mancini), Aleksio Moro (Alexio Moreno), Rolf Pfenninger (Rolf Pfenninger) a Matthias Ressel).

Z publikování

Vaše komentáře, návrhy, poslat dotazy na e-mailem [Chráněný emailem] (PETTER Nakladatelství, počítačový redakci).

Budeme rádi, abychom znali váš názor!

Všechny zdrojové texty v knize najdete na adrese http://www.piter.com/download..

Na webu nakladatelství http://www.piter.com naleznete podrobné informace o našich knihách.

Problém

V této části knihy je scéna připravena, na které extrémní programování by mělo být následné. Popisuje různé aspekty problému, které mají být vyřešeny vytvořením nové disciplíny vývoje softwaru.

Tato část popisuje základní předpoklady, které musíme brát v úvahu výběrem technik rozvoje softwaru, metaforou pro správu automobilů, čtyř hodnot, principy vytvořené na základě těchto hodnot, jakož i činnosti, které mají být strukturovány v rámci Rámec nové disciplíny vývoje softwaru.

Riziko: Hlavní problém

Stávající disciplíny vývoje softwaru nejsou spuštěny a nedávají požadovaný ekonomický efekt. Tento problém má obrovský hospodářský a humanitární význam. Potřebujeme nový způsob, jak rozvíjet software.

Hlavním problémem vývoje softwaru je riziko.

Zde jsou některé příklady rizika.

Snímání grafů- Den doručení přijde, a jste nuceni informovat zákazníka, že systém byl vyvinut, nebude připraven dalších šest měsíců.

Uzavření projektu- Po několika směnách harmonogramu a přenosu data doručení se projekt zavře, ani nepřinese do zkušebního fáze v pracovních podmínkách.

Systém ztrácí svůj užitek - Vyvinutý software je úspěšně založen v reálném výrobním pracovním prostředí, ale po několika letech používání se náklady na provedení změn na něm a / nebo počet vad zvyšuje tak, že se stává levnější nahradit systém novým rozvoj.

- Softwarový systém je instalován v reálném výrobním pracovním prostředí, ale počet vad a nedostatků je tak velký, že systém není použit.

- Softwarový systém je instalován v reálném výrobním pracovním prostředí, nicméně ukazuje, že ve skutečnosti nevyřeší problém podnikání, aby se vyřešil, který byl původně zamýšlen.

Změna obchodní přírody - Softwarový systém je instalován v reálném výrobním pracovním prostředí, avšak během šesti posledních měsíců, problém, pro který byl tento systém zamýšlen tak, aby byl relevantní, a místo toho podnikání čelil novým, ještě vážnějším problémem.

Nedostatek možností - Softwarový systém má mnoho potenciálně zajímavých funkcí, z nichž každý byl velmi příjemný pro program, ale ukázalo se, že žádný z těchto možností nepřináší zákazníkovi mnoho výhod.

Výukové rámečky - Pro dva roky práce, vše dobré programátoryKdo pracoval na projektu, jeden po druhém zvýšil programový systém vyvinutý a šel do jiné práce.

Na stránkách této knihy budete číst o Extreme Programming ( extrémní programování, XP) - Disciplína vývoje softwaru, který je zaměřen na snížení míry rizika na všech úrovních procesu vývoje. XP přispívá k významnému nárůstu produktivity a zlepšuje kvalitu vyvíjených programů, navíc je to velmi zaneprázdněná praxe, která dává všem svým účastníkům mnoho potěšení.

Jak XP sníží rizika uvedená dříve?

Vymítnutí grafiky - XP nabízí použití velmi krátkého času vydání každé další verze. Každá pravidelná verze systému připravených k použití je vyvinuta po dobu nejvýše několik měsíců. Rozsah práce v rámci každé znění je tedy omezen, a proto, pokud dojde k vysídlení, je méně významný. V rámci každé verze je plánováno vydat několik iterací požadovaných zákazníkům příležitosti k rozvoji každého z těchto iterací od jednoho do čtyř týdnů. To zajišťuje flexibilní a citlivou zpětnou vazbu se zákazníkem, takže dostane představu o současné práci. V rámci každé iterace se plánování v souladu s XP provádí z hlediska několika úkolů, které je třeba vyřešit, aby se získala další iterace. Řešení každé z úkolů je uvedeno od jednoho do tří dnů. V důsledku toho může příkaz detekovat a odstraňovat problémy i v procesu iterace. Konečně XP znamená, že budou provedeny příležitosti s nejvyšší prioritou. Musí tedy možnosti, které nedokázaly realizovat v rámci této pravidelné verze softwarového produktu, mají menší prioritu.

Uzavření projektu - V rámci XP musí Zákazník určit nejmenší přípustnou sadu příležitostí, které musí minimální pracovní verze programu mít smysl z hlediska řešení obchodních úkolů. Programátoři tak budou muset učinit minimální množství úsilí, aby zákazník pochopil, zda potřebuje tento projekt nebo ne.

Systém ztrácí svůj užitek - Jako součást XP, obrovský počet testů je vytvořeno a podporováno, které jsou spuštěny a restartovány po provedení jakékoli změny systému (několikrát denně), díky které je možné pečlivě sledovat kvalitu programu vyvíjeny. XP neustále podporuje systém ve výborném stavu. Vady jednoduše nedávají akumulovat.

Počet vad a nedostatků - V rámci XP se systém vyvinutý je testován jako programátoři vytváření testů pro každou individuální funkci a zákazníci, kteří vytvářejí testy pro každé jednotlivé systémové schopnosti.

Chybí problém řešený problém - Jako součást XP je zákazník nedílnou součástí týmu, který pracuje na projektu. Specifikace projektu je neustále recyklována v průběhu práce na projektu, díky tomu, jakékoli zdokonalení a objevy, které zákazník hlásí vývojový tým, okamžitě zjistí jejich odraz v programu, který je vyvíjen.

Extrémní programování: Vývoj prostřednictvím testování

Věnovaný Cindy: křídla mé duše

Publikační práva byla získána dohodou s Addison-Wesley Longmanem. Všechna práva vyhrazena. Žádná část této knihy nelze reprodukovat v jakékoli formě bez písemného souhlasu držitelů autorských práv.

Informace obsažené v této knize jsou získány ze zdrojů zvažovaných vydavatelem jako spolehlivý. S ohledem na možné lidské nebo technické chyby však vydavatel nemůže zaručit absolutní přesnost a úplnost informací a neodpovídá za možné chyby související s použitím knihy.

ISBN 978-0321146533 English.

ISBN 978-5-496-02570-6.

Předmluva

Čistý kód, který funguje (Čistý kód, který funguje) - v této krátké, ale obsahové fráze vynalezené Ron Jeffries (Ron Jeffries), leží celý význam rozvojové metodiky prostřednictvím testování (test-řízený vývoj, TDD). Čistý kód, který funguje, je cílem, ke kterému stojí za to usilovat

To je předvídatelný způsob, jak rozvíjet programy. Víte, kdy práce lze považovat za úplnou a ne obávejte se o dlouhou sérii chyb;

Dává šanci naučit se lekce, které kód prezentuje. Pokud použijete první myšlenku, která přišla na mysl, nebudete mít šanci realizovat druhý, lepší nápad;

Zlepšuje životnost uživatelů vašich programů;

Umožňuje svým kolegům počítat s vámi, a vy - abyste se na ně počítali;

Napište takový kód příjemnější.

Ale jak získat čistý kód, který funguje? Mnoho síly zasahují s námi, abychom získali čistý kód, a někdy není možné dostat ani kód, který funguje jen. Chcete-li se zbavit mnoha problémů, budeme vypracovat kód založený na automatizovaném testování. Tento programovací styl se nazývá testování. Podle této technice

Nový kód je napsán pouze po automatickém testu, který dokončí selhání, je napsán;

Jakákoliv duplikace je eliminována.

Dva jednoduchá pravidla, Není to ono? Generují však komplexní individuální a skupinové chování s množstvím technických důsledků:

V procesu návrhu neustále spustíme kód a získáme představu o jeho práci, pomáhá provést správná rozhodnutí;

Píšeme testy sami, protože nemůžeme čekat, že někdo jiný bude psát testy pro nás;

Naše vývojové prostředí musí rychle reagovat na modifikace malých kódů;

Konstrukce programu by měl být založen na používání souboru autonomních, slabě souvisejících komponent pro zjednodušení testování kódů.

Dvě zmíněné pravidla TDD určují postup pro programovací fáze.

1. červená - napsat malý test, který nefunguje, a možná ani nekompiluje.

2. Zelená - Proveďte zkušební práci co nejrychleji, nemyslete si o označení návrhu a čistoty kódu. Napište přesně takový kód tak, aby test fungoval.

3. Refactoring - Eliminovat jakoukoliv duplikaci z písemného kódu.

Červená - zelená - Refactoring je TDD mantra.

Pokud předpokládáme, že takový programovací styl je možný, lze předpokládat, že kvůli jeho použití bude kód obsahovat výrazně méně vad, kromě toho, že cíle práce bude jasný každému, kdo se v něm účastní. Pokud ano, pak vývoj pouze kódu potřebného k průchodu testů také vede k sociálním důsledkům:

S dostatečně nízkou hustotou vad, zajištění kvality, QA bude moci přejít z reakce na chyby jejich varování;

S poklesem počtu nepříjemných překvapení budou projektoví manažeři schopni přesněji hodnotit náklady na pracovní sílu a zapojit zákazníky do procesu vývoje;

Pokud jsou témata technických diskusí jasně definována, programátoři mohou stále interagovat mezi sebou neustále a více než jednou denně nebo jednou týdně;

A znovu, s poměrně nízkou hustotou vad, můžeme obdržet integrovaný pracovní produkt s novou funkčností, která se k něm přidala každý den, abychom se mohli připojit k našim zákazníkům v obchodním vztahu zcela nového typu.

Takže myšlenka je jednoduchá, ale jaký je náš zájem? Proč by měl programátor předpokládat další poplatek za psaní automatizovaných testů? Proč přesunout programátorem, aby se pohyboval kupředu drobnými řetězci, když je jeho mozek schopen přemýšlet o mnohem složitější konstrukční strukturu? Udatnost.

Udatnost

TDD je způsob, jak spravovat strach v procesu programování. Nemyslím strach z pádu z křesla nebo strachu z hlavy. Mám na mysli strach z úkolu, "tak složitý, že nemám ponětí, jak to vyřešit." Bolest je, když nám příroda říká: "Stop!", A strach je, když nám příroda říká: "Buďte opatrní!" Upozornění není vůbec špatná, ale kromě výhody má strach nějaký negativní dopad na nás:

Strach nás činí předem a důkladně přemýšlet o něčem nebo jiném jednání;

Strach nás činí méně komunikovat;

Strach nás bojí zpětné vazby na naší práci;

Strach nás dělá podrážděný.

Nic z toho nelze nazvat užitečné pro proces programování, zejména pokud pracujete na složitém úkolu. Takže čelí otázce, jak se dostat z obtížné situace a

Nepokoušejte se předpovědět budoucnost a okamžitě začněte praktickou studii problému;

Nenechte se opravit ze zbytku světa, ale zvýšit úroveň komunikace;

Neodhýbejte se reakcím, ale naopak stanovení spolehlivé zpětné vazby as pomocí pečlivě sledovat výsledky vašich akcí;

(S podráždění, musíte se vyrovnat s sebou).

Porovnejte programování s kbelíkem studny. Kbelík je naplněn vodou, otočíte páku, vinutí řetězu na bránu a zvyšování kbelíku nahoru. Pokud je malý kbelík docela vhodný pro pravidelnou, volně rotující bránu. Ale pokud je kbelík velký a tvrdý, budete unaveni před tím, než ho zvednete. Chcete-li získat příležitost k odpočinku mezi otočením páky, je zapotřebí ráčnový mechanismus, který umožňuje upevnit páku. Tvrdší kbelík, tím častěji by zuby měly následovat na převodovku ráčny.

Testy v TDD jsou zuby na převodovku ráčny. Nutit zkoušku do práce, víme, že nyní test funguje, od teď navždy. Stali jsme se o krok blíže k dokončení práce než před vydělaným testem. Poté jsme nuceni pracovat druhý test, pak třetí, čtvrtý atd. Čím těžší je problém s programátorem, tím menší funkce by měly pokrývat každý test.

Čtená knihy Extrémní programování VysokoMusí si všimnout pozornost rozdílu v tónu mezi extrémním programováním (extrémní programování, XP) a testováním testováním (vývoj testu, TDD). Na rozdíl od XP není technika TDD absolutní. XP říká: "Chcete-li jít dál, musíte se naučit a to." TDD je méně specifická technika. TDD přebírá přítomnost intervalu mezi rozhodováním a získáváním výsledků a nabízí nástroje pro kontrolu délky trvání tohoto intervalu. "Co když během týdne navrhnu algoritmus na papíře, a pak napsat kód, pomocí" První testy "? Bude to fit tdd? " Samozřejmě to bude. Znáte velikost intervalu mezi rozhodováním a vyhodnocováním výsledků a vědomě kontrolovat tento interval.

Většina lidí, kteří zvládli TDD, tvrdí, že jejich programovací praxe se změnila na lepší. Infikované testy (Infikovaný test) - Taková definice přišla s Erich Gamma (Erich Gamma), aby popsala tuto změnu. Měl zvládl TDD, zjistíte, že píšete mnohem více testů než předtím, a posuňte se dopředu drobnými kroky, které by se objevily bezvýznamné. Na druhou stranu, někteří programátoři se seznámili s TDD, se rozhodnou vrátit se k použití předchozích postupů, rezervovat TDD pro zvláštní příležitosti, pokud běžné programování nevede k požadovanému pokroku.

Určitě existují úkoly, které jsou nemožné (alespoň v tuto chvíli) vyřešit pouze s testy. Zejména TDD neumožňuje mechanicky demonstrovat přiměřenost vyvinutého kódu z hlediska bezpečnosti dat a spolehlivosti paralelních operací. Samozřejmě, že bezpečnost je založena na kodexu, ve kterém by neměly být žádné vady, ale je také založeno na lidské účasti v postupech ochrany údajů. Tenké problémy paralelních operací jsou nemožné reprodukovat s důvěrou, jen běží nějaký kód.