Kent Beck - Extrémní programování. Vývoj prostřednictvím testování. Extrémní programování (XP) není pro slabé povahy

A další.

Název metodiky pochází z myšlenky použití užitečných tradičních vývojových metod a postupů. software, čímž je posouváme na novou „extrémní“ úroveň. Takže například praxe provádění revize kódu, která spočívá v tom, že jeden programátor kontroluje kód napsaný jiným programátorem, v „extrémní“ verzi je „párové programování“, kdy jeden programátor kóduje a jeho partner na zároveň průběžně přezkoumává nově napsaný kód.

Encyklopedický YouTube

1 / 5

Extrémní programování (XP) – základní techniky

Hexlet Webinar #6: Extrémní programování

životní tipy. Proč se účastnit programátorských soutěží?

032. Párové programování - Sergey Berezhnoy

Kanál extrémní programování proti. 2,0

titulky

XP základní triky

Dvanáct základních technik extrémního programování (podle prvního vydání knihy Extrémní programování vysvětleno) lze seskupit do čtyř skupin:

Krátký cyklus zpětné vazby (zpětná vazba v jemném měřítku)
- Vývoj až po testování (vývoj řízený testem)
- Plánovací hra
- Zákazník je vždy přítomen (celý tým, zákazník na místě)
- Párové programování
Nepřetržitý, ne dávkový proces
- Průběžná integrace
- Refaktoring (vylepšení designu, Refaktoring)
- Častá malá vydání
Porozumění sdílené všemi
- Jednoduchost
- Systémová metafora
- Kolektivní vlastnictví kódu nebo vybraných návrhových vzorů (kolektivní vlastnictví vzorů)
- Kódovací standard nebo kódovací konvence
Sociální zabezpečení programátora (Programmer welfare):
- 40hodinový pracovní týden (udržitelné tempo, čtyřicetihodinový týden)

Testování

XP zahrnuje psaní automatických testů (programový kód napsaný speciálně pro testování logiky jiného programový kód). Zvláštní pozornost je věnována dvěma typům testování:

jednotkové testování modulů;

Vývojář si nemůže být jistý správností kódu, který píše, dokud nefungují absolutně všechny unit testy systému, který vyvíjí. Unit testy (jednotkové testy) umožňují vývojářům ujistit se, že každý z nich samostatně funguje správně. Pomáhají také ostatním vývojářům pochopit, proč je konkrétní část kódu potřebná a jak funguje – v průběhu studia testovacího kódu se logika testovaného kódu vyjasní, protože je jasné, jak by měl být použit. Jednotkové testy také umožňují vývojáři bez obav refaktorovat.

Funkční testy jsou navrženy tak, aby otestovaly fungování logiky tvořené interakcí několika (často velmi působivých velikostí) částí. Jsou méně podrobné než unit testy, ale pokrývají mnohem více – tedy testy, které při svém provádění ovlivňují větší množství kódu, mají samozřejmě větší šanci odhalit jakékoli nesprávné chování. Z tohoto důvodu v průmyslové programování psaní funkčních testů má často přednost před psaním unit testů.

Pro XP má vyšší prioritu přístup zvaný TDD (z anglického test-driven development - vývoj přes testování). V souladu s tímto přístupem se nejprve napíše test, který zpočátku selže (protože logika, kterou by měl kontrolovat, zatím prostě neexistuje), pak se implementuje logika nezbytná k tomu, aby test prošel. TDD v jistém smyslu umožňuje psát kód, který je pohodlnější používat - protože při psaní testu, když ještě neexistuje žádná logika, je nejjednodušší se postarat o pohodlí budoucího systému.

Plánovací hra

Hlavním cílem plánovací hry je rychle se tvořit hrubý plán pracovat a neustále jej aktualizovat, jak se vyjasňují podmínky úkolu. Artefakty plánovací hry jsou sada papírových karet, které obsahují přání zákazníka (příběhy zákazníků) a hrubý pracovní plán pro vydání další jedné nebo více malých verzí produktu. Kritickým faktorem, díky kterému je tento styl plánování efektivní, je to tento případ zákazník je zodpovědný za obchodní rozhodnutí a vývojový tým je zodpovědný za technická rozhodnutí. Pokud se toto pravidlo nedodrží, celý proces se rozpadne.

Zákazník je tam vždy

"Zákazník" v XP není ten, kdo platí účty, ale koncový uživatel softwarový produkt. XP tvrdí, že zákazník musí být neustále v kontaktu a k dispozici pro dotazy.

Párové programování

Párové programování předpokládá, že veškerý kód je vytvořen páry programátorů pracujících na stejném počítači. Jeden z nich pracuje přímo s textem programu, druhý kontroluje jeho práci a sleduje velký obraz co se děje. V případě potřeby se klávesnice volně přenáší z jedné na druhou. Při práci na projektu nejsou dvojice pevně dané: doporučuje se je smíchat, aby každý programátor v týmu měl dobrou představu o celém systému. Tímto způsobem párové programování zlepšuje interakci v týmu.

Průběžná integrace

Pokud dostatečně často integrujete vyvíjený systém, můžete se vyhnout většině problémů s tím spojených. V tradičních metodách se integrace zpravidla provádí na samém konci práce na produktu, kdy se má za to, že všechny součásti vyvíjeného systému jsou zcela připraveny. V XP se kódová integrace celého systému provádí několikrát denně poté, co se vývojáři ujistili, že všechny testy jednotek fungují správně.

Refaktoring

Refaktoring je technika pro vylepšení kódu bez změny jeho funkčnosti. XP znamená, že jakmile je kód napsán, bude téměř jistě v průběhu projektu mnohokrát předělán. Vývojáři XP nemilosrdně přepracovávají dříve napsaný kód, aby jej vylepšili. Tento proces se nazývá refaktoring. Nedostatek testovacího pokrytí vyvolává odmítnutí refaktoringu kvůli strachu z prolomení systému, což vede k postupné degradaci kódu.

Častá malá vydání

Verze (release) produktu by měly jít do výroby co nejčastěji. Práce na každé verzi by měla zabrat co nejméně času. Každá verze by přitom měla být dostatečně smysluplná z hlediska užitečnosti pro podnikání.

Čím dříve je uvolněna první pracovní verze produktu, tím dříve díky ní zákazník začne získávat další zisk. Pamatujte, že peníze vydělané dnes mají větší hodnotu než peníze vydělané zítra. Čím dříve začne zákazník produkt používat, tím dříve od něj vývojáři dostanou informaci o tom, co splňuje požadavky zákazníka. Tyto informace mohou být velmi užitečné při plánování dalšího vydání.

Snadnost designu

XP vychází z toho, že v průběhu práce se podmínky problému mohou opakovaně měnit, což znamená, že vyvíjený produkt by neměl být předem zcela a kompletně navržen. Snažit se systém detailně navrhnout hned na začátku práce je ztráta času. XP naznačuje, že návrh je tak důležitý proces, že musí být prováděn nepřetržitě po celou dobu životnosti projektu. Návrh by měl být prováděn po malých krocích s ohledem na neustále se měnící požadavky. V každém okamžiku byste se měli pokusit použít nejjednodušší návrh, který vyhovuje aktuálnímu problému, a změnit jej podle toho, jak se změní podmínky problému.

Systémová metafora

Architektura je reprezentace komponent systému a jejich vzájemných vztahů. Vývojáři potřebují analyzovat softwarovou architekturu, aby pochopili, kam v systému potřebují přidat nové funkce a s čím bude nová komponenta interagovat.

Metafora systému je analogická tomu, co většina technik nazývá architektura. Metafora systému dává týmu představu o tom, jak systém aktuálně funguje, kam se přidávají nové komponenty a jakou formu by měly mít.

Výběr dobré metafory usnadňuje vývojovému týmu pochopit, jak systém funguje. Někdy to není snadné.

Kódovací standardy

Všichni členové týmu musí v průběhu práce splňovat požadavky společných standardů kódování. Tím:

členové týmu neztrácejí čas dohadováním se o věcech, které ve skutečnosti nemají vliv na rychlost práce na projektu;
je zajištěno účinné provádění jiných postupů.

Pokud tým nepoužívá jednotné kódovací standardy, je pro vývojáře obtížnější refaktorovat; při střídání partnerů ve dvojicích je více obtíží; obecně je postup projektu obtížný. V rámci XP je nutné zajistit, aby bylo obtížné pochopit, kdo je autorem toho či onoho kódu - celý tým pracuje jednotně, jako jeden člověk. Tým musí vytvořit sadu pravidel a každý člen týmu musí tato pravidla během procesu kódování dodržovat. Seznam pravidel by neměl být vyčerpávající ani příliš obsáhlý. Úkolem je formulovat obecné pokyny, díky nimž bude kód srozumitelný pro každého z členů týmu. Kódovací standard by měl být zpočátku jednoduchý, pak se může postupně s tím, jak vývojový tým získávat zkušenosti, stávat složitějším. Není třeba trávit příliš mnoho času předvypracováním normy.

Kolektivní vlastnictví

Kolektivní vlastnictví znamená, že každý člen týmu je zodpovědný za veškerý zdrojový kód. Každý má tedy právo provádět změny v jakékoli části programu. Párové programování podporuje tuto praxi: při práci v různých párech se všichni programátoři seznámí se všemi částmi kódu systému. Důležitou výhodou kolektivního vlastnictví kódu je, že urychluje proces vývoje, protože když se objeví chyba, může ji opravit každý programátor.

Vložil(a) St, 25.01.2012 - 02:28

7. Adaptivní vývojové procesní modely: Scrum

V současné době stále rozšířenější adaptivní nebo lehké e, „živé“ (agilní) vývojové procesy
Ony nevyžadují tak přísnou regulaci, dovolit možnost častých a výrazných změn požadavků zákazníků

Adaptivní procesy klást důraz na použití dobří vývojáři spíše než dobře zavedené vývojové procesy
Ony vyvarujte se stanovení jasných vzorců jednání poskytnout větší flexibilitu v každém konkrétním projektu a nevyžadovat vypracování dalších pomocných dokumentů

Principy "živého" vývoje

Základní principy "živého" vývoje softwaru opraveno v manifestu, který se objevil v roce 2000:=

Lidé zapojení do projektu a jejich komunikace jsou důležitější než procesy a nástroje
Funkční program je důležitější než komplexní dokumentace
Spolupráce se zákazníkem je důležitější než projednávání detailů smlouvy
Praktikování změn je důležitější než následování plánů

Extrémní programování

Nejčastěji používané adaptivní model je extrémní programovací model(Extrémní programování, proces XP)
Procesně orientovaný na XP do malých a středních skupin vyvíjejících softwarové produkty tváří v tvář nejistým nebo rychle se měnícím požadavkům

XP proces (extrémní programování)

Základní myšlenka procesu XP – eliminovat vysoké náklady na provádění změn. Toho je dosaženo prudkým (až dva týdny) zkrácením doby trvání jednotlivých iterací.
Základní xp akce jsou:=

kódování,
testování,
naslouchání zákazníkovi
design

Principy XP

Vysoká dynamika vývoj je zajištěn následujícími zásadami:=

nepřetržitá komunikace se zákazníkem,
jednoduchost zvolených řešení,
rychlá zpětná vazba založená na provozním testování,
prevence rizik

Vývojové postupy XP

Implementace těchto zásad je dosažena pomocí následujících metod:=

Metafora– veškerý vývoj je založen na jednoduché veřejné historii fungování systému
Jednoduchý design- jsou přijímána co nejjednodušší konstrukční rozhodnutí
Průběžné testování jak jednotlivé moduly, tak systém jako celek; vstupním kritériem pro zápis kódu je neúspěšný testovací případ
Reorganizace(Refaktoring) - zlepšení struktury systému při zachování jeho chování
Párové programování e - kód píší dva programátoři na jednom počítači
Kolektivní vlastnictví kódu– každý vývojář může vylepšit kód libovolného modulu systému
Průběžná integrace – systém je integrován tak často, jak je to možné; průběžné regresní testování zajišťuje, že funkčnost zůstane zachována i při změně požadavků
Místní zákazník– ve skupině musí být neustále kompetentní zástupce zákazníka
Kódovací standardy- musí být dodržována pravidla zajišťující stejnou reprezentaci kódu ve všech částech systému

Vývojové schéma XP

Obrázek XP (vývojový diagram XP):

Scrum model

Je dalším příkladem procesu adaptivního vývoje (dříve jsme zvažovali)
Hlavní myšlenky modelu formulovali Hirotaka Takeuchi a Ikujiro Nonaka v roce 1986.

Hlavní myšlenka modelu Scrum

Experimentální fakt: projekty, na kterých pracují malé týmy napříč různými funkcemi, mají tendenci systematicky přinášet lepší výsledky

Takeuki a Nonata to vysvětlili jako "ragbyový přístup" a zavedl termín

"skrumáž"- „rozdrtit; skrumáž kolem míče (v rugby)“

Scrum byl poprvé zdokumentován v roce 1996 Sutherlandem a Schwaberem.

Role

ScrumMaster, někdo, kdo se podílí na procesech a pracuje jako projektový manažer,
Vlastník produktu, osoba, která zastupuje zájmy koncových uživatelů a dalších zainteresovaných stran na produktu,
tým, která zahrnuje vývojáře

Vývojové fáze

Proces vývoje je rozdělen na samostatné etapy určitého trvání - sprinty(obvykle 15-30 dní)
Každý sprint předchází fáze nazývaná produktový backlog– dokumentace požadavků na práci

Plánování sprintu

Požadavky na práci jsou určovány během fáze desky plánování sprintu − schůzka plánování sprintu

Plánování sprintu
Během této schůzky informuje Product Owner o úkolech, které je třeba splnit
Tým určí, kolik požadovaného může splnit, aby dokončil potřebné části během dalšího sprintu

Provedení sprintu

Během sprintu tým podává výkon určitý pevný seznam úkolů - položky nevyřízených položek zvýšení funkčnosti softwarového produktu

Po celé toto období nikdo nemá právo měnit seznam požadavků na práci, což je třeba chápat jako zmrazení požadavků (požadavků) během sprintu

Scrum schéma =

text referenční odpovědi (neuvádím jej jako povinný)

Extrémní programování

XP základní triky

Krátký cyklus zpětné vazby (zpětná vazba s jemným měřítkem)

o Testem řízený vývoj

o Plánovací hra

o Zákazník je vždy přítomen (celý tým, zákazník na místě)

o Párové programování

Kontinuální spíše než dávkový proces

o Průběžná integrace

o Refaktoring (vylepšení designu, Refaktor)

o Častá malá vydání

Porozumění sdílené všemi

o Jednoduchost

o Systémová metafora

o kolektivní vlastnictví kódu nebo vybraných návrhových vzorů (kolektivní vlastnictví vzorů)

o Kódovací standard nebo kódovací konvence

Sociální zabezpečení programátora (Programmer welfare):

o 40hodinový pracovní týden (udržitelné tempo, čtyřicetihodinový týden)

Testování

XP se zaměřuje na dva typy testování:

testování modulů (testování jednotek);

Přijímací zkoušky.

Vývojář si nemůže být jistý správností kódu, který píše, dokud nefungují absolutně všechny unit testy systému, který vyvíjí. Unit testy umožňují vývojářům ověřit, že jejich kód funguje správně. Pomáhají také ostatním vývojářům pochopit, proč je potřeba konkrétní část kódu a jak funguje. Jednotkové testy také umožňují vývojáři bez obav refaktorovat.

Akceptační testy vám umožní ujistit se, že systém skutečně má deklarované schopnosti. Kromě toho akceptační testy umožňují zkontrolovat správné fungování vyvíjeného produktu.

Pro XP je prioritnější přístup zvaný TDD (Test Driven Development) - nejprve se napíše test, který neprojde, poté se napíše kód, aby test prošel, a poté se kód refaktoruje.

Plánovací hra

Hlavním cílem plánovací hry je rychle sestavit hrubý pracovní plán a neustále jej aktualizovat, jak se vyjasňují podmínky úkolu. Artefakty plánovací hry jsou sada papírových kartiček, které obsahují přání zákazníka (příběhy zákazníků) a hrubý pracovní plán pro vydání další jedné nebo více malých verzí produktu. Kritickým faktorem, který činí tento styl plánování efektivním, je, že v tomto případě je zákazník odpovědný za obchodní rozhodnutí a vývojový tým je odpovědný za technická rozhodnutí. Pokud se toto pravidlo nedodrží, celý proces se rozpadne.

Zákazník je tam vždy

„Zákazníkem“ v XP není ten, kdo platí účty, ale ten, kdo systém skutečně používá. XP tvrdí, že zákazník musí být neustále v kontaktu a k dispozici pro dotazy.

Párové programování

Párové programování předpokládá, že veškerý kód tvoří dvojice programátorů pracujících na stejném počítači. Jeden z nich pracuje přímo s textem programu, druhý se dívá na jeho práci a sleduje celkový obraz toho, co se děje. V případě potřeby se klávesnice volně přenáší z jedné na druhou. Při práci na projektu nejsou dvojice pevně dané: doporučuje se je smíchat, aby každý programátor v týmu měl dobrou představu o celém systému. Párové programování tedy zlepšuje interakci v týmu.

Průběžná integrace

Pokud svůj systém integrujete dostatečně často, můžete se vyhnout většině problémů s ním spojených. V tradičních metodách se integrace zpravidla provádí na samém konci práce na produktu, kdy se má za to, že všechny součásti vyvíjeného systému jsou zcela připraveny. V XP se kódová integrace celého systému provádí několikrát denně poté, co se vývojáři ujistili, že všechny testy jednotek fungují správně.

Refaktoring

Je to technika pro vylepšení kódu bez změny jeho funkčnosti. XP znamená, že jakmile je kód napsán, bude téměř jistě v průběhu projektu mnohokrát předělán. Vývojáři XP nemilosrdně přepracovávají dříve napsaný kód, aby jej vylepšili. Tento proces se nazývá refaktoring. Nedostatek testovacího pokrytí vyvolává odmítnutí refaktoringu kvůli obavám z prolomení systému, což vede k postupné degradaci kódu.

Častá malá vydání

Čím dříve uvolníme první pracovní verzi produktu, tím dříve z ní zákazník začne mít další zisk. Pamatujte, že peníze vydělané dnes mají větší hodnotu než peníze vydělané zítra. Čím dříve začne zákazník produkt používat, tím dříve od něj vývojáři dostanou informaci o tom, co splňuje požadavky zákazníka. Tyto informace mohou být velmi užitečné při plánování dalšího vydání.

Jednoduchost designu

XP vychází z toho, že v průběhu práce se podmínky problému mohou opakovaně měnit, což znamená, že vyvíjený produkt by neměl být předem zcela a kompletně navržen. Pokud se na samém začátku práce snažíte navrhnout systém detailně od začátku do konce, ztrácíte čas. XP naznačuje, že návrh je tak důležitý proces, že musí být prováděn nepřetržitě po celou dobu životnosti projektu. Návrh by měl být prováděn po malých krocích s ohledem na neustále se měnící požadavky. V každém okamžiku se snažíme použít nejjednodušší design, který vyhovuje aktuálnímu úkolu. Zároveň jej měníme tak, jak se mění podmínky problému.

Systémová metafora

Architektura je určitá představa o komponentách systému a o tom, jak jsou vzájemně propojeny. Vývojáři používají architekturu k tomu, aby pochopili, kde v systému jsou přidány nové funkce a s čím budou některé nové komponenty interagovat.

Výběrem dobré metafory usnadníte týmu pochopit, jak váš systém funguje. Někdy to není snadné.

Kódovací standardy

Všichni členové týmu musí v průběhu práce splňovat požadavky společných standardů kódování. Tím:

Členové týmu neztrácejí čas hloupými hádkami o věcech, které ve skutečnosti nemají vliv na rychlost práce na projektu;

Zajišťuje efektivní implementaci dalších postupů.

Pokud tým nepoužívá jednotné kódovací standardy, je pro vývojáře obtížnější refaktorovat; při střídání partnerů ve dvojicích je více obtíží; obecně je postup projektu obtížný. V rámci XP je nutné zajistit, aby bylo obtížné pochopit, kdo je autorem toho či onoho kódu - celý tým pracuje jednotně, jako jeden člověk. Tým musí vytvořit sadu pravidel a každý člen týmu musí tato pravidla během procesu kódování dodržovat. Seznam pravidel by neměl být vyčerpávající ani příliš obsáhlý. Úkolem je formulovat obecné pokyny, díky nimž bude kód srozumitelný pro každého z členů týmu. Standard kódování by měl být zpočátku jednoduchý, pak se bude vyvíjet, jak tým získá zkušenosti. Přednávrhem normy byste neměli trávit příliš mnoho času.

Kolektivní vlastnictví

Kolektivní vlastnictví znamená, že každý člen týmu je zodpovědný za celek zdroj. Každý má tedy právo provádět změny v jakékoli části programu. Párové programování podporuje tuto praxi: při práci v různých párech se všichni programátoři seznámí se všemi částmi kódu systému. Důležitou výhodou kolektivního vlastnictví kódu je, že urychluje proces vývoje, protože když se objeví chyba, může ji opravit každý programátor.

Tím, že dáváme každému programátorovi právo změnit kód, riskujeme, že zavedeme chyby od programátorů, kteří si myslí, že vědí, co dělají, ale neberou v úvahu některé závislosti. Dobře definované UNIT testy řeší tento problém: pokud nezkontrolované závislosti generují chyby, pak další běh UNIT testů selže.

Scrum je soubor principů, na kterých je založen vývojový proces, který umožňuje v pevně stanovených krátkých časových obdobích (sprinty od 2 do 4 týdnů) poskytnout koncovému uživateli fungující software s novými funkcemi, pro které je nejvyšší priorita. odhodlaný. Možnosti softwaru pro implementaci v dalším sprintu jsou určeny na začátku sprintu ve fázi plánování a nelze je měnit po celou dobu jeho trvání. Zároveň striktně fixní krátké trvání sprintu dává vývojovému procesu předvídatelnost a flexibilitu.

Hlavní herecké role ve Scrumu: ScrumMaster - ten, kdo vede jednání Scrumu a zajišťuje dodržování všech principů Scrumu (role neimplikuje nic jiného než správné chování samotného Scrumu, projektový manažer je spíše Vlastník produktu a neměl by být ScrumMaster); Product Owner - osoba, která zastupuje zájmy koncových uživatelů a dalších zájemců o produkt; a cross-funkční tým (Scrum Team), složený z vývojářů a testerů, architektů, analytiků atd. (velikost týmu je ideálně 7 ± 2 lidé). Tým je jediným plně zapojeným účastníkem vývoje a je zodpovědný za výsledek jako celek. Nikdo kromě týmu nemůže během sprintu zasahovat do vývojového procesu.

Během každého sprintu se vytváří funkční růst softwaru. Sada funkcí, které jsou implementovány v každém sprintu, pochází z fáze zvané produktový backlog (dokumentace pracovních požadavků), která má nejvyšší prioritu z hlediska úrovně pracovních požadavků, které musí být dokončeny. Položky backlogu identifikované během schůzky plánování sprintu se přesunou do milníku sprintu. Během této schůzky informuje Product Owner o úkolech, které je třeba splnit. Tým pak určí, kolik z toho chce dosáhnout, aby dokončil požadované části během dalšího sprintu. Během sprintu tým plní určitý pevný seznam úkolů (tzv. sprint backlog). Během tohoto období nemá nikdo právo měnit seznam požadavků na práci, což by mělo být chápáno jako zmrazení požadavků (požadavek) během sprintu.

_____________
matfak vgu a zbytek klasiky =)

Chcete-li psát komentáře, přihlaste se

Extreme Programming (XP) je jednou z flexibilních metodologií vývoje softwaru. Autory metodiky jsou Kent Beck, Ward Cunningham, Martin Fowler a další.

Plánovací hra

Náš svět je příliš proměnlivý a nepředvídatelný na to, abychom spoléhali na neměnnost situace. Totéž se děje při vývoji softwaru: o ojedinělém systému lze říci, že jeho finální podoba byla předem detailně známa již na samém počátku vývoje. Zákazníkův apetit obvykle přichází s jídlem: neustále chce něco měnit, něco zlepšovat a něco ze systému úplně vyhazovat. To je ta variabilita požadavků, které se všichni tak bojí. Naštěstí je člověku dána schopnost předvídat možné možnosti a tím udržet situaci pod kontrolou.
V extrémním programování je plánování nedílnou součástí vývoje a s tím, že plány se mohou měnit, se počítá od samého začátku. Tím opěrným bodem, technikou, která vám umožňuje předvídat situaci a bezbolestně se smířit se změnami, je hra plánování. V průběhu takové hry lze rychle shromažďovat známé systémové požadavky, vyhodnocovat je a plánovat jejich vývoj v souladu s prioritou.
Jako každá jiná hra má plánování své účastníky a svůj účel. Klíčovou postavou je samozřejmě zákazník. Je to on, kdo informuje o potřebě konkrétní funkce. Programátoři také poskytují přibližné hodnocení každé funkce. Krása hry plánování spočívá v jednotě účelu a solidarity mezi vývojářem a zákazníkem: v případě vítězství všichni vyhrají, v případě porážky všichni prohrají. Ale zároveň každý účastník jde k vítězství svým vlastním způsobem: zákazník si vybírá nejdůležitější úkoly v souladu s rozpočtem a programátor hodnotí úkoly v souladu se svými schopnostmi je realizovat.
Extrémní programování předpokládá, že vývojáři jsou schopni sami rozhodnout, jak dlouho se budou vyrovnávat se svými úkoly a kdo z nich by byl ochotnější řešit jeden problém a kdo ne.
V ideálním případě by se plánovací hra zahrnující zákazníka a programátora měla hrát každých 3-6 týdnů, před začátkem další iterace vývoje. Díky tomu je poměrně snadné provádět úpravy v souladu s úspěchy a neúspěchy předchozí iterace.

Plán vydání

Plán vydání definuje data vydání a uživatelský jazyk, který bude implementován v každém vydání. Na základě toho můžete zvolit formulaci pro další iteraci. Během iterace jsou vytvořeny akceptační testy a spuštěny v rámci této iterace a všech následných iterací, aby bylo zajištěno správná práce programy. Plán může být revidován v případě výrazného zpoždění nebo pokroku po výsledcích jedné z iterací.
Iterace. Iterace činí proces vývoje dynamickým. Své programovací úlohy nemusíte plánovat dlouho dopředu. Místo toho je lepší mít plánovací schůzku na začátku každé iterace. Nemá cenu zkoušet realizovat něco, co nebylo v plánu. Stále budete mít čas na realizaci těchto nápadů, až dojdou na řadu podle plánu vydání.
Tím, že si zvyknete nepřidávat funkce předem a použijete přímé plánování, se můžete snadno přizpůsobit měnícím se požadavkům zákazníků.

Plánování iterací

Plánování iterací začíná schůzkou na začátku každé iterace za účelem vytvoření plánu kroků k dosažení cílů programu. Každá iterace by měla trvat jeden až tři týdny. Výkazy v rámci iterace jsou seřazeny podle důležitosti pro zákazníka. Navíc jsou přidány úkoly, které neuspěly v akceptačních testech a je třeba je zlepšit. Výroky a výsledky testů jsou převedeny do programových úloh. Úkoly se píší na kartičky, které tvoří podrobný iterační plán. Vyřešení každého z úkolů trvá jeden až tři dny. Úkoly, které potřebují méně než jeden den, lze seskupit a velké úkoly lze rozdělit na několik menších. Vývojáři hodnotí úkoly a termíny jejich dokončení. Pro vývojáře je velmi důležité nastavit přesný čas provedení úkolu. Může být nutné přehodnotit některé jazyky a revidovat plán vydání po každých třech nebo pěti iteracích - to je docela přijatelné. Pokud nejprve implementujete nejdůležitější oblasti práce, pak budete mít vždy čas udělat pro své zákazníky maximum možného. Vývojový styl založený na posloupnosti iterací zlepšuje proces vývoje.

Stálá schůzka

Každé ráno probíhá porada, kde se probírají problémy, jejich řešení a zvyšuje se koncentrace týmu. Schůzka se koná ve stoje, aby se předešlo zdlouhavým diskusím, které nejsou zajímavé pro všechny členy týmu.
Na typickém setkání většina účastníků ničím nepřispívá, pouze se účastní, aby slyšela, co říkají ostatní. Velký početčas lidí je promarněn získáním malého množství komunikace. Účast všech lidí na poradách proto ubírá zdroje z projektu a vytváří chaos v plánování.
Pro tento druh komunikace je potřeba stálá schůzka. Je mnohem lepší mít jednu krátkou povinnou schůzku než mnoho dlouhých, kterých se většina vývojářů stejně musí zúčastnit.
Máte-li každodenní schůzky ve stoje, pak by se všech ostatních schůzek měli účastnit jen ti lidé, kteří jsou potřební a něco přinesou. Navíc je možné se některým schůzkám dokonce vyhnout. S omezeným počtem účastníků lze většinu setkání konat spontánně před monitorem, kde je výměna nápadů mnohem intenzivnější.
Každodenní ranní setkání není jen další ztráta času. Umožní vám to vyhnout se mnoha dalším schůzkám a ušetří vám více času, než zbytečných.

Jednoduchost

Jednoduchý návrh vždy zabere méně času než složitý. Vždy tedy dělejte ty nejjednodušší věci, které mohou jedině fungovat. Vždy je rychlejší a levnější nahradit složitý kód hned, než na něm strávíte spoustu času prací. Udržujte věci tak jednoduché, jak je to jen možné, aniž byste museli přidávat funkce, než se to naplánuje. Mějte na paměti: udržet jednoduchý design je těžká práce.

Metaforický systém

Volba systému metafor je nutná k udržení týmu ve stejném rámci při pojmenovávání tříd a metod. Jak pojmenujete své objekty, je velmi důležité pro pochopení celkového návrhu systému a opětovného použití kódu. Pokud je vývojář schopen správně odhadnout, jak by mohl být pojmenován existující objekt, šetří to čas. Použijte pro své objekty systém pojmenování, kterému bude rozumět každý bez konkrétních znalostí systému.

Zákazník na pracovišti

Hlavním problémem vývoje softwaru je nedostatek znalostí programátorů ve vývoji předmětová oblast. Extrémní programování našlo východisko i z této situace. Ne, nejedná se o vývojářskou stáž u zákazníka – pak nebude chtít programovat. Naopak je to účast zákazníka na procesu vývoje.
Jak může programátor, aniž by důkladně pochopil podstatu problému a nebyl telepat, odhadnout, co zákazník chce? Odpověď je zřejmá. Nejjednodušší způsob, jak překonat tuto nepříjemnost – a extrémní programování nás učí najít nejvíce jednoduchá řešení- položí zákazníkovi přímou otázku. Důslednější přístupy vyžadují komplexní předběžnou analýzu rozvíjené oblasti. V určité případy je to oprávněné, i když je to dražší. Reálné zkušenosti s prováděním světských projektů ukazují, že není možné shromáždit všechny požadavky předem. Navíc, i když předpokládáme, že všechny požadavky jsou aktuálně shromážděny, stále bude existovat jedno úzké hrdlo: programy, stejně jako vše v přírodě, nejsou vytvářeny okamžitě a mezitím se mohou obchodní procesy změnit. To je třeba vzít v úvahu.
Mnozí pochybují o možnosti zapojení zákazníka do procesu vývoje. Zákazníci jsou skutečně různí. Pokud není možné přilákat zákazníka nebo jeho zástupce, má někdy smysl dočasně najmout specialistu na rozvíjenou oblast. Takový krok sníží nejasnosti v práci, zvýší rychlost vývoje a přiblíží projekt tomu, co chce zákazník dostat. To může být přínosné i z finanční stránky: vždyť plat programátora někdy výrazně převyšuje plat specialistů v jiných odvětvích.
uživatelský příběh. User Story (něco jako uživatelský příběh) je popis toho, jak by měl systém fungovat. Každý uživatelský příběh je napsán na kartě a představuje určitou část funkce systému, která dává z pohledu zákazníka logický smysl. Formulář je jeden nebo dva odstavce textu, který je pro uživatele srozumitelný (nepříliš technický).
Uživatelský příběh je napsán Zákazníkem. Jsou podobné případům použití pro systém, ale nejsou omezeny na uživatelské rozhraní. Pro každý příběh jsou napsány funkční testy, které to potvrzují tento příběh správně implementovány – nazývají se také akceptační testy.

Testování před vývojem

Testování v klasickém slova smyslu je poměrně nudná procedura. Obvykle najímají testera, který pravidelně provádí stejné akce a čeká na den, kdy je konečně převeden na jinou pozici nebo existuje příležitost změnit zaměstnání.
V extrémním programování je role testování zajímavější: nyní je na prvním místě test a poté kód. Jak můžete testovat něco, co ještě neexistuje? Odpověď je jednoduchá a banální: otestujte si své myšlenky – co lze očekávat od budoucího softwaru nebo funkcí. To vám umožní lépe porozumět tomu, co programátoři musí udělat, a zkontrolovat funkčnost kódu, jakmile je napsán.
Ale ani test nemusí fungovat. Co napsat test na test? A pak testovat na test a tak dále do nekonečna? Vůbec ne. Test pro test nahradí kód. Jak to? Ale podívejte se: představte si, že potřebujete upevnit matici uprostřed šroubu, aby se neotáčela. co pro to dělají? Přišroubujte druhou matici těsně k první tak, aby každá matice zabránila otáčení další matice. V programování je to stejné: test testuje kód a kód testuje test.
Praxe ukazuje, že tento přístup nejen nezpomaluje, ale také urychluje vývoj. Koneckonců, vědět, co je třeba udělat, a požadované množství práce ušetří čas tím, že odmítnete implementovat nevyžádané tento moment podrobnosti.

Párové programování

Veškerý kód pro produkční systém je napsán ve dvojicích. Dva vývojáři sedí vedle sebe. Jeden vytáčí, druhý hlídá. Čas od času se mění. Není dovoleno pracovat samostatně. Pokud z nějakého důvodu druhý z dvojice něco zmeškal (byl nemocný, odešel atd.), je povinen zkontrolovat všechny změny provedené prvním.
Zní to nezvykle, ale po krátké době přizpůsobení většina lidí funguje skvěle ve dvojici. Dokonce se jim to líbí, protože práce jde znatelně rychleji. Platí zásada „Jedna hlava je dobrá, ale dvě jsou lepší“. Páry většinou najdou optimálnější řešení. Kromě toho se výrazně zvyšuje kvalita kódu, snižuje se počet chyb a zrychluje se výměna znalostí mezi vývojáři. Zatímco jedna osoba se zaměřuje na strategický pohled na objekt, druhá osoba implementuje jeho vlastnosti a metody.

Změna pozic

Během další iterace by měli být všichni pracovníci přesunuti do nových oblastí práce. Takové pohyby jsou nezbytné, aby se zabránilo izolaci znalostí a odstranění úzkých míst. Zvláště plodná je výměna jednoho z vývojářů v párovém programování.

Kolektivní vlastnictví kódu

Kolektivní vlastnictví kódu povzbuzuje vývojáře, aby předkládali nápady pro všechny části projektu, nejen pro své vlastní moduly. Každý vývojář může změnit jakýkoli kód a přidat funkce a opravit chyby.
Na první pohled to vypadá jako chaos. Nicméně, vezmeme-li v úvahu, že alespoň jakýkoli kód je vytvořen několika vývojáři, tyto testy vám umožňují zkontrolovat správnost Změny a co je uvnitř reálný život tak či onak musíte rozumět cizímu kódu, je jasné, že kolektivní vlastnictví kódu značně zjednodušuje zavádění změn a snižuje riziko spojené s vysokou specializací toho či onoho člena týmu.

Kódovací konvence

Jste v týmu, který na tomto projektu pracuje? dlouho. Lidé přicházejí a odcházejí. Nikdo nekóduje sám a kód patří všem. Vždy budou chvíle, kdy bude nutné porozumět a opravit cizí kód. Vývojáři odstraní nebo změní duplicitní kód, analyzují a vylepší třídy jiných lidí a tak dále. Časem nebude možné zjistit, kdo je autorem konkrétní třídy.
Proto se každý musí řídit běžnými standardy kódování – formátování kódu, třída, proměnná, konstantní pojmenování, styl komentáře. Budeme tak mít jistotu, že změnami v cizím kódu (které jsou nezbytné pro agresivní a extrémní pokrok vpřed) z něj neuděláme babylonské pandemonium.
Výše uvedené znamená, že všichni členové týmu se musí dohodnout na společných standardech kódování. Je jedno co. Platí pravidlo, že je všichni dodržují. Kdo je nechce dodržovat, tým opouští.

Častá integrace

Vývojáři, pokud je to možné, by měli integrovat a vydávat svůj kód každých několik hodin. V žádném případě byste změny nikdy neměli uchovávat déle než jeden den. Častá integrace zabraňuje odcizení a fragmentaci ve vývoji, kde vývojáři nemohou komunikovat ve smyslu výměny nápadů nebo opětovného použití kódu. Každý musí pracovat s Nejnovější verze.
Každá dvojice vývojářů by měla rozdat svůj kód, jakmile k tomu bude rozumná příležitost. To může být, když všechny UnitTests projdou 100%. Odesíláním změn několikrát denně snížíte problémy s integrací téměř na nic. Integrace je aktivita typu „zaplať teď nebo plať víc později“. Proto díky každodenní integraci změn po malých částech nebudete muset strávit týden spojováním systému těsně před dodáním projektu. Vždy pracujte na nejnovější verzi systému.

Čtyřicetihodinový pracovní týden

Člověk, zvláště je-li programátor, je schopen udělat hodně kvůli podnikání: zůstat v práci, jít do práce na víkend, odmítnout si vzít dovolenou, zůstat několik dní vzhůru, sedět u klávesnice. .. Obecně platí, že kvůli své oblíbené zábavě nemůžete dělat nic. Ale extrémní programování je kategoricky proti takovému sebeobětování a porušování přijatých pracovněprávních norem.
To je diktováno nejen ohledy na zákonnost a lidskost, ale především nutností zvýšit efektivitu práce a přísnou organizaci. Koneckonců, extrémní programování je kolektivní hra, určená ne pro jednotlivce, ale pro celou skupinu jako celek. A něco takového, jako je například párové programování, je možné pouze tehdy, jsou-li biorytmy jeho účastníků synchronizovány. A je nemožné, když jeden přijde do práce v devět a druhý ve dvanáct, nebo se někdo rozhodne, že je pro něj lepší pracovat v sobotu a neděli, zatímco druhému je to nepříjemné.
Ale hlavně, aby si člověk udržel zdraví a výkonnost, potřebuje pořádný odpočinek. Osmihodinový pracovní den a pětidenní pracovní týden jsou stanoveny právě z důvodu maximální produktivity. V mnoha západních firmách je pozdní odchod z práce považován za špatný akademický výkon nebo neschopnost řádně řídit svou pracovní dobu. Ve většině případů je to pravda. Ano, a z lékařského hlediska vedou prodlevy v práci k neustálé únavě, podrážděnosti a snížené mozkové aktivitě. Je to účinné? Jak ale zorganizovat neustálou otevřenou komunikaci mezi vývojáři v takovém týmu a bude možné párové programování? Odpověď je záporná. Pravidla jsou pravidla a měla by se dodržovat.

Závěr

Tyto techniky nejsou spojeny náhodou. Jejich důsledná kombinace dokáže uvést vývojový proces do intelektuální rezonance, výrazně zlepšit kvalitu produktu a přiblížit dobu jeho uvedení na trh. Hlavní krásou celého extrémního programování je předvídatelnost a minimalizace nákladů na vývoj; poskytnout zákazníkovi produkt, který chce obdržet v okamžiku vydání; a samozřejmě komunikace a školení vývojářů na pracovišti.

Bibliografie:

Extrémní programování: vývoj řízený testem

Věnováno Cindy: křídla mé duše

Publikační práva získaná na základě dohody s Addison-Wesley Longman. Všechna práva vyhrazena. Žádná část této knihy nesmí být reprodukována v žádné formě bez písemného souhlasu držitelů autorských práv.

Informace obsažené v této knize byly získány ze zdrojů, které vydavatel považuje za spolehlivé. Avšak s ohledem na možné lidské resp technické chyby, vydavatel nemůže zaručit absolutní správnost a úplnost poskytnutých informací a nenese odpovědnost za případné chyby spojené s užitím knihy.

ISBN 978-0321146533

ISBN 978-5-496-02570-6

Úvodní slovo

Čistý kód, který funguje(čistý kód, který funguje), - v této krátké, ale smysluplné frázi, kterou vytvořil Ron Jeffries, spočívá celý smysl Test-Driven Development (TDD). Čistý kód, který funguje, je cílem, o který stojí za to usilovat, protože

Toto je předvídatelný způsob vývoje programů. Víte, kdy lze práci považovat za dokončenou, a nestarat se o dlouhou řadu chyb;

Dává šanci naučit se lekce, které kód učí. Pokud použijete první nápad, který vás napadne, nebudete mít šanci realizovat druhý, lepší nápad;

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

Umožňuje vašim kolegům spolehnout se na vás a vy na ně;

Je příjemnější napsat takový kód.

Ale jak získáte čistý kód, který funguje? Mnoho sil nám brání získat čistý kód a někdy ani nemůžeme získat kód, který prostě funguje. Abychom se zbavili spousty problémů, vyvineme kód založený na automatizovaném testování. Tento styl programování se nazývá vývoj řízený testováním. Podle této metodiky

Nový kód je zapsán až poté, co je napsán automatický test, končící neúspěchem;

Jakákoli duplicita je vyloučena.

Dva jednoduchá pravidla, Není to ono? Vytvářejí však složité individuální a skupinové chování s mnoha technickými důsledky:

Během procesu návrhu neustále spouštíme kód a získáváme představu o tom, jak to funguje, což pomáhá činit správná rozhodnutí;

Testy píšeme sami, protože nemůžeme čekat, až za nás testy napíše někdo jiný;

Naše vývojové prostředí musí rychle reagovat na malé úpravy kódu;

Návrh programu by měl být založen na použití mnoha samostatných, volně propojených komponent, aby se usnadnilo testování kódu.

Dvě zmíněná pravidla TDD definují pořadí programovacích kroků.

1. Červená - napište malý test, který nefunguje, nebo se možná ani nezkompiluje.

2. Zelená – udělejte testovací běh co nejrychleji, bez přemýšlení o správném designu a čistotě kódu. Napište jen tolik kódu, aby test fungoval.

3. Refaktoring - odstranění duplicit z napsaného kódu.

Red-Green-Refactoring je TDD mantra.

Za předpokladu, že je tento styl programování možný, lze předpokládat, že díky jeho použití bude kód obsahovat podstatně méně defektů, navíc bude všem, kdo se na něm podílí, jasný účel práce. Pokud ano, pak vývoj pouze kódu potřebného k úspěšnému složení testů má také sociální důsledky:

S dostatečně nízkou hustotou defektů bude tým pro zajišťování kvality (QA) schopen přejít od reakce na chyby k prevenci;

S poklesem počtu nepříjemná překvapení projektoví manažeři budou schopni přesněji odhadnout mzdové náklady a zapojit zákazníky do procesu vývoje;

Pokud budou témata technických diskusí jasně definována, programátoři budou moci spolu neustále komunikovat, a ne jednou denně nebo jednou týdně;

Opět, s dostatečně nízkou hustotou defektů, budeme moci každý den získat integrovaný pracovní produkt s přidanou novou funkčností, abychom mohli vstoupit do zcela nového typu obchodního vztahu s našimi zákazníky.

Myšlenka je tedy jednoduchá, ale co nás zajímá? Proč by měl programátor přebírat další zodpovědnost za psaní automatických testů? Proč by se měl programátor posouvat vpřed po malých krůčcích, když jeho mozek dokáže vymyslet mnohem složitější strukturu návrhu? Udatnost.

Udatnost

TDD je způsob, jak zvládat strach při programování. Nemyslím tím strach z pádu ze židle nebo strach ze svého šéfa. Mám na mysli strach z úkolu „tak těžkého, že zatím netuším, jak ho vyřešit“. Bolest je, když nám příroda říká: "Stop!", a strach je, když nám příroda říká: "Buďte opatrní!" Opatrnost není vůbec špatná, ale kromě výhod má na nás strach i určitý negativní dopad:

Strach nás nutí přemýšlet dopředu a pečlivě, k čemu ta či ona akce může vést;

Strach nás nutí méně komunikovat;

Ze strachu se bojíme zpětné vazby na naši práci;

Strach nás činí podrážděnými.

Nic z toho není užitečné pro proces programování, zvláště pokud pracujete na složitém problému. Stojíme tedy před otázkou, jak z těžké situace ven

Nesnažte se předpovídat budoucnost, ale okamžitě začněte s praktickým studiem problému;

Ne oplotit se před zbytkem světa, ale zvýšit úroveň komunikace;

Nevyhýbat se odpovědím, ale naopak navázat spolehlivé zpětná vazba a s její pomocí pečlivě kontrolovat výsledky svých činů;

(S podrážděním se musíte vypořádat sami.)

Porovnejte programování se zvedáním kbelíku ze studny. Kbelík se naplní vodou, otočíte pákou, namotáte řetízek kolem obojku a zvednete kbelík nahoru. Pokud je kbelík malý, postačí běžná, volně se otáčející brána. Pokud je ale kbelík velký a těžký, budete unavení, než ho zvednout. Aby bylo možné spočinout mezi otáčkami páky, je zapotřebí rohatkový mechanismus, který umožní páku zablokovat. Čím těžší je kbelík, tím častěji by měly následovat zuby na ráčnovém převodu.

Testy v TDD jsou zuby na ráčnovém ozubeném kole. Tím, že test funguje, víme, že test funguje nyní, nyní a navždy. Jsme o krok blíže k dokončení, než jsme byli před spuštěním testu. Poté zpracujeme druhý test, pak třetí, čtvrtý a tak dále. těžší problém tváří v tvář programátorovi, tím méně funkčnost by měl pokrývat každý test.

čtenáři knih Extrémní programování vysvětleno si museli všimnout rozdílu v tónu mezi extrémním programováním (XP) a vývojem řízeným testováním (TDD). Na rozdíl od XP není metodika TDD absolutní. XP říká: "Abyste mohli jít dál, musíte zvládnout to a to." TDD je méně specifická technika. TDD předpokládá, že mezi učiněním rozhodnutí a obdržením výsledků existuje určitý interval, a poskytuje nástroje pro řízení trvání tohoto intervalu. „Co když navrhnu algoritmus na papíře po dobu jednoho týdne a poté napíšu kód pomocí přístupu nejprve test? Bude se hodit k TDD?" Samozřejmě, že bude. Znáte interval mezi rozhodnutím a vyhodnocením výsledků a tento interval vědomě řídíte.

Většina lidí, kteří zvládli TDD, tvrdí, že se jejich programovací postupy změnily k lepšímu. Nakaženo testy(test infikováno) je definice, kterou vytvořil Erich Gamma k popisu této změny. Jakmile zvládnete TDD, zjistíte, že píšete podstatně více testů, než jste byli zvyklí, a pohybujete se vpřed po malých krůčcích, které by vám dříve připadaly zbytečné. Na druhou stranu, někteří programátoři se po seznámení s TDD rozhodnou vrátit se ke starým postupům a vyhradit si TDD pro speciální případy, kdy konvenční programování nevede k požadovanému pokroku.

Jistě existují problémy, které nelze (alespoň prozatím) vyřešit pouze testy. TDD zejména neumožňuje mechanicky prokázat adekvátnost vyvinutého kódu z hlediska bezpečnosti dat a spolehlivosti paralelních operací. Zabezpečení je samozřejmě založeno na kódu, který by neměl být vadný, ale je také založen na lidské účasti na postupech ochrany dat. Jemné problémy souběžnosti nelze s jistotou reprodukovat pouhým spuštěním nějakého kódu.

V poslední době se mezi vývojáři softwaru stala
populární technologie zvaná "extrémní programování" nebo XP. O
je napsáno mnoho článků a knih, které poskytují představu o teoretických základech
tuto metodiku. Rád bych vám řekl, jak to vypadá v praxi, a
jaké jsou výhody a nevýhody

Za prvé, co je XP? Na internetu najdete spoustu definic a popisů
tento výraz. V zásadě každý z nich více či méně adekvátně odráží podstatu
jevů, ale rozmanitost definic může vývojáře zmást. Proto je nutné
pochopit, že XP je soubor technik vyvinutých k potlačení
proces vývoje softwaru čtyři základní principy. A to:

sdělení;
jednoduchost;
Zpětná vazba;
udatnost.

Obvykle jsou v materiálech na XP tyto techniky konkretizovány. Zde je nejvíce
typický seznam:

Plánovací hra;
Testování před vývojem;
Párové programování;
Neustálé zpracování;
Snadný vývoj;
Kolektivní vlastnictví kódu;
Pokračující integrace;
Zákazník na pracovišti;
Rychlé vydání verzí;
Čtyřicetihodinový pracovní týden;
Kódovací standardy;
systémová metafora.

Vyjádřím se pouze k některým technikám, protože význam většiny z nich
zcela jasné z názvu a podrobně popsané v literatuře. Někteří z nich
metody se zdají celkem logické, některé naopak způsobují zmatek.

Plánovací hra Myšlenka této techniky je poměrně jednoduchá. Vývojáři spolu s
zákazníci se sejdou a rozehrají některé možné situace (v
ideálně všechny), které mohou nastat při řešení problému v životě. Taková setkání
je žádoucí zařídit před zahájením vývoje každého subsystému, to znamená udělat
je to běžné během celého procesu vývoje. To neumožňuje
zapojit se do vývoje podle přísného plánu a včas se přizpůsobit
změny v předmětné oblasti.

Testování před vývojem. Očekává se, že před voj
jakýkoli fragment programu, je pro něj napsán test. To poskytuje řadu výhod.
Za prvé se stává, že jedna změna v jednom kusu kódu znamená
chyby u ostatních. Tento přístup k testování vám umožňuje okamžitou identifikaci
takové situace. Za druhé, pro zákazníka je pohodlnější vizuálně vidět, že test funguje,
než číst velké objemy dokumentace. Proto výsledek testu
je třeba vizualizovat.

systémová metafora. Vyvinuté produkty nebo úryvky kódu jsou porovnávány s
jakékoli podobné produkty nebo jevy. Budují se metafory. Tento
zjednodušuje pochopení úkolu, a tudíž urychluje vývoj.

Ale musíte také pochopit, že pokud z nějakého důvodu
kterákoli z těchto technik začíná jít proti základním principům XP a
takové situace jsou docela možné, pak by se od toho mělo upustit.

Upřímně řečeno, navzdory skutečnosti, že před začátkem popsaných událostí I
měl základní znalosti o extrémním programování, ale v procesu
vývoj aplikace, o které vám chci říci, vědomě dodržovat
Metody XP jsem nezkoušel. To je však podle mého názoru typické
Příklad XP. V každém případě bylo dosaženo pozitivního výsledku.

Nyní se podívejme, jak lze XP přístupy použít v praxi
naše podmínky. Jedním z mých úkolů v práci je automatizace školení
proces. Ve skutečnosti jsem docela dlouho
Píšu aplikaci, která implementuje (alespoň podle návrhu
autor :)) komplexní řešení tohoto problému. Rozpočet projektu je mizivý a objem
práce je slušná. Dalším, téměř rozhodujícím faktorem byla konstanta
úprava předmětné oblasti. Formuláře hlášení se pravidelně mění
dokumentaci a jak ji získat. Nastala situace, kdy se projekt zastavil
držet krok s požadavky uživatelů. A jednoho dne přišel okamžik, kdy
objektivních i subjektivních důvodů mohl být vývoj bezpečně pohřben. nicméně
nečekaně jsem dostal konkrétní úkol určit
náplň třídního fondu na semestr. V tuto chvíli ze tří účastníků
Z projektu jsem zůstal jediný, ale tento subsystém nebyl implementován a jeho implementace
nebyl ani v bezprostředních plánech rozvoje projektu. O maličkostech jako
kompetentní vyjádření problému, výpočet pracnosti práce, přidělení
nikdo ani nepomyslel na další zdroje. Dokončení úkolu bylo
dány dva týdny. Zároveň mé argumenty ohledně nemožnosti exekuce
tato otázka nebyla vůbec zvažována. Moje první rozhodnutí bylo najít
jiného zaměstnavatele, jelikož za dva týdny jsem musel psát nejen
modul pro rozbor vytíženosti třídního fondu, ale také systém pro zadávání rozvrhu
třídy, kontrola překrytí a mnoho dalšího. Samostatně, tento úkol není vyřešen
v zásadě - potřebujete původní údaje. A nejen původní údaje, ale ty správné
výchozí data, ze kterých vyplývají všechny výše uvedené úkoly. Nicméně,
Nevím proč, ale tuhle výzvu jsem přijal.

Samozřejmě, co mluvit o vývoji klasických metod v tomto případě
nemístný. Zde se hodí XP přístupy. Obecná představa o úkolu
už měl, ale bylo tam mnoho nuancí, které by potenciálně mohly
výrazně zvýšit objem práce. Začal jsem pracovat vytočením čísla
vzdělávacího oddělení a začali bombardovat osobu, která telefonovala, spoustou otázek, odpovědí na
které jsem nemohl najít sám nebo kterými jsem si nebyl jistý.
.
Spustil jsem Rational Rose a začal stavět model. Do konce pracovního dne
Načrtl jsem model, který se mi zdál víceméně adekvátní. Po práci I
udělal další krok v souladu s ideologií XP. Vytáhl jsem kamaráda ven
pracující ve výcvikovém oddělení k pití piva. V tomto procesu, důležité ve všech
vztahy akce, vysvětlil jsem mu svou vizi programu, jeho rozhraní a
pracovní logiku. Ten na oplátku začal mluvit o potřebě
řešení některých lokálních dílčích problémů. K večeru jsem jasněji pochopil co
je ještě potřeba udělat v rámci tohoto projektu (už jsem nepochyboval, že úkol
by měl být považován za samostatný projekt). Další však není vyřešen
ne nedůležitou otázkou je výběr vývojových nástrojů. Kdy bylo popsáno
události jsem začal aktivně studovat technologii MDA. Stručně řečeno, podstatou je toto:
úryvky kódu aplikace a datové struktury jsou automaticky generovány na základě
z modelu UML, což může výrazně zkrátit dobu vývoje. Jako část
v tomto článku nebudu podrobně popisovat principy MDA, ale chci
upozornit na skutečnost, že použití této technologie je zcela
reaguje na "duch XP". Je to dáno tím, že jednou z podmínek, za kterých
Metody XP budou úspěšně fungovat, jde o snížení nákladů na provedené změny
aplikace v pozdějších fázích vývoje. Mezi faktory přispívající
k dosažení toho není nedůležité používat různé nové
programovací technologie. Podotýkám, že je to právě jednoduchost refaktoringu MDA
aplikací je jednou z hlavních výhod této technologie. Obecně, na
dnes je implementací MDA docela dost, vybral jsem si
Tučné pro Delphi.

Ale v mé situaci bylo pár „kluzkých momentů“. Za prvé, uvědomit si to
MDA poskytuje určité výhody, stále si nejsem dost jistý
vlastnil tuto technologii a neměl prakticky žádné zkušenosti s psaním aplikací MDA.
Za druhé jsem pochopil, že některé úryvky kódu by byly problematické
implementováno pomocí standardních nástrojů MDA a existuje spousta „příruček
kódování“, které v tomto případě bude mít určitá specifika.

Alternativou bylo napsat "běžnou" aplikaci Delphi. Spustil jsem
ICQ a napsal zprávu svému příteli - Tučnému přívrženci. Potom já
stručně mu nastínil podstatu problému, zeptal jsem se ho, co by na mém místě udělal on.
Odpověděl asi takto: „Buď se ponořte po hlavě do Boldu, nebo
nikdy to nezvládneš. Udělejte seriózní projekt - Nejlepší způsob prozkoumat
technika." Vlastně jsem ani nečekal jinou odpověď.

Ráno jsem vzal stávající model a začal sestavovat aplikaci. To je pravda, stavět. NA
Nezačal jsem kódovat, ale jen skicoval uživatelské rozhraní, mnoho
prvky, které téměř okamžitě získaly. Na kouřové přestávce jsem se pokusil jít ven
společnosti zaměstnanců školicího oddělení, to mi umožnilo přetáhnout další
"oběť" na obrazovku svého monitoru a (ne bez jisté hrdosti) ukázal
mezivýsledky. Tím byl implementován princip zpětné vazby.
Můžete právem říci: "A co párové programování?". Ano,
skutečně jsem byl jediný, kdo se do projektu zapojil jako programátor. Ale jsem tady
Zmíním ještě jednu šťastnou náhodu. Během toho časového období
když k popisovaným událostem došlo, já spolu se skupinou vývojářů -
nadšenci vyvinuli internetový projekt věnovaný MDA. A tehdy já
se přiblížil k nejobtížnějšímu místu ve svém vývoji, které tento projekt přinesl
zcela nečekané výsledky.

Několik dní jsem psal kód pro proceduru, která implementuje zobrazení aktivit
na obrazovce. Standardní ovládací prvky neumožňovaly zobrazit všechny
údaje ve formě, ve které jsou obvykle prezentovány. To jsem chtěl
koncový uživatel by alespoň přibližně pochopil, co program dělá
a jak s tím pracovat. Napsal jsem svou komponentu na základě obvyklého TStringGrid.
Nebyl jsem si jistý, co to bylo dobré rozhodnutí ale kód fungoval. Na fóru
o našem projektu, uvedl jsem své rozhodnutí v očekávání, že v rámci něj obdržím nějaký druh hodnocení
dostatečně dlouhou dobu. Přišlo však doslova za 15-20 minut
první odpověď. nabídl Alternativní možnost roztoků a po dalších 10 minutách
přišel testovací příklad, ale ne jeden, ale hned dva, od dvou autorů. Li
zamyslet se nad tím, proč vývojáři s takovým nadšením začali řešit
problém někoho jiného, pak můžete dojít k jednoduchému závěru. Za prvé, oni prostě
zajímavé najít nějaké řešení na jednom místě, který pak může
použít ve svých projektech. A za druhé se zajímali o samotný proces
sdělení. Nutno podotknout, že se stejným nadšením byly řešeny i další úkoly.
různé úrovně složitosti. Samozřejmě se nejedná o párové programování
běžné porozumění. Spíše je to druh náhražky, ale přesto existuje
jeho výhody. Řekněme, že všechny vyjádřené myšlenky a nápady automaticky
byly zdokumentovány a mohly být kdykoli zpřístupněny.

Rád bych se zastavil u testů samostatně. Jak doporučuje v jeho knize
"Extreme Programming" Kent Beck, Testy musí být napsány předem. Více
Navíc autor vypadá nějak takto. Existuje speciální program
napsaný samotným vývojářem, když kliknete na jedno z jeho tlačítek
všechny testy jsou spuštěny a v důsledku toho se na obrazovce objeví zelená „žárovka“.
v případě pozitivního výsledku a červená jinak. Já takový popis
poněkud sklíčený. Souhlas, je těžké si představit jak
je možné napsat program, který naprosto ve všem napodobuje akce uživatele
situace.

Jak jsem řekl, nesnažil jsem se striktně dodržovat metody extrému
programování. A v knihách, které jsem četl, to bylo jednoznačně uvedeno
psaní testu je jedna z nejdůležitějších věcí v XP a bez něj zbytek
metody by neměly fungovat. Proč jsem byl nakonec pozitivní?
výsledek? Všechno se ukázalo být docela jednoduché. Pomohl mi odpovědět na tuto otázku
jen tento příklad se zelenými a červenými žárovkami. Faktem je, že v Bold
je možné ukázat, zda daný objekt modely. A
to se děje právě pomocí takových "žárovek". Doslova dva řádky
který jsem téměř okamžitě vložil do kódu aplikace, mi umožnil vidět, ve kterém
kde dojde k neshodě (pokud existuje). To je to, co nahradilo
já testuji. Je možné, že tento přístup není zcela konzistentní
původní myšlenka „test před vývojem“, ale fungovala.

O týden později jsem měl téměř hotovou aplikaci. Během druhého
týdnech jsem udělal další dvě verze, ve kterých jsem vážně rozšířil funkčnost a
také provedl import většiny dat nezbytných pro práci z jiných
pracovní systémy. Problém byl vyřešen a z velké části díky používání
XP metody. Smysl všeho výše uvedeného vidím pouze v tom, že tento příklad na
V praxi prokázal efektivitu extrémního programování.

Na závěr si dovolím ještě jednu poznámku. extrémní programování,
podle mého názoru to není všelék. A její metody lze aplikovat daleko
pro jakýkoli projekt. V zásadě uvažovaný projekt podle některých funkcí
byl zařazen právě do té kategorie projektů, kde se nedoporučuje používat XP.
Při flexibilnějším přístupu však použití extrému
programování může přinést velmi překvapivé výsledky. Při čtení
knihy zahraničních autorů na toto téma, od tuzemského čtenáře
lze vytvořit názor, že metody XP v zásadě nelze použít
naše podmínky. A nejde jen o to, že vztah mezi vývojáři a
zákazníky, ale i vztahy ve vývojovém týmu, popsané v knihách
příklady jsou postaveny na trochu jiných principech. Jde spíš o ten rozdíl
mentalita. Adaptace XP na naše podmínky je však docela možná a může
poskytují velmi působivé výsledky.

http://xprogramming.com.ua/ - svět
extrémní programování

http://www.xprogramming.ru/ -
extrémní programování v ruštině

http://www.maxkir.com/ - o vývoji
software

http://xprogramming.com/ – webové stránky
Ideolog XP Ron Jeffries