Co je extrémní programování?

plánovací hra

plánování XP řeší dvě klíčové otázky ve vývoji softwaru: předpovídání toho, co bude dosaženo do data splatnosti, a určení, co dělat dál. Důraz je kladen na řízení projektu – což je docela jednoduché – spíše než na přesné předpovědi, co bude potřeba a jak dlouho to bude trvat – což je docela obtížné., V XP existují dva klíčové plánovací kroky, které řeší tyto dvě otázky:

plánování vydání je praxe, kdy zákazník programátorům předkládá požadované funkce a programátoři odhadují jejich obtížnost. S odhady nákladů v ruce as vědomím důležitosti funkcí zákazník stanoví plán projektu. Počáteční plány vydání jsou nutně nepřesné: ani priority, ani odhady nejsou skutečně solidní, a dokud tým nezačne pracovat, nebudeme vědět, jak rychle půjdou., Dokonce i první plán vydání je dostatečně přesný pro rozhodování a týmy XP pravidelně revidují plán vydání.

iterační plánování je praxe, kdy tým dostane směr každých pár týdnů. Týmy XP vytvářejí software ve dvoutýdenních „iteracích“ a dodávají na konci každé iterace užitečný software. Během iteračního plánování představuje zákazník požadované funkce pro následující dva týdny. Programátoři je rozdělují do úkolů a odhadují jejich náklady (na jemnější úrovni detailů než při plánování vydání)., Na základě množství práce provedené v předchozí iteraci se tým přihlásí k tomu, co bude provedeno v současné iteraci.

Tyto plánovací kroky jsou velmi jednoduché, ale poskytují velmi dobré informace a vynikající řízení v rukou Zákazníka. Každých pár týdnů je množství pokroku zcela viditelné. V XP není „devadesát procent hotovo“: příběh funkce byl dokončen, nebo to nebylo., Toto zaměření na viditelnost má za následek pěkný malý paradox: na jedné straně, s takovou viditelností, je zákazník schopen projekt zrušit, pokud pokrok nestačí. Na druhou stranu je pokrok tak viditelný a schopnost rozhodnout, co bude dále, je tak úplná, že projekty XP mají tendenci dodávat více toho, co je potřeba, s menším tlakem a stresem.

zákaznické testy

v rámci prezentace každé požadované funkce definuje zákazník XP jeden nebo více automatizovaných akceptačních testů, které ukazují, že tato funkce funguje., Tým tyto testy sestavuje a používá je k tomu, aby dokázal sobě i zákazníkovi, že funkce je implementována správně. Automatizace je důležitá, protože v tisku času jsou ruční testy přeskočeny. To je jako vypnout světla, když noc ztmavne.

nejlepší týmy XP ošetřují své zákaznické testy stejným způsobem jako programátorské testy: jakmile test běží, tým jej poté udržuje správně. To znamená, že systém se zlepšuje, vždy se otáčí dopředu, nikdy se nezmění.,

Small Releases

XP teams cvičí malé verze dvěma důležitými způsoby:

tým nejprve vydává běžící, testovaný software, který přináší obchodní hodnotu zvolenou zákazníkem, každou iteraci. Zákazník může používat tento software pro jakýkoli účel, ať už hodnocení nebo dokonce uvolnění koncovým uživatelům (vysoce doporučeno). Nejdůležitějším aspektem je, že software je viditelný a dán zákazníkovi na konci každé iterace. To udržuje vše otevřené a hmatatelné.

za druhé, XP týmy uvolňují svým koncovým uživatelům často také., Webové projekty XP se vydávají tak často jako denně, v domácích projektech měsíčně nebo častěji. Dokonce i smršťovací zabalené výrobky jsou dodávány tak často, jak čtvrtletně.

často se může zdát nemožné vytvářet dobré verze, ale týmy XP to dělají po celou dobu. Viz kontinuální integrace pro více informací o tom, a všimněte si, že tyto časté verze jsou udržovány spolehlivé posedlost XP s testováním, jak je popsáno zde v testech zákazníků a Test-řízený vývoj.

jednoduchý Design

XP týmy vytvářejí software na jednoduchý, ale vždy přiměřený design., Začínají jednoduše a prostřednictvím testování programátorů a zlepšování designu to tak udržují. Tým XP udržuje design přesně vhodný pro aktuální funkčnost systému. Neexistuje žádný zbytečný pohyb a software je vždy připraven na to, co bude dál.

Design v XP není jednorázová věc, nebo up-front věc, to je all-the-time věc. Existují konstrukční kroky v plánování vydání a plánování iterací, a týmy se zapojují do rychlých designových relací a revizí designu prostřednictvím refaktoringu, v průběhu celého projektu., V inkrementálním, iterativním procesu, jako je extrémní programování, je nezbytný dobrý design. Proto je v průběhu celého vývoje tolik zaměřeno na design.

párové programování

veškerý výrobní software v XP je postaven dvěma programátory, sedícími vedle sebe, na stejném stroji. Tato praxe zajišťuje, že veškerý výrobní kód je přezkoumán alespoň jedním dalším programátorem a má za následek lepší design, lepší testování a lepší kód.

může se zdát neefektivní mít dva programátory, kteří dělají „práci jednoho programátora“, ale opak je pravdou., Výzkum párového programování ukazuje, že párování vytváří lepší kód přibližně ve stejnou dobu jako programátoři pracující jednotlivě. To je pravda: dvě hlavy jsou opravdu lepší než jedna!

někteří programátoři vznášejí námitky proti spárování programování, aniž by to někdy vyzkoušeli. To trvá nějakou praxi dělat dobře, a musíte to udělat dobře po dobu několika týdnů vidět výsledky. Devadesát procent programátorů, kteří se učí párovému programování, to dává přednost, proto ho vřele doporučujeme všem týmům.

párování, kromě poskytování lepšího kódu a testů, také slouží ke komunikaci znalostí v celém týmu., Jako páry přepínat, každý dostane výhody všech specializovaných znalostí. Programátoři se učí, jejich dovednosti se zlepšují, stávají se cennějšími pro tým a společnost. Párování, dokonce i samo o sobě mimo XP, je pro každého velkou výhrou.

vývoj založený na testech

extrémní programování je posedlé zpětnou vazbou a při vývoji softwaru vyžaduje dobrá zpětná vazba dobré testování. Nejlepší týmy XP praktikují „vývoj založený na testech“, pracují ve velmi krátkých cyklech přidání testu a poté jej fungují., Téměř bez námahy týmy vyrábějí kód s téměř 100% testovacím pokrytím, což je ve většině obchodů skvělý krok vpřed. (Pokud vaši programátoři již dělají ještě sofistikovanější testování, více energie pro vás. Držte to, může to jen pomoci!)

nestačí psát testy: musíte je spustit. I zde je extrémní programování extrémní. Tyto „programátor testy“, nebo „jednotkové testy“, jsou všechny shromážděny, a pokaždé, když nějaký programátor uvolňuje nějaký kód do úložiště (a páry obvykle uvolňováním dvakrát denně nebo více), každý programátor testy musí běžet správně., Na sto procent, pořád! To znamená, že programátoři získají okamžitou zpětnou vazbu o tom, jak se jim daří. Tyto testy navíc poskytují neocenitelnou podporu, protože se zlepšuje návrh softwaru.

zlepšení designu (Refactoring)

extrémní programování se zaměřuje na poskytování obchodní hodnoty v každé iteraci. K dosažení tohoto cíle v průběhu celého projektu musí být software dobře navržen. Alternativou by bylo zpomalit a nakonec uvíznout., XP tedy používá proces neustálého zlepšování designu zvaný Refactoring, z názvu knihy Martina Fowlera „Refactoring: Zlepšení návrhu stávajícího kódu“.

proces refaktorování se zaměřuje na odstranění duplikace (jistý znak špatného designu) a na zvýšení „soudržnosti“ kódu při současném snížení „spojky“. Vysoká soudržnost a nízká spojka jsou uznávány jako charakteristické znaky dobře navrženého kódu po dobu nejméně třiceti let. Výsledkem je, že týmy XP začínají dobrým, jednoduchým designem a vždy mají dobrý a jednoduchý design softwaru., To jim umožňuje udržet rychlost vývoje a ve skutečnosti obecně zvyšovat rychlost, jak projekt pokračuje.

Refactoring je samozřejmě silně podporován komplexním testováním, aby se ujistil, že jak se design vyvíjí, nic není přerušeno. Zákaznické testy a programátorské testy jsou tedy rozhodujícím faktorem. Praxe XP se navzájem podporují: jsou silnější než Samostatně.

kontinuální integrace

extrémní programovací týmy udržují systém plně integrovaný po celou dobu. Říkáme, že denní sestavení jsou pro wimps: XP týmy staví vícekrát denně., (Jeden XP tým čtyřiceti lidí staví nejméně osm nebo desetkrát denně!)

ve prospěch této praxe může být viděn tím, že vzpomínal na projekty, které jste možná slyšeli o (nebo dokonce část), kde proces sestavení byla jednou týdně nebo méně často, a obvykle vedlo k „integration hell“, kde se všechno rozbilo a nikdo nevěděl proč.

častá integrace vede k vážným problémům v softwarovém projektu., Za prvé, přestože integrace je zásadní pro dopravu dobré pracovní kód, tým není praktikována na to, a často je přenesena na lidi, kteří nejsou obeznámeni s celým systémem. Za druhé, zřídka integrovaný kód je často-řekl bych obvykle-buggy kód. Problémy tečení v integrační čas, že nejsou detekovány žádné testování, které probíhá na nezabudované systému. Za třetí, slabý proces integrace vede k dlouhým zamrznutím kódu., Kód zamrzne znamenat, že jste dlouho období, kdy programátoři mohli pracovat na důležité shippable funkce, ale tyto funkce musí být drženy. To oslabuje vaši pozici na trhu nebo u vašich koncových uživatelů.

kolektivní vlastnictví kódu

na extrémním programovacím projektu může každá dvojice programátorů kdykoli vylepšit jakýkoli kód. To znamená, že veškerý kód získává výhodu pozornosti mnoha lidí, což zvyšuje kvalitu kódu a snižuje vady., Existuje i další důležitá výhoda: když je Kód vlastněn jednotlivci, požadované funkce jsou často umístěny na špatném místě, protože jeden programátor zjistí, že potřebuje funkci někde v kódu, který nevlastní. Majitel je na to příliš zaneprázdněn, takže programátor vloží funkci do svého vlastního kódu, kam nepatří. To vede k ošklivému, těžko udržovatelnému kódu, plnému duplikace a nízké (špatné) soudržnosti.

kolektivní vlastnictví by mohlo být problémem, kdyby lidé pracovali slepě na kódu, kterému nerozuměli., XP se těmto problémům vyhýbá dvěma klíčovými technikami: programátor testuje chyby a párové programování znamená, že nejlepším způsobem práce na neznámém kódu je spárování s odborníkem. Kromě zajištění dobrých úprav v případě potřeby tato praxe rozšiřuje znalosti v celém týmu.

kódovací Standard

XP týmy dodržují společný kódovací standard, takže celý kód v systému vypadá, jako by byl napsán jedním – velmi kompetentním – jednotlivcem., Specifika standardu nejsou důležitá: důležité je, aby veškerý kód vypadal povědomě, na podporu kolektivního vlastnictví.

metafora

extrémní programovací týmy rozvíjejí společnou vizi toho, jak program funguje, což nazýváme „metaforou“. Na své nejlepší, metafora je jednoduchý evokující popis, jak program pracuje, jako „tento program funguje jako roj včel, chodit na pyl a přináší ho do úlu“ jako označení pro agenta-based information retrieval systém.

někdy nevzniká dostatečně poetická metafora., V každém případě, s nebo bez ostré snímky, XP týmy používají společný systém jmen, aby se ujistil, že každý chápe jak systém funguje a kde hledat najít funkce, které hledáte, nebo najít správné místo pro funkčnost se chystáte přidat.

udržitelné tempo

extrémní programovací týmy jsou v něm dlouhodobě. Pracují tvrdě a tempem, které lze udržet donekonečna. To znamená, že pracují přesčas, když je to efektivní, a že obvykle pracují takovým způsobem, aby maximalizovali produktivitu týden a týden., Je to dost dobře zřejmé, v těchto dnech, že pochod smrti projekty nejsou ani produktivní, ani vyrábět kvalitní software. XP týmy jsou v něm vyhrát, ne zemřít.

závěr

extrémní programování je disciplína vývoje softwaru založená na hodnotách jednoduchosti, komunikace, zpětné vazby a odvahy. Funguje to tím, že celý tým společně v přítomnosti jednoduchých postupů, s dostatečnou zpětnou vazbu, aby umožnily týmu vidět, kde jsou a vyladit postupy pro jejich jedinečné situaci.