Extrémní programování ( Extreme Programming , XP ) je jednou z agilních metodik vývoje softwaru . Autory metodiky jsou Kent Beck , Ward Cunningham , Martin Fowler a další.
Název metodiky vychází z myšlenky aplikovat užitečné tradiční metody a postupy vývoje softwaru a posouvat je 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 píše kód a jeho partner na zároveň neustále kontroluje, jaký napsaný kód.
Metodiku vyvinul Kent Beck během své práce na projektu mzdové agendy Chrysler Comprehensive Compensation System (C3) . Beck se stal hlavním projektovým specialistou v březnu 1996. Začal vylepšovat vývojovou metodiku použitou v projektu a napsal o tom knihu Extreme Programming Explained (vyšla v říjnu 1999). [1] Projekt byl uzavřen v únoru 2000.
Dvanáct základních technik extrémního programování (podle prvního vydání Extrémního programování vysvětleno ) lze seskupit do čtyř skupin:
XP zahrnuje psaní automatických testů (kód napsaný speciálně pro testování logiky jiného kódu). Zvláštní pozornost je věnována dvěma typům testování:
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 je logika testovaného kódu jasná, protože je jasné, jak by měl být používán. 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 působivých velikostí) částí. Jsou méně podrobné než testy jednotek, ale pokrývají mnohem více – tedy testy, které při svém spuštění ovlivní větší množství kódu, mají samozřejmě větší šanci odhalit jakékoli nesprávné chování. Z tohoto důvodu má v průmyslovém programování psaní funkčních testů často přednost před psaním jednotkových testů.
Pro XP má vyšší prioritu přístup zvaný TDD (z anglického test-driven development - development through testing ). 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ám 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šší postarat se o pohodlí budoucího systému.
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íkem“ v XP není ten, kdo platí účty, ale konečný uživatel softwarového produktu. XP tvrdí, že zákazník musí být neustále v kontaktu a k dispozici pro dotazy.
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.
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 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.
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í.
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.
Kent Beck a Martin Fowler [2] navrhují popsat „jednoduchý design“ jako splnění následujících čtyř kritérií:
Robert Martin souhlasí [3] s těmito pravidly, ale ve své dřívější práci [4] také navrhuje popisovat „jednoduchý design“ s následujícími třemi principy:
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é.
V tuto chvíli Bob Martin uznal, že systémová metafora je zastaralá a měla by být nahrazena Domain Driven Design .
Všichni členové týmu v průběhu práce musí splňovat požadavky společných standardů kódování. Tím:
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 potřeba ztížit pochopení, kdo je autorem toho či onoho kódu – celý tým funguje jednotně, jako jeden člověk. Tým musí vytvořit sadu pravidel a každý člen týmu musí tato pravidla při psaní kódu 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 může postupně s tím, jak bude vývojový tým získávat zkušenosti, stát složitějším. Není třeba trávit příliš mnoho času předvypracováním normy.
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.
Právo každého programátora na změnu kódu podstupuje riziko, že chyby zavedou programátoři, kteří si myslí, že vědí, co dělají, ale neberou v úvahu některé závislosti. Extrémní programátoři věří, že dobře definované testy jednotek tento problém řeší: pokud nezkontrolované závislosti generují chyby, pak další běh unit testů selže a odhalí problém.
| Vývoj softwaru | |
|---|---|
| Proces | |
Koncepty na vysoké úrovni | |
| Pokyny |
|
Vývojové metodiky | |
| Modelky |
|
| Pozoruhodné postavy |
|