Extrémne programovanie (XP) je jednou z agilných vývojových metodík softvér. Autormi metodiky sú Kent Beck, Ward Cunningham, Martin Fowler a ďalší.

Plánovacia hra

Náš svet je príliš premenlivý a nepredvídateľný na to, aby sme sa spoliehali na nemennosť situácie. To isté sa deje aj pri vývoji softvéru: o vzácnom systéme možno povedať, že jeho finálna podoba bola už na začiatku vývoja vopred detailne známa. S jedlom zvyčajne prichádza apetít zákazníka: neustále chce niečo meniť, niečo zlepšovať a niečo úplne vyhodiť zo systému. To je tá variabilita požiadaviek, ktorej sa každý tak veľmi bojí. Našťastie je človeku daná schopnosť predvídať možné možnosti a tak udržať situáciu pod kontrolou.
V Extrémnom programovaní je plánovanie neoddeliteľnou súčasťou vývoja a s tým, že plány sa môžu meniť, sa počíta od samého začiatku. Tým oporným bodom, technikou, ktorá vám umožňuje predvídať situáciu a bezbolestne sa zmieriť so zmenami, je hra plánovania. V priebehu takejto hry je možné rýchlo zhromaždiť známe systémové požiadavky, vyhodnotiť ich a naplánovať ich vývoj podľa priority.
Ako každá iná hra, aj plánovanie má svojich účastníkov a svoj účel. Kľúčovou postavou je samozrejme zákazník. Je to on, kto informuje o potrebe konkrétnej funkcionality. Programátori tiež poskytujú približné hodnotenie každej funkcie. Krása plánovacej hry spočíva v jednote účelu a solidarity medzi vývojárom a zákazníkom: v prípade víťazstva všetci vyhrávajú, v prípade porážky všetci prehrávajú. Ale zároveň každý účastník ide k víťazstvu svojou vlastnou cestou: zákazník si vyberá najdôležitejšie úlohy v súlade s rozpočtom a programátor hodnotí úlohy v súlade s jeho schopnosťou ich implementovať.
Extrémne programovanie predpokladá, že vývojári sa môžu sami rozhodnúť, ako dlho sa budú vyrovnávať so svojimi úlohami a ktorý z nich by bol ochotnejší vyriešiť jeden problém a kto nie.
V ideálnej situácii by sa plánovacia hra zahŕňajúca zákazníka a programátora mala hrať každých 3-6 týždňov, pred začiatkom ďalšej iterácie vývoja. Vďaka tomu je pomerne jednoduché vykonávať úpravy v súlade s úspechmi a neúspechmi predchádzajúcej iterácie.

Plán vydania

Plán vydania definuje dátumy vydania a jazyk používateľa, ktorý bude implementovaný v každom vydaní. Na základe toho si môžete zvoliť formuláciu pre ďalšiu iteráciu. Počas iterácie sa vytvoria akceptačné testy a spustia sa v rámci tejto iterácie a všetkých nasledujúcich iterácií, aby sa zabezpečilo, že program funguje správne. Plán je možné revidovať v prípade výrazného oneskorenia alebo pokroku po výsledkoch jednej z iterácií.
Iterácie. Iterácia robí proces vývoja dynamickým. Svoje programovacie úlohy si nemusíte plánovať dlho dopredu. Namiesto toho je lepšie mať plánovacie stretnutie na začiatku každej iterácie. Nestojí za to pokúšať sa realizovať niečo, čo nebolo plánované. Stále budete mať čas na realizáciu týchto nápadov, keď sa dostanú na rad podľa plánu vydania.
Tým, že si zvyknete nepridávať funkcie vopred a použijete priame plánovanie, môžete sa ľahko prispôsobiť meniacim sa požiadavkám zákazníkov.

Plánovanie iterácií

Plánovanie iterácií sa začína stretnutím na začiatku každej iterácie, aby sa vypracoval plán krokov na dosiahnutie cieľov programu. Každá iterácia by mala trvať jeden až tri týždne. Výkazy v rámci iterácie sú zoradené podľa dôležitosti pre zákazníka. Okrem toho sú pridané úlohy, ktoré neprešli akceptačnými testami a je potrebné ich zlepšiť. Vyhlásenia a výsledky testov sú prevedené do programových úloh. Úlohy sa píšu na kartičky, ktoré tvoria podrobný plán iterácií. Vyriešenie každej z úloh trvá jeden až tri dni. Úlohy, ktoré potrebujú menej ako jeden deň, je možné zoskupiť a veľké úlohy rozdeliť na niekoľko menších. Vývojári hodnotia úlohy a termíny ich dokončenia. Je veľmi dôležité, aby vývojár nastavil presný čas vykonania úlohy. Môže byť potrebné prehodnotiť niektoré jazyky a revidovať plán vydania po každých troch alebo piatich iteráciách - to je celkom prijateľné. Ak najskôr implementujete najdôležitejšie oblasti práce, potom budete mať vždy čas urobiť pre svojich zákazníkov maximum možného. Vývojový štýl založený na postupnosti opakovaní zlepšuje proces vývoja.

Stále stretnutie

Každé ráno je porada, na ktorej sa diskutuje o problémoch, ich riešení a na zvýšenie koncentrácie tímu. Stretnutie sa koná v stoji, aby sa predišlo zdĺhavým diskusiám, ktoré nie sú zaujímavé pre všetkých členov tímu.
Na typickom stretnutí väčšina účastníkov neprispieva ničím, len sa zúčastňuje, aby si vypočula, čo hovoria ostatní. Veľké množstvo času ľudí sa premrhá na prijímanie malého množstva komunikácie. Účasť všetkých ľudí na stretnutiach preto uberá z projektu zdroje a vytvára chaos v plánovaní.
Pre tento druh komunikácie je potrebná stála schôdza. Je oveľa lepšie mať jedno krátke povinné stretnutie ako veľa dlhých, ktorých sa musí väčšina vývojárov aj tak zúčastniť.
Ak máte denné stretnutia v stoji, tak na všetky ostatné stretnutia by mali chodiť len tí ľudia, ktorí sú potrební a niečo prinesú. Navyše je dokonca možné vyhnúť sa niektorým stretnutiam. S obmedzeným počtom účastníkov sa väčšina stretnutí môže konať spontánne pred monitorom, kde je výmena nápadov oveľa intenzívnejšia.
Každodenné ranné stretnutie nie je len ďalšou stratou času. Umožní vám vyhnúť sa mnohým ďalším stretnutiam a ušetrí vám viac času, ako zbytočne.

Jednoduchosť

Jednoduchý dizajn vždy zaberie menej času ako zložitý. Preto vždy robte tie najjednoduchšie veci, ktoré môžu fungovať. Vždy je rýchlejšie a lacnejšie nahradiť zložitý kód hneď, ako na ňom strávite veľa času. Urobte veci tak jednoduché, ako je to len možné, bez pridávania funkcií ešte pred plánovaním. Majte na pamäti: udržať jednoduchý dizajn je náročná práca.

Metaforický systém

Výber systému metafor je potrebný na to, aby tím zostal v rovnakom rámci pri pomenovaní tried a metód. To, ako pomenujete svoje objekty, je veľmi dôležité pre pochopenie celkového dizajnu systému a opätovného použitia kódu. Ak je vývojár schopný správne odhadnúť, ako by mohol byť pomenovaný existujúci objekt, šetrí to čas. Používajte pre svoje objekty systém pomenovávania, ktorému rozumie každý bez špecifických znalostí systému.

Zákazník na pracovisku

Hlavným problémom vývoja softvéru je nedostatočná znalosť programátorov v danej oblasti. Extrémne programovanie našlo východisko aj z tejto situácie. Nie, nejde o vývojársku stáž u zákazníka – potom nebude chcieť programovať. Naopak, je to účasť zákazníka na procese vývoja.
Ako môže programátor bez dôkladného pochopenia podstaty problému a nebyť telepata uhádnuť, čo zákazník chce? Odpoveď je zrejmá. najviac jednoduchým spôsobom prekonať takúto nepríjemnosť – a extrémne programovanie nás učí nájsť najviac jednoduché riešenia- položí zákazníkovi priamu otázku. Prísnejšie prístupy si vyžadujú komplexnú predbežnú analýzu rozvíjanej oblasti. V určitých prípadoch je to opodstatnené, hoci to stojí viac. Skutočné skúsenosti s realizáciou svetských projektov ukazujú, že nie je možné zhromaždiť všetky požiadavky vopred. Navyše, aj keď predpokladáme, že všetky požiadavky sú momentálne zhromaždené, stále tu bude jeden problém: programy, ako všetko v prírode, sa nevytvárajú okamžite a medzitým sa môžu obchodné procesy zmeniť. Toto treba brať do úvahy.
Mnohí pochybujú o možnosti zapojenia zákazníka do procesu vývoja. V skutočnosti sú zákazníci rôzni. Ak nie je možné prilákať zákazníka alebo jeho zástupcu, niekedy má zmysel dočasne najať špecialistu v rozvíjanej oblasti. Takýto krok zníži nejasnosti v práci, zvýši rýchlosť vývoja a priblíži projekt tomu, čo chce zákazník dostať. To môže byť prospešné aj z finančnej stránky: veď plat programátora niekedy výrazne prevyšuje plat špecialistov v iných odvetviach.
užívateľský príbeh. User Story (niečo ako používateľský príbeh) je popis toho, ako by mal systém fungovať. Každý užívateľský príbeh je napísaný na karte a predstavuje určitú časť systémovej funkcionality, ktorá dáva logický zmysel z pohľadu zákazníka. Formulár je jeden alebo dva odseky textu, ktorý je pre používateľa zrozumiteľný (nie je príliš technický).
Používateľský príbeh je napísaný Zákazníkom. Sú podobné, ale nie sú obmedzené na, scenáre používania systému. užívateľské rozhranie. Pre každý príbeh sú napísané funkčné testy, ktoré potvrdzujú, že tento príbeh je správne implementovaný – nazývajú sa tiež akceptačné testy.

Testovanie pred vývojom

Testovanie je v klasickom zmysle dosť nudný postup. Zvyčajne si najímajú testera, ktorý pravidelne vykonáva tie isté akcie a čaká na deň, kedy je konečne presunutý na inú pozíciu alebo existuje príležitosť zmeniť prácu.
V extrémnom programovaní je úloha testovania zaujímavejšia: teraz je prvý test a potom kód. Ako môžete testovať niečo, čo ešte neexistuje? Odpoveď je jednoduchá a banálna: otestujte si svoje myšlienky – čo by ste mali očakávať od budúceho softvéru alebo funkčnosti. To vám umožní lepšie pochopiť, čo musia programátori urobiť, a skontrolovať funkčnosť kódu hneď po jeho napísaní.
Ale ani test nemusí fungovať. Čo tak napísať test na test? A potom testovať na test a tak ďalej donekonečna? Vôbec nie. Test na test nahradí kód. Ako to? Ale pozrite si: predstavte si, že potrebujete upevniť maticu v strede skrutky, aby sa neotáčala. Čo pre to robia? Naskrutkujte druhú maticu tesne k prvej tak, aby každá matica zabránila otáčaniu ďalšej. V programovaní je to rovnaké: test testuje kód a kód testuje test.
Prax ukazuje, že tento prístup nielenže nespomaľuje, ale aj urýchľuje vývoj. Koniec koncov, vedieť, čo je potrebné urobiť a potrebné množstvo práce, ušetrí čas tým, že odmietne implementovať nenárokované tento moment podrobnosti.

Párové programovanie

Celý kód pre produkčný systém je napísaný v pároch. Vedľa seba sedia dvaja vývojári. Jeden vytáča, druhý sleduje. Z času na čas sa menia. Samostatne pracovať nie je dovolené. Ak z nejakého dôvodu druhý z dvojice niečo zmeškal (bol chorý, odišiel a pod.), je povinný skontrolovať všetky zmeny, ktoré urobil prvý.
Znie to nezvyčajne, ale po krátkej dobe prispôsobenia sa väčšine ľudí skvele funguje vo dvojici. Dokonca sa im to páči, pretože práca ide citeľne rýchlejšie. Platí zásada „Jedna hlava je dobrá, ale dve sú lepšie“. Páry väčšinou nájdu optimálnejšie riešenia. Okrem toho sa výrazne zvyšuje kvalita kódu, znižuje sa počet chýb a zrýchľuje sa výmena znalostí medzi vývojármi. Zatiaľ čo jedna osoba sa zameriava na strategický pohľad na objekt, druhá osoba implementuje jeho vlastnosti a metódy.

Zmena pozícií

Počas ďalšej iterácie by sa všetci pracovníci mali presunúť do nových oblastí práce. Takéto pohyby sú potrebné, aby sa predišlo izolácii vedomostí a odstránili sa úzke miesta. Obzvlášť plodná je výmena jedného z vývojárov v párovom programovaní.

Kolektívne vlastníctvo kódu

Kolektívne vlastníctvo kódu povzbudzuje vývojárov, aby predkladali nápady pre všetky časti projektu, nielen pre svoje vlastné moduly. Každý vývojár môže zmeniť ľubovoľný kód, aby pridal funkčnosť a opravoval chyby.
Na prvý pohľad to vyzerá ako chaos. Ak však vezmeme do úvahy, že aspoň akýkoľvek kód vytvára pár vývojárov, že testy vám umožňujú skontrolovať správnosť vykonaných zmien a že v reálnom živote musíte stále tak či onak rozumieť kódu niekoho iného, ​​je jasné, že kolektívne vlastníctvo kódu výrazne zjednodušuje zavádzanie zmien a znižuje riziko spojené s vysokou špecializáciou člena tímu.

Kódovacia konvencia

Ste v tíme, ktorý na tomto projekte pracuje už dlho. Ľudia prichádzajú a odchádzajú. Nikto nekóduje sám a kód patrí všetkým. Vždy budú chvíle, keď bude potrebné pochopiť a opraviť kód niekoho iného. Vývojári odstránia alebo zmenia duplicitný kód, analyzujú a vylepšia triedy iných ľudí atď. Časom nebude možné zistiť, kto je autorom konkrétnej triedy.
Preto sa každý musí podriadiť bežným kódovacím štandardom – formátovanie kódu, trieda, premenná, konštantné pomenovanie, štýl komentára. Takto budeme mať istotu, že vykonaním zmien v cudzom kóde (čo je nevyhnutné pre agresívny a extrémny pokrok vpred) z neho neurobíme babylonské pandemonium.
Vyššie uvedené znamená, že všetci členovia tímu sa musia dohodnúť na spoločných štandardoch kódovania. Je jedno aké. Platí pravidlo, že ich všetci poslúchajú. Tí, ktorí ich nechcú dodržiavať, opúšťajú tím.

Častá integrácia

Ak je to možné, vývojári by mali svoj kód integrovať a vydať každých niekoľko hodín. V každom prípade by ste zmeny nikdy nemali uchovávať dlhšie ako jeden deň. Častá integrácia zabraňuje odcudzeniu a fragmentácii vo vývoji, kde vývojári nemôžu komunikovať v zmysle výmeny nápadov alebo opätovného použitia kódu. Každý musí pracovať s Najnovšia verzia.
Každá dvojica vývojárov by mala rozdať svoj kód hneď, ako na to bude primeraná príležitosť. Môže to byť vtedy, keď všetky UnitTests prejdú 100 %. Odoslaním zmien niekoľkokrát denne znížite problémy s integráciou takmer na nič. Integrácia je činnosť typu „zaplať teraz alebo zaplať viac neskôr“. Vďaka každodennej integrácii zmien v malých častiach preto nebudete musieť stráviť týždeň spájaním systému tesne pred dodaním projektu. Vždy pracujte na najnovšej verzii systému.

Štyridsaťhodinový pracovný týždeň

Človek, najmä ak je programátor, je schopný urobiť veľa pre podnikanie: zostať v práci, ísť do práce na víkend, odmietnuť dovolenku, zostať niekoľko dní hore, sedieť pri klávesnici. , .. Vo všeobecnosti nemôžete robiť nič pre svoju obľúbenú zábavu. Ale extrémne programovanie je kategoricky proti takémuto sebaobetovaniu a porušovaniu akceptovaných pracovnoprávnych noriem.
Je to diktované nielen úvahami o zákonnosti a ľudskosti, ale predovšetkým potrebou zvýšiť efektivitu práce a prísnu organizáciu. Koniec koncov, extrémne programovanie je kolektívna hra, určená nie pre jednotlivcov, ale pre celú skupinu ako celok. A také niečo, ako je napríklad párové programovanie, je možné len vtedy, ak sú biorytmy jeho účastníkov synchronizované. A je nemožné, ak jeden príde do práce o deviatej a druhý o dvanástej, alebo sa jeden rozhodne, že je pre neho lepšie pracovať v sobotu a nedeľu, kým druhému je to nepríjemné.
Ale čo je najdôležitejšie, na udržanie zdravia a výkonnosti potrebuje človek dobrý odpočinok. Osemhodinový pracovný deň a päťdňový pracovný týždeň sú stanovené práve z dôvodu maximálnej produktivity. V mnohých západných firmách sa neskoré odchod z práce považuje za slabý akademický výkon alebo neschopnosť správne si riadiť pracovný čas. Vo väčšine prípadov je to pravda. Áno, a z medicínskeho hľadiska vedie meškanie v práci k neustálej únave, podráždenosti a zníženiu mozgovej aktivity. Je to efektívne? Ako však organizovať neustálu otvorenú komunikáciu medzi vývojármi v takomto tíme a bude možné párové programovanie? Odpoveď je negatívna. Pravidlá sú pravidlá a mali by sa dodržiavať.

Záver

Tieto techniky nie sú spojené náhodou. Ich dôsledná kombinácia dokáže priviesť vývojový proces do intelektuálnej rezonancie, výrazne zlepšiť kvalitu produktu a priblížiť čas jeho vydania. Hlavnou krásou celého extrémneho programovania je predvídateľnosť a minimalizácia nákladov na vývoj; poskytnúť zákazníkovi produkt, ktorý chce dostať v čase uvoľnenia; a samozrejme komunikácia a školenie vývojárov priamo na mieste.

Bibliografia:

Extrémne programovanie (XP) vzniklo ako evolučná metóda vývoja softvéru zdola nahor. Tento prístup je príkladom takzvanej metódy agilného rozvoja. Do skupiny „živých“ metód patria okrem extrémneho programovania aj metódy SCRUM, DSDM (Dynamic Systems Development Method), Feature-Driven Development (vývoj riadený systémovými funkciami) atď.

Základné princípy "živého" vývoja softvéru sú stanovené v "živom" vývojovom manifeste, ktorý sa objavil v roku 2000.

• · Ľudia zapojení do projektu a ich komunikácia je dôležitejšia ako procesy a nástroje.
• · Pracovný program je dôležitejší ako komplexná dokumentácia.
• · Spolupráca so zákazníkom je dôležitejšia ako diskutovanie o detailoch zmluvy.
• · Cvičenie zmien je dôležitejšie ako dodržiavanie plánov.

"Live" metódy sa objavili ako protest proti prílišnej byrokratizácii vývoja softvéru, množstvu vedľajších dokumentov, ktoré nie sú potrebné na získanie konečného výsledku, ktoré je potrebné vypracovať počas projektu v súlade s väčšinou "ťažkých" procesov. , práca naviac na podporu fixného procesu organizácie, ako to vyžaduje napríklad CMM. Väčšina týchto prác a dokumentov priamo nesúvisí s vývojom softvéru a zabezpečením kvality, ale ich cieľom je splniť formálne klauzuly vývojových zmlúv, získať a potvrdiť certifikáty o súlade s rôznymi normami.

„Live“ metódy umožňujú väčšinu úsilia vývojárov zamerať sa na skutočné úlohy vývoja a uspokojovania skutočné potreby používateľov. Absencia hromady dokumentov a potreba ich udržiavania v súvislom stave umožňuje rýchlejšie a efektívnejšie reagovať na zmeny požiadaviek a prostredia, v ktorom bude musieť budúci program fungovať.

Napriek tomu má XP svoju vlastnú schému vývojového procesu (hoci, všeobecne povedané, široko používané chápanie „procesu vývoja“ ako dosť rigidnej schémy akcií je v rozpore so samotnou myšlienkou „živosti“) vývoja, znázornenej na obrázku 1.

Podľa autorov XP táto technika ani tak nesleduje nejaké všeobecné vzorce konania, ako skôr kombináciu nasledujúcich techník. Každá technika je však dôležitá a bez nej sa vývoj považuje za non-XP, podľa Kenta Becka, jedného z autorov tohto prístupu spolu s Wardom Cunninghamom (Ward Cunningham) a Ronom Jeffriesom (Ron Jeffries).

· žijúci plánovanie hra)

Jeho úlohou je čo najrýchlejšie určiť množstvo práce, ktorú je potrebné vykonať pred ďalšou verziou softvéru. Rozhodnutie sa robí v prvom rade na základe priorít zákazníka (t. j. jeho potrieb, čo potrebuje od systému, aby mohol úspešnejšie podnikať) a v druhom rade na základe technické posudky(t.j. odhady zložitosti vývoja, kompatibility s ostatnými prvkami systému a pod.). Plány sa menia, akonáhle sa začnú rozchádzať s realitou alebo želaniami zákazníka.

Obr.1

· Časté zmeniť verzie (malé vydania)

Úplne prvá pracovná verzia by sa mala objaviť čo najskôr a mala by sa okamžite použiť. Ďalšie verzie sa pripravujú v pomerne krátkych intervaloch (od niekoľkých hodín s malými zmenami). malý program, až mesiac alebo dva so serióznym spracovaním veľkého systému). Verzie (vydania) produktu by mali ísť do výroby čo najčastejšie. Práca na každej verzii by mala trvať čo najmenej času. Každá verzia by mala byť zároveň dostatočne zmysluplná z hľadiska užitočnosti pre podnikanie.

· Metafora systému

Metafora v pomerne jednoduchej a pre tím zrozumiteľnej forme by mala popisovať hlavný mechanizmus systému. Tento koncept pripomína architektúru, ale malo by byť oveľa jednoduchšie, len jednou alebo dvoma frázami, opísať hlavnú podstatu akceptovaného technické riešenia.

Architektúra je určitá predstava o komponentoch systému a o tom, ako sú vzájomne prepojené. Vývojári používajú architektúru, aby pochopili, kde v systéme sú pridané nové funkcie a s čím bude nejaký nový komponent interagovať.

Metafora systému je analogická tomu, čo väčšina techník nazýva architektúra. Metafora systému dáva tímu predstavu o tom, ako systém momentálne funguje, kde sa pridávajú nové komponenty a akú formu by mali mať.

· Jednoduché dizajn riešenia (jednoduché dizajn)

V každom danom čase by mal byť systém navrhnutý čo najjednoduchšie. Nie je potrebné pridávať funkcie vopred - iba po výslovnom vyžiadaní. Všetka nadbytočná zložitosť sa odstráni hneď, ako sa objaví.

XP vychádza zo skutočnosti, že v procese práce sa podmienky problému môžu opakovane meniť, čo znamená, že vyvíjaný produkt by nemal byť navrhnutý vopred úplne a úplne. Ak sa na úplnom začiatku práce snažíte navrhnúť systém detailne od začiatku do konca, strácate čas. XP naznačuje, že návrh je taký dôležitý proces, že sa musí vykonávať nepretržite počas životnosti projektu. Návrh by sa mal vykonávať v malých krokoch, pričom treba brať do úvahy neustále sa meniace požiadavky. V každom okamihu sa snažíme použiť najjednoduchší dizajn, ktorý vyhovuje aktuálnej úlohe. Zároveň ho meníme tak, ako sa menia podmienky problému.

· rozvoj na základ testovanie (riadené testom vývoj)

Vývojári najskôr napíšu testy, potom sa pokúsia implementovať svoje moduly tak, aby testy fungovali. Zákazníci vopred píšu testy, ktoré demonštrujú hlavné vlastnosti systému, aby ste videli, že systém naozaj funguje.

XP sa zameriava na dva typy testovania:

ь testovanie jednotiek (testovanie jednotiek);

ь akceptačné testovanie (akceptačné testovanie).

extrémne programovací softvér

Vývojár si nemôže byť istý správnosťou kódu, ktorý napíše, kým nefungujú absolútne všetky unit testy systému, ktorý vyvíja. Unit testy umožňujú vývojárom overiť, či ich kód funguje správne. Pomáhajú tiež ostatným vývojárom pochopiť, prečo je konkrétny kód potrebný a ako funguje. Jednotkové testy tiež umožňujú vývojárovi refaktorovať bez akéhokoľvek strachu.

Akceptačné testy vám umožňujú uistiť sa, že systém má skutočne deklarované schopnosti. Okrem toho akceptačné testy umožňujú kontrolovať správne fungovanie vyvíjaného produktu.

Pre XP je prioritnejší prístup nazývaný TDD (Test Driven Development), najskôr sa napíše test, ktorý neprejde, potom sa napíše kód tak, aby test prešiel, a potom sa kód refaktoruje.

· Neustále refaktoring

Nie je žiadnym tajomstvom, že každá pridaná nová funkcia a rastúci kód sťažujú vývoj, zachytávanie chýb a následné zmeny. Jedným z trikov extrémneho programovania je kompenzovať pridanie funkčnosti vylepšením kódu. Toto je refaktorovanie alebo refaktorovanie kódu.

Programátori neustále prerábajú systém, aby odstránili zbytočnú zložitosť, zvýšili zrozumiteľnosť kódu, zvýšili jeho flexibilitu, avšak bez zmeny jeho správania, čo sa overuje spustením po každom prepracovaní testov. Zároveň sa uprednostňujú elegantnejšie a flexibilnejšie riešenia v porovnaní s tými, ktoré jednoducho poskytujú požadovaný výsledok. Neúspešne prerobené komponenty by sa mali zistiť pri spustení testov a vrátiť sa späť do posledného konzistentného stavu (spolu s komponentmi, ktoré sú na nich závislé).

Refaktoring je technika na zlepšenie kódu bez zmeny jeho funkčnosti. XP znamená, že akonáhle je kód napísaný, bude takmer určite mnohokrát prepracovaný v priebehu projektu. Vývojári XP nemilosrdne prepracúvajú predtým napísaný kód, aby ho vylepšili. Tento proces sa nazýva refaktoring. Nedostatočné pokrytie testov vyvoláva odmietnutie refaktoringu z dôvodu strachu z prelomenia systému, čo vedie k postupnej degradácii kódu.

· Programovanie v pároch (pár programovanie)

Skúsení vývojári si všimli, že pravidelná kontrola kódu niekoho iného má pozitívny vplyv na jeho kvalitu. Extreme Programmers vyvinuli tento prístup: počas vývoja je kód neustále revidovaný pomocou techniky nazývanej párové programovanie.

Kódovanie vykonávajú dvaja programátori na jednom počítači. Párovanie je ľubovoľné a líši sa od problému k problému. Ten, v ktorého rukách sa klávesnica pokúša najlepším možným spôsobom vyriešiť aktuálny problém. Druhý programátor analyzuje prácu prvého a poskytuje rady, zvažuje dôsledky určitých rozhodnutí, nové testy, menej priame, ale flexibilnejšie riešenia. V prípade potreby sa klávesnica voľne prenáša z jednej na druhú. Pri práci na projekte nie sú dvojice pevne dané: odporúča sa ich pomiešať, aby mal každý programátor v tíme dobrú predstavu o celom systéme. Párové programovanie teda zlepšuje interakciu v rámci tímu.

· kolektívne držba kód (kolektívny vlastníctvo)

kolektívne držba znamená, že každý člen tímu je zodpovedný za celok zdroj. Každý má teda právo vykonávať zmeny v ktorejkoľvek časti programu. Párové programovanie podporuje túto prax: všetci programátori sa pri práci v rôznych pároch zoznámia so všetkými časťami kódu systému. Dôležitou výhodou kolektívneho vlastníctva kódu je, že urýchľuje proces vývoja, pretože keď sa vyskytne chyba, každý programátor ju môže opraviť.

Tým, že dávame každému programátorovi právo zmeniť kód, riskujeme, že zavedieme chyby od programátorov, ktorí si myslia, že vedia, čo robia, ale neberú do úvahy niektoré závislosti. Dobre definované UNIT testy riešia tento problém: ak nepreskúmané závislosti generujú chyby, potom ďalšie spustenie UNIT testov zlyhá.

· Neustále integrácia (nepretržitá integrácia)

Systém sa zostavuje a integruje tak často, ako je to možné, niekoľkokrát denne, vždy, keď pár programátorov dokončí implementáciu funkcie.

Ak svoj systém integrujete dostatočne často, môžete sa vyhnúť väčšine problémov, ktoré s tým súvisia. V tradičných metódach sa integrácia spravidla vykonáva na samom konci práce na produkte, keď sa predpokladá, že všetky komponenty vyvíjaného systému sú úplne pripravené. V XP sa kódová integrácia celého systému vykonáva niekoľkokrát denne po tom, čo sa vývojári ubezpečia, že všetky testy jednotiek fungujú správne.

Napriek svojej jednoduchosti má táto technika svoje vlastné pravidlá používania, ako je úspešnosť existujúcich jednotkových testov pre integrovanú funkčnosť, prítomnosť funkčných alebo akceptačných testov a samozrejme schopnosť vrátiť sa do predchádzajúceho stavu. Spravidla sa vykonáva integrácia a riešenie sprievodných ťažkostí samostatný počítač pár programátorov. To umožňuje minimalizovať riziko nežiaducich následkov integrácie.

· 40 hodín pracovné týždeň

Nadčasy sa považujú za znak veľkých problémov v projekte. Nie je dovolené robiť nadčasy 2 týždne po sebe – programátorov to vyčerpáva a ich práca je výrazne menej produktívna.

Človek, najmä ak je programátorom, je v záujme podnikania schopný veľa vecí: zostať v práci, ísť do práce na víkend, odmietnuť si vziať dovolenku, byť niekoľko dní hore, sedieť pri klávesnici. Vo všeobecnosti nemôžete robiť nič pre svoju obľúbenú zábavu. Ale extrémne programovanie je kategoricky proti takémuto sebaobetovaniu a porušovaniu akceptovaných pracovnoprávnych noriem.

Je to diktované nielen úvahami o zákonnosti a ľudskosti, ale predovšetkým potrebou zvýšiť efektivitu práce a prísnu organizáciu. Koniec koncov, extrémne programovanie je kolektívna hra, určená nie pre jednotlivcov, ale pre celú skupinu ako celok. A také niečo, ako je napríklad párové programovanie, je možné len vtedy, ak sú biorytmy jeho účastníkov synchronizované. A je nemožné, ak jeden príde do práce o deviatej a druhý o dvanástej, alebo sa jeden rozhodne, že je pre neho lepšie pracovať v sobotu a nedeľu, kým druhému je to nepríjemné.

Ale čo je najdôležitejšie, na udržanie zdravia a výkonnosti potrebuje človek dobrý odpočinok. Osemhodinový pracovný deň a päťdňový pracovný týždeň sú stanovené práve z dôvodu maximálnej produktivity. V mnohých západných firmách sa neskoré odchod z práce považuje za slabý akademický výkon alebo neschopnosť správne si riadiť pracovný čas. Vo väčšine prípadov je to pravda. Áno, a z medicínskeho hľadiska vedie meškanie v práci k neustálej únave, podráždenosti a zníženiu mozgovej aktivity. Je to efektívne? Ako však organizovať neustálu otvorenú komunikáciu medzi vývojármi v takomto tíme a bude možné párové programovanie? Odpoveď je negatívna. Pravidlá sú pravidlá a mali by sa dodržiavať.

· Inklúzia zákazníka v príkaz (na mieste zákazník)

Hlavným problémom vývoja softvéru je nedostatočná znalosť programátorov v danej oblasti. Extrémne programovanie našlo východisko aj z tejto situácie. Nie, nejde o vývojársku stáž u zákazníka – potom nebude chcieť programovať. Naopak, je to účasť zákazníka na procese vývoja.

Súčasťou vývojového tímu je vždy zástupca zákazníka, ktorý je k dispozícii počas celého pracovného dňa a je schopný odpovedať na všetky otázky týkajúce sa systému. Je jeho povinnosťou dostatočne promptne reagovať na otázky akéhokoľvek typu týkajúce sa funkcií systému, jeho rozhrania, požadovaného výkonu, správna prevádzka systémy v náročných situáciách, nutnosť komunikácie s inými aplikáciami a pod.

Mnohí pochybujú o možnosti zapojenia zákazníka do procesu vývoja. V skutočnosti sú zákazníci rôzni. Ak nie je možné prilákať zákazníka alebo jeho zástupcu, niekedy má zmysel dočasne najať špecialistu v rozvíjanej oblasti. Takýto krok zníži nejasnosti v práci, zvýši rýchlosť vývoja a priblíži projekt tomu, čo chce zákazník dostať. To môže byť prospešné aj z finančnej stránky: veď plat programátora niekedy výrazne prevyšuje plat špecialistov v iných odvetviach.

· Použitie kód ako fondy komunikácie

Kód je považovaný za najdôležitejší prostriedok komunikácie v rámci tímu. Zrozumiteľnosť kódu je jednou z najvyšších priorít. Dodržiavanie štandardov kódovania, ktoré poskytujú takúto jasnosť, je nevyhnutné. Takéto normy by okrem prehľadnosti kódu mali zabezpečiť minimum výrazov (zákaz duplikácie kódu a informácií) a mali by byť akceptované všetkými členmi tímu.

· OTVORENÉ pracovné priestor (otvorený pracovný priestor)

Tím je umiestnený v jednej miestnosti, dostatočne priestrannej na uľahčenie komunikácie a možnosti kolektívnych diskusií pri plánovaní a prijímaní dôležitých technických rozhodnutí.

· Zmeniť pravidlá na potrebné (len pravidlá)

Každý člen tímu musí uvedené pravidlá akceptovať, ale ak to bude potrebné, tím ich môže zmeniť, ak s touto zmenou súhlasia všetci jeho členovia.

Ako vidno z použitých techník, XP je navrhnutý na použitie v rámci malých tímov (nie viac ako 10 programátorov), čo zdôrazňujú aj autori tejto techniky. Väčšia veľkosť tímu ničí jednoduchosť komunikácie potrebnej na úspech a znemožňuje mnohé z uvedených techník.

Extrémne programovanie je odklon od tradičného procesu tvorby programov – namiesto jednorázového plánovania, analýzy a návrhu systému s dlhodobou perspektívou programátori všetky tieto operácie implementujú postupne počas vývoja.

Spočiatku existoval model „vodopádu“ (obr. 1a): žiadame používateľov, aby jednoznačne formulovali svoje požiadavky; navrhujeme systém, ktorý bude robiť všetko, čo používatelia chcú; píšeme kód; testujeme program, aby sme sa uistili, že robí to, čo má robiť. Všetko dopadne výborne.

V skutočnosti to nebolo ani zďaleka ružové. Pred začatím vývoja používatelia ešte nedokážu jednoznačne formulovať svoje požiadavky. Nie vždy vedeli, čo chcú, niekedy si protirečili a zmenili názor na problém. Nejde však len o používateľov. My programátori, ktorí sme prešli tri štvrtiny cesty a zistili sme, že sme v skutočnosti urobili iba jednu tretinu práce, sme sa z toho tešili ako z obrovského úspechu.

Takže dlhý vývojový cyklus je zlý, pretože nie je schopný prispôsobiť sa zmenám. Potom je možno potrebné skrátiť cyklus a všetky problémy sa vyriešia? Na obr. 1b ilustruje transformáciu vodopádového modelu na iteračný model.

Pripomeňme, že vodopádový model sa neobjavil z ničoho nič – bola to prirodzená reakcia na tie šokujúce odhady, ktoré ukázali, že cena za vykonanie zmien v programe sa časom veľmi zvyšuje. Ak je to pravda, potom je potrebné urobiť najdôležitejšie, ďalekosiahle rozhodnutia v najskoršom štádiu životného cyklu programu, aby za ne neskôr nemuseli draho zaplatiť.

Akademická obec softvérových vývojárov sa ujala problému vysokej ceny zmien a vytvorila nové technológie – relačné databázy, modulárne programovanie, skrývanie informácií. Čo ak však všetky tieto diela už vyčerpali svoj potenciál? A môžeme nájsť Nová cesta znížiť náklady na vykonávanie zmien tým, že „vodopád“ nerozsekáte na kúsky, ale jednoducho zmiešate všetky jeho zložky? Výsledok je znázornený na obrázku 1c. Nazvali sme to "Extrémne programovanie" (XP).

Anatómia XP

XP sa vzďaľuje od tradičného procesu tvorby softvérový systém a namiesto jednorazového plánovania, analýzy a návrhu z dlhodobého hľadiska sa s XP všetky tieto aktivity implementujú postupne počas vývoja, čím sa dosiahne výrazné zníženie nákladov na zmeny v programe. Metódy XP boli navrhnuté s ohľadom na kumulatívne použitie, takže keď pochopíte jednu z nich, nevyhnutne pochopíte aj ostatné (pozri bočný panel). Bočný panel sleduje historické pozadie tohto prístupu.)

vývojový cyklus XP

Na obr. 2 proces XP súvisí s rôznymi časovými osami, kde sa ako merná jednotka používajú roky, mesiace, týždne a dni. Zákazník si určí ďalšiu verziu (vydanie) systému, pričom si vyberie najhodnotnejšie funkcie (v XP sa im hovorí stories - stories) zo všetkých možných. Hodnotu funkcií určujú materiálové a časové náklady na ich realizáciu vývojovým tímom.

Zákazník určí príbehy pre ďalšiu iteráciu výberom najvýznamnejších príbehov z tých, ktoré zostali vo verzii, opäť na základe odhadu nákladov a rýchlosti ich vývoja. Programátori rozkladajú príbehy na lokálne úlohy a každý preberá zodpovednosť za jednu z nich. Potom programátor transformuje svoj problém do súboru testovacích prípadov, ktorých úspešné vykonanie ukáže, že problém bol úplne vyriešený. Pri práci v tandeme s partnerom programátor dosiahne normálnu prevádzku testov pri vývoji spoločného projektu. Takto je možné implementovať najjednoduchšiu architektúru systému ako celku.

Príbehy

Obdobie do prvého spustenia systému do reálnej prevádzky je z pohľadu XP nebezpečnou anomáliou v r. životný cyklus projektu a treba ho čo najskôr prekonať. Práca na akomkoľvek projekte sa však musí nejako začať.

V prvom rade je potrebné rozhodnúť, na čo je systém vo všeobecnosti určený a čo by mal v prvom rade zvládať. Na prijatie takýchto rozhodnutí je spravidla potrebná určitá analýza. Symbolizuje ho úzky modrý obdĺžnik na obr. 1 s. Nemôžete začať programovať, kým nepochopíte, čo vlastne treba naprogramovať.

Výsledky všeobecnej analýzy sú prezentované ako príbehy - indexy uvádzajúce možné aplikácie systému. Je potrebné, aby bol každý príbeh zameraný na konkrétne obchodné ciele, aby sa dal otestovať a vyhodnotiť pomocou kvantitatívnych ukazovateľov. mesiac je dosť prijateľný čas formulovať príbehy pre 10 osoboročný projekt. Je jasné, že tento čas nestačí na podrobné preštudovanie všetkých možné problémy. Ale nikdy nebude dosť času na analýzu všetkých problémov, ak vôbec máte v úmysle prejsť k implementácii systému.

Verzia

Ako je možné vidieť na obr. 2, neimplementujeme všetky príbehy naraz. Zákazník si najskôr vyberie malý súbor najdôležitejších príbehov, ktoré spolu logicky súvisia. A my ich predovšetkým programujeme a uvádzame do prevádzky. Potom je všetko ostatné implementované.

Výber príbehov pre verziu systému možno prirovnať k nákupu v supermarkete. Idete do obchodu so sto dolármi vo vrecku. Najprv zvážte, čo potrebujete. Pozrite sa na cenovky. A rozhodnite sa, čo kúpiť. V plánovacej hre sú produkty príbehy a cenovky sú odhady príbehov. Váš rozpočet je určený počtom odhadovaných príbehov dodaných vývojovým tímom za danú jednotku času.

Kupujúci (zákazník) môže buď naplniť svoj košík (vybrať si sadu príbehov), potom mu programátori vypočítajú konečný termín ich implementácie, alebo stanoviť dátum, do ktorého programátori vypočítajú rozpočet a zákazník si vyzdvihne požadovaný počet príbehov pre prijatú sumu.

Iterácia

Cieľom každej iterácie je spustiť do produkcie niekoľko nových, testovaných a pripravených príbehov. Tento proces začína plánom, ktorý definuje, aké príbehy sa budú implementovať a ako vývojový tím túto úlohu splní. Zatiaľ čo vývoj prebieha, zákazník prichádza s funkčnými testami. Na konci iterácie by mali bežať testy a vývojári by mali byť pripravení na ďalšiu iteráciu.

Pri začatí plánovania iterácie vývojári opäť požiadajú zákazníka, aby vybral najhodnotnejšie príbehy, tentoraz spomedzi tých, ktoré zostávajú na implementáciu v tejto verzii. Vývojári rozdeľujú príbehy na úlohy – moduly, ktoré jeden človek zvládne za pár dní. Ak existuje niekoľko technických výziev, ako je napríklad presun do Nová verzia databázy, sú zahrnuté aj vo všeobecnom zozname.

Programátori potom preberajú zodpovednosť za implementáciu určitých úloh. Po rozdelení všetkých úloh programátor zodpovedný za úlohu vyhodnotí, tentoraz podľa počtu ideálnych programovacích dní. Potom sa zozbierajú odhady úloh všetkých programátorov tímu a ak niektorí plánujú venovať implementácii viac času a iní menej, podľa toho sa prerozdelí aj záťaž v tíme.

Počas iterácie programátori implementujú svoje úlohy. Po dokončení úloh je ich kód integrovaný do celkového systému a testovaný spolu s ním. Buď všetky testy prejdú úspešne, alebo kód nemožno integrovať do systému. Počas iterácie sa k celkovej sérii testov pridávajú funkčné testy poskytované zákazníkom. Na konci iterácie sa všetky testy pre jednotlivé moduly a všetky funkčné testy.

Úloha

Programátor, ktorý je za ňu zodpovedný, hľadá na implementáciu úlohy v prvom rade partnera, keďže finálny kód vždy píšu dvaja ľudia na tom istom stroji. Ak sa vyskytnú otázky týkajúce sa predmetu alebo metód implementácie, partneri usporiadajú krátke (15-minútové) stretnutie so zákazníkom a/alebo programátormi, ktorí sú oboznámení s problémami s kódovaním, ktoré sú s najväčšou pravdepodobnosťou spojené s kódom tejto úlohy počas implementácia.

Na základe výsledkov tohto stretnutia programátori zostavia zoznam testovacích prípadov, ktoré je potrebné spustiť pred dokončením úlohy. Zo zoznamu sa vyberie taký test, v ktorého implementácii sú programátori úplne presvedčení a pomocou ktorého budú môcť lepšie pochopiť podstatu problému. Píše sa testovací program. Ak to hneď funguje dobre, môžete ísť ďalej. Spravidla to však nie je bezproblémové. Ak test nefunguje, je možná jedna z nasledujúcich situácií:

• poznáme jednoduchý spôsob, ako to urobiť, a tak konáme;
• poznáme komplikovaný a veľmi frustrujúci spôsob, ako to urobiť, aby to fungovalo, ale rozumieme tomu, ako zmeniť architektúru systému a zabezpečiť, aby testovací prípad fungoval správne bez veľkého úsilia. Potom sa rozhodneme prepracovať systém;
• poznáme zložitý a nepríjemný spôsob, ako to urobiť, aby to fungovalo, a nevidíme žiadny spôsob, ako systém prepracovať, takže ideme ťažšou cestou.

Po vykonaní testu možno opäť pochopíme, ako systém vylepšiť, čo aj urobíme.

Je pravdepodobné, že počas implementácie testovacieho prípadu nájdeme ďalší testovací prípad, ktorý by mal tiež fungovať. Prinášame nový test do svojho zoznamu a pokračujte vo vývoji. Možno zistíme, že rozsah reštrukturalizácie systému presahuje požiadavky súčasného testu, potom túto skutočnosť napravíme a ideme ďalej. Naším cieľom je nakoniec zamerať sa na detaily a úspešne vyriešiť konkrétny problém, no zároveň nestratiť všeobecnú predstavu o systéme, ktorá vzniká pri intenzívnej práci na kódoch.

Test

Ak hovoríme o kľúčovej metóde XP, potom je to samozrejme testovanie jednotiek. Ako už teraz vidíte, testovanie jednotiek je nevyhnutnou súčasťou každodennej práce každého programátora. Dve funkcie robia proces testovania XP oveľa efektívnejším ako tradičné metódy: programátori píšu svoje vlastné testy a robia to pred kódovaním. Samozrejme, ak pristupujete k programovaniu ako k postupnému štúdiu problému a štúdium problému považujete za najefektívnejší prostriedok spätná väzba so zákazníkom budete mať najväčší úžitok z testov napísaných treťou stranou niekoľko dní alebo týždňov po dokončení kódovania. XP berie do úvahy konvenčnú múdrosť, že programátori nedokážu správne otestovať svoj vlastný kód, a preto od nich vyžaduje, aby pracovali vo dvojiciach.

Niektoré metodiky, najmä Cleanroom, zakazujú programátorom testovať av niektorých prípadoch dokonca zostavovať svoje programy. Programátor zvyčajne napíše kód, skompiluje ho, uistí sa, že funguje, a potom ho odošle nejakej testovacej organizácii. Tradičné metódy benchmarkingu sú krokovanie cez kód a premenné, interpretácia výsledkov tlačových príkazov, testovanie tlačidiel ponuky atď.

XP nezavádza žiadne nové testovacie techniky oproti konvenčným metódam. Ide len o to, že testovanie prebieha inou formou a namiesto toho, aby ste robili niečo, čo po dokončení testovania nezanechá stopy, vytvárate testy na dlhé obdobie. Tieto testy fungujú dnes, budú fungovať v deň dokončenia systémovej integrácie a nasledujúci deň, o týždeň a budúci rok. Dôvera v bežnú prevádzku každého jednotlivého testu postupne buduje dôveru medzi vývojármi v normálne fungovanie systému ako celku.

Ako už bolo uvedené, zákazníci prichádzajú aj s testami. Na začiatku iterácie musí zákazník nájsť tie faktory, ktoré ho presvedčia, že príbehy pre túto iteráciu sú plne implementované. Svoje myšlienky o tom formalizuje v testoch pre systém ako celok. Zákazník môže samostatne písať testy pomocou textových alebo grafických skriptovacích jazykov, alebo ich zveriť programátorovi, ktorý použije vlastné testovacie nástroje. Takéto testy tiež budujú dôveru, tentoraz dôveru zákazníka v správne fungovanie systému.

mas problemy?

Diskusia o jednej alebo druhej metóde programovania v podmienkach, kde funguje perfektne, nie je náročná. Oveľa zaujímavejšie je vedieť, čo urobíte, ak sa ocitnete v nepredvídanej alebo nežiaducej situácii.

Prehodnotenie vlastných schopností. Občas si na seba vezmete viac, ako dokážete zvládnuť. Je potrebné čo najviac minimalizovať počet takýchto situácií a čo najčastejšie sa uchyľovať ku kvantitatívnym hodnoteniam vašej práce. Ak zistíte, že ste preťažení, v prvom rade hľadajte príčinu v sebe. Analyzujte: možno ste príliš rozptýlení od riešenia praktických problémov. Ste plne odhodlaní testovať, spolupracovať s partnerom, prerábať systém a integrovať? Robíte viac, ako momentálne zákazník potrebuje?

Ak nedokážete nájsť vnútorné rezervy na urýchlenie vývoja, potom by ste mali požiadať zákazníka, aby vám pomohol. Ponechanie si zodpovednosti za pracovné zaťaženie, ktoré nemôžete zaručiť, zmarí plán, poškodí kvalitu systému a nakoniec ho urobí úplne nepoužiteľným. Nedovoľte si to. Prehodnoťte svoje schopnosti na základe skúseností, ktoré ste získali, a potom požiadajte zákazníka, aby prehodnotil svoje požiadavky. Ak ste schopní implementovať iba dva z troch príbehov, nechajte ho určiť, ktoré príbehy sa majú riešiť ako prvé a ktoré si ponechať pre ďalšiu iteráciu alebo verziu. Neexistuje taký príbeh, ktorého niektoré časti sú dôležitejšie ako iné? Potom môžete jeho implementáciu rozdeliť na etapy a naprogramovať relevantnejšie komponenty okamžite a menej dôležité o niečo neskôr.

Ak zákazník nespolupracuje. Predstavte si situáciu, že zákazník neakceptuje pravidlá vašej hry. Nevymýšľa testy, neuprednostňuje, neformuluje príbehy. Najprv sa pokúste nainštalovať dôverný vzťah so zákazníkom. Zvyšovaním funkcionality systému od iterácie po iteráciu dajte zákazníkovi možnosť kontrolovať proces vývoja. Ak vzájomná dôvera nefunguje, analyzujte, či je to vaša chyba. Robíte všetko pre efektívnu interakciu so zákazníkom?

Ak tento problém nedokážete vyriešiť sami, požiadajte o pomoc svojho zákazníka. Princípy XP jednoducho neumožňujú programátorom vyvíjať sa hádaním o potrebách svojich zákazníkov. Vysvetlite alebo ukážte zákazníkovi na príklade postupnosť práce v XP. Ak nezmení svoj postoj k vám, snažte sa, aby vaše argumenty boli opisnejšie. Ak sa ukáže, že v podstate nikomu okrem vás na riešení tohto problému nezáleží, možno má tento projekt v činnosti zákazníka nízku prioritu a vôbec by ste nemali trvať na jeho pokračovaní.

Fluktuácia zamestnancov. Predpokladajme, že jeden z členov tímu sa rozhodol odísť. Ocitnete sa v slepej uličke kvôli nedostatku potrebných dokumentov alebo správ? V prvom rade si všimnite, že určitá fluktuácia zamestnancov je dobrá pre vývojový tím a jeho jednotlivých členov. Bol by som, samozrejme, rád, aby sa ľudia pri odchode riadili pozitívnymi motívmi. Ak ide domov na konci budúceho týždňa, programátor vidí konkrétne pozitívne výsledky jeho aktivity, pravdepodobnosť jeho sklamania v práci a vzniku túžby odísť sa výrazne znižuje.

Ak niekto opustí projekt XP, vôbec to neznamená, že si so sebou vezme tajomstvá, ktoré pozná sám. Každú linku v systéme ovládajú vždy dvaja ľudia. A akákoľvek informácia sa dostane z pracovne, nespôsobí veľa škody na práci tímu, pretože vývojári budú môcť spustiť testy a skontrolovať, či sa bez ich vedomia nestalo niečo neočakávané.

Noví členovia XP tímu sa pri práci na prvých dvoch iteráciách obmedzujú na pomoc skúsenejšiemu partnerovi vo dvojici, štúdium testov a komunikáciu so zákazníkom. S pocitom väčšej dôvery vo svoje schopnosti budú môcť prevziať zodpovednosť za určitú úlohu. Počas vývoja niekoľkých ďalších iterácií sa výkon nováčikov natoľko zvyšuje, že sú schopní každému predviesť realizáciu konkrétnych úloh načas. Po niekoľkých mesiacoch sa už nedajú rozoznať od skúsených členov tímu.

Ťažkým problémom sú programátori, ktorí nie sú zvyknutí pracovať v tíme. XP je náročné, spoločné úsilie a nie každý sa dokáže prispôsobiť tomuto druhu práce. Možno bude potrebné vzdať sa starých návykov a to nie je vôbec jednoduché, najmä pre programátorov, ktorí si sami seba vysoko cenia. V konečnom dôsledku však mnohé formy spätnej väzby XP umožňujú presne určiť, kto môže a kto nemôže pracovať v tíme. Ak jeden z vás neustále neplní úlohu, integrácia jeho modulov vždy spôsobuje problémy ostatným členom tímu, nikdy sa nepokúša prerábať systém, nepracuje vo dvojici, netestuje atď. Každý v tíme pochopí, o čo ide. A celému tímu bude len lepšie, ak takýto človek odíde, bez ohľadu na jeho schopnosti a skúsenosti.

Meniace sa požiadavky. Problém problémov pre väčšinu vývojových systémov vôbec nie je taký pre XP. Projekt XP, ktorý bol vytvorený dnes na riešenie špecifických problémov, sa s rovnakou účinnosťou vyrovná s akýmikoľvek zmenami funkčnosti v budúcnosti. Bude jednoduchšie urobiť niečo podobné, čo už bolo urobené, keďže XP vyznáva princíp „každú myšlienku sformuluj raz a len raz“. Práve pri takomto spracovaní vzniká potreba najčastejšie. Ale aj v prípade, že sa objaví úplne nová požiadavka na systém, nemusíte unáhlene budovať nové mechanizmy na jeho fungovanie.

Na začiatku som nemal jasnú predstavu o prispôsobivosti XP zmenám. V prvej verzii XP bol proces výberu príbehu súčasťou plánovania verzie a príbehy boli priradené všetkým iteráciám vo verzii. Vývojári potom zistili, že s menším plánovacím úsilím by to mohli dosiahnuť najlepšie výsledky. Preto je teraz zákazník požiadaný, aby špecifikoval iba tie príbehy, ktoré by mali byť prítomné v ďalšej iterácii. Ak sa zobrazí nový príbeh, dáte si ho do rezervy a zvyšok iterácie nepremiešate. Za jeden alebo dva týždne, ak nový príbeh ešte nestratil na aktuálnosti, zákazník si ho vyberie.

Plánovaním vždy jednej iterácie dosiahneme postupný sebarozvoj a sebapodobnosť systému. Na škále mesiacov a rokov sa zaoberáme históriou danej verzie systému a následne históriou budúcich verzií. Na škále týždňov a mesiacov sa zaoberáme príbehmi tejto iterácie a potom príbehmi, ktoré zostávajú v tejto verzii. Na škále dní a týždňov sa zaoberáme úlohou, na ktorej práve pracujeme, a potom úlohami zostávajúcimi v iterácii. Nakoniec, na škále minút a dní, sa zaoberáme testom, ktorý práve prebieha, a potom ďalšími testovacími prípadmi, ktoré môžeme vymyslieť.

XP je bezpochyby elegantný, logicky úplný nápad. Hranice jeho použiteľnosti zatiaľ nie sú úplne jasné. Ak teraz použijete tento prístup, musíte preukázať určitú odvahu, flexibilitu a ochotu opustiť projekt, ak zlyhá. XP treba najskôr vyskúšať v tých projektoch, kde sú výhody tohto prístupu zrejmé: pri vlastnom alebo vnútropodnikovom vývoji malých systémov, ktorých požiadavky nie sú jasne definované a môžu sa meniť.

Ak chcete zažiť XP, nesnažte sa robiť všetko naraz. Vyberte si pre vás najnepríjemnejší problém a skúste ho vyriešiť pomocou XP. Keď už tento problém nie je najnepríjemnejší, hľadajte ďalší a postup zopakujte. Keď budete pokračovať v ceste, pravdepodobne zistíte, že žiadna z vašich starých metód už nefunguje. Potom ich už nebudete môcť kontaktovať. Tento postupný proces začlenenia vám dáva šancu vyvinúť si vlastný štýl vývoja – ktorý vás povedie v každej situácii – a tým znížiť riziko problémov so systémom XP.

Silný rozdiel medzi obchodnými a technickými rozhodnutiami XP siaha až k práci architekta Christophera Alexandra. Jeho kniha The Timeless Way of Building poznamenáva, že tí, ktorí prevádzkujú budovu, musia mať možnosť robiť dôležité rozhodnutia počas jej výstavby.

Princípy XP pre rýchly vývoj plánu v súlade s technickými a obchodnými zmenami odrážajú princípy metodológie Scrum a jazyka šablón Episodes, ktorý vyvinul Ward Cunningham.

Myšlienka špecifikovať a naplánovať projekt z hľadiska realizovateľných možností siaha až do práce Ivara Jakobsona.

Tom Gilb je guru evolučného inžinierstva. Jeho najnovšie práce sa zameriavajú na uvedenie softvéru do prevádzky v priebehu niekoľkých týždňov, po ktorom nasleduje vývoj.

Špirálový model od Barryho Boehma bol prvou reakciou na zastaranie modelu vodopádu. Na dlhú dobu v ovládaní výkonných technológií nikto nedokázal prekonať Davea Thomasa a jeho kolegov z Object Technology International, ktorí vytvorili metódu JIT.

Korene princípu metafory použitej v XP možno nájsť v knihách Georga Lakoffa a Marka Johnsona, najmä v ich najnovšom diele Philoslphy in the Flesh. Tento princíp navrhol aj Richard Coine, ktorý prepojil metaforu a vývoj softvéru v zmysle postmodernej filozofie.

Napokon, veľká časť dôrazu XP na organizáciu kancelárie pochádza z práce Jima Copliena, Toma DeMarca a Tima Listera, ktorí zaznamenali vplyv podmienok prostredia na prácu programátorov.

Príklady vykonávania projektov pomocou XP

Acxiom: na ceste k dosiahnutiu spoločného cieľa

Ji Hannula

tím: manažéri, obchodní analytici, vývojári, testeri, technickí autori

Aplikácia: databáza správy kampaní

Doba realizácie: 3 roky

Acxiom vytvoril aplikáciu pre riadenie podniku založenú na dátovom sklade pomocou distribuovaného objektovo orientovaného vývojového súboru nástrojov Forte. Malý tím vývojárov – iba 10 ľudí – sa pri tvorbe aplikácie pevne držal princípov objektovo orientovaného programovania a kolaboratívneho vývoja. Z troch rokov, ktoré trvalo vývoj, za posledné dva roky tím, ktorý zahŕňal manažérov, obchodných analytikov, vývojárov, testerov a technických autorov, používal metódy extrémneho programovania a takto uspel.

Až donedávna spoločnosť Acxiom považovala projekt za úspešný, ak bol jednoduchý a niektoré z predtým vytvorených systémov sa mohli kvalifikovať ako súčasť novej aplikácie. Ukázalo sa však, že z toho nič dobré nebolo. Prepracovanie systému sa stalo kritickým prvkom vývoja. Jasne sme si uvedomili, že keď sa bojíme meniť tie časti programu, ktorých funkcie ešte nepoznáme, nemôžeme sa považovať za dobrých vývojárov. Necháme program, aby nás ovládal. Keby sme nevedeli čo daný kód, nebáli sme sa do toho pustiť a prísť na to. Je lepšie to urobiť sami určitú časť kódu, než aby sa celá aplikácia stala rukojemníkom jej samostatného kusu.

Veľa úsilia bolo vynaložené na testovanie jednotiek, pretože Forte neponúka vstavané základné testovacie nástroje. Museli sme si vytvoriť vlastné a použiť ich na úspešné testovanie. Nedávno sme prešli na programovací jazyk Java a teraz používame JUnit ako testovací nástroj.

Keď sme prvýkrát začali pracovať na princípoch XP, boli medzi nami programátori, ktorí nechceli používať jeho metódy. Mali pocit, že tieto metódy nevyhovujú štýlu programovania, ktorý vyvinuli, a bránili by im v produktivite. Výsledkom bolo, že väčšina problémov vznikla s komponentmi systému napísanými týmito ľuďmi. Títo vývojári ignorovali tímovú prácu a stali sa menejcennými v zručnostiach ako ostatní členovia tímu, ktorí využili príležitosť učiť sa jeden od druhého. Dvaja skúsení programátori, ktorí medzi sebou a zvyškom tímu úzko spolupracujú, vždy predčia „jednotlivca“ v zručnosti, aj keď má na čele sedem rán.

Uvedomili sme si, že každý člen tímu musí dodržiavať zásady XP, inak tento prístup nebude fungovať. Teraz ihneď upozorňujeme potenciálneho vývojára, že ak nie je spokojný s nami prijatým štýlom, mal by si radšej hľadať prácu v inom tíme. Jedna osoba, ktorá nemá záujem o zvolenú metódu rozvoja, môže anulovať úsilie celého tímu. Podstatou XP je kolektívny vývoj nových nápadov v procese vytvárania systému.

O HR panuje mylná predstava, že tento prístup potláča tvorivú činnosť a rozvoj individuálnych schopností vývojára. V skutočnosti je všetko presne naopak. XP stimuluje tvorivý rast programátora a dáva jednotlivým členom tímu šancu zažiariť. Hlavná vec je rozhodnúť sa a pevne sa držať zvoleného smeru.

„Extrémne programovanie“ nepostavilo náš tím do extrémnych podmienok. Táto metóda využíva dobre známe a do značnej miery známe vývojové prístupy. Všetci úzko spolupracujú a spoločne kráčajú k cieľu.

DaimlerChrysler: najlepší tím na svete

Chet Hendriksen

tím: 15 ľudí, z toho 10 programátorov

Aplikácia: plná automatizácia výpočtu miezd

Doba realizácie: 4 roky

Práce na projekte C3 sa začali v januári 1995. Chrysler Corporation uzavrela s partnerskou spoločnosťou zmluvu, podľa ktorej sa projektu ujal spoločný vývojový tím oboch organizácií. Naši partneri postupovali podľa metodiky vývoja zameranej na použitie GUI a ignoroval automatizáciu testov. Výsledkom bol systém, ktorý bol prešpikovaný nevýraznou grafikou a väčšine zamestnancov nesprávne vypočítal plat. Trvalo by asi 100 dní, kým by takýto systém vygeneroval mesačnú výplatnú pásku. Uvedomili sme si, že program, ktorý sme napísali, sa v skutočnosti nikdy nepoužije.

Oslovili sme Kenta Becka, aby nám pomohol vyladiť výkon systému. Našiel v nás rovnaké javy, s ktorými sa neustále stretáva, keď preberá úlohu ladenia výkonu: zle navrhnutý kód, testy, ktoré sa nedajú znova spustiť, manažment, ktorý stratil dôveru vo svoj projekt. Kent Beck odporučil zahodiť všetok napísaný kód a spustiť plnohodnotný projekt XP.

Predchádzajúca zmluva bola ukončená a Chrysler takmer z polovice aktualizoval svoj vývojový tím. Od tohto momentu sme konali podľa pravidiel XP. Boli pridelené zodpovednosti, naplánované iterácie, stanovené pravidlá testovania, testované párové programovanie a prijaté ako štandard. Na konci 33. týždňa sme mali systém, v ktorom sme už mohli začať ladiť výkon a vykonávať paralelné testovanie. Mohli sme začať ladiť výkon, keďže systém bol dobre premyslený a zálohovaný Plný set jednotkové testy. Boli sme pripravení na paralelné testovanie, pretože séria funkčných testov zákazníkovi jasne preukázala, že systém má požadované schopnosti.

Táto fáza implementácie C3 bola spustená v máji 1997, aj keď sme predpokladali skorší dátum. Neúspech našich plánov bol spôsobený dvoma faktormi. Najprv sme sa rozhodli vymeniť iba vnútorné komponenty platobný systém. Všetky externé rozhrania zostali nedotknuté. Výstup zápasu nový systém komponentov starého sa ukázalo oveľa viac náročná úloha než sme očakávali. Po druhé, rozhodli sme sa nezaviesť špeciálne požiadavky počas žiadneho výplatného obdobia, ako je spracovanie W-2, zdieľanie zisku alebo všeobecné zvýšenie platu. mzdy. V dôsledku toho sa to, čo sa malo urobiť v novembri, odložilo na apríl.

Od spustenia systému výpočtu mesačných platieb sme pridali niekoľko noviniek a automatizovaný výpočet dvojtýždenných platieb. Mzdy pre pilotnú skupinu sa počítajú od augusta 1998 a dúfame, že do novembra 1999 budeme mať funkčný systém pre ostatných zamestnancov.

Na základe skúseností získaných počas tohto dlhého vývoja môžem povedať, že očakávania nášho manažmentu a našich zákazníkov sme nenaplnili až vtedy, keď sme sa odklonili od princípov XP. Keď sa v priebehu vývoja stal rozhodujúci proces testovania, keď sme písali kód vo dvojiciach, keď boli implementované tie najjednoduchšie, s najväčšou pravdepodobnosťou fungujúce funkcie, zmenili sme sa na najlepší tím, aký mohol byť.

Ford Motor: jedinečná kombinácia účinnosti a kvality

Don Wells

tím: 17 ľudí, z toho 12 programátorov

Aplikácia: systém analýzy nákladov

Doba realizácie: 6 rokov

Divízia finančných systémov spoločnosti Ford Motor Company vyvíja analytický systém Vehicle Costing and Profit System (VCAPS), ktorý generuje správy o tržbách z výroby, výdavkoch, čistom zisku a zisku. Vstupmi do systému sú špecifikácie inžinierskych produktov, fixné náklady a výdavky a variabilné náklady, ako je pracovný čas. VCAPS agreguje všetky tieto údaje a pripravuje podrobné správy s analýzou nákladov, ktoré umožňujú efektívne predpovedanie a podnikové rozhodovanie. Práce na projekte VCAPS sa začali v roku 1993. Vyvinuté pomocou VisualWorks a GemStone Smalltalk. VCAPS je v súčasnosti udržiavaný malým tímom ľudí a čoskoro bude nahradený modernejšou aplikáciou.

Pri realizácii projektu VCAPS sme museli riešiť dva vážne problémy. Po prvé, analytici chceli vykonať zmeny v systéme a zároveň získať nové funkcie, ktoré už fungovali. Požiadavky sa neustále menili a my sme s nimi jednoducho nemohli držať krok. Po druhé, existovali určité obmedzenia týkajúce sa prevádzkového času systému. Systém zároveň strávil veľa času spracovaním údajov a vyžadoval manuálne zadávanie dlhých sekvencií. Akákoľvek chyba viedla k potrebe reštartu a strate drahocenného času.

S pomocou XP sme dosiahli jedinečnú kombináciu schopností: dokázali sme rýchlo reagovať na neustále sa meniace požiadavky a dosiahli kvalitu systému, ktorá nám umožnila vyhnúť sa nebezpečným reštartom.

Práca na metódach XP sa začala vo fáze plánovania. A ukázalo sa, že to bola chyba. Zákazníci a manažment nie sú zvyknutí spoločne riešiť pracovné plány. To, čo sa stalo v dôsledku toho, trpelo nedostatkom vierohodnosti a praktickej použiteľnosti. Museli sme prejsť na plány MS Project, ktoré sa dali zmeniť bez usporiadania valných zhromaždení a pomocou ktorých sme dostali plány vo forme známej vedeniu.

Potom sme vykonali niekoľko jednotkových testov a po roku bolo otestovaných 40 % systému a vedenie zaznamenalo 40 % zníženie počtu chybových hlásení. Potom sa XP dostalo veľkej pozornosti.

Problémy sme vyriešili implementáciou všetkých nových metód XP. Testy nám umožnili prejsť na nepretržitú integráciu a časté zmeny verzií. To zase pripravilo cestu pre kolektívne vlastníctvo a prepracovanie systému. Naším cieľom bolo vytvoriť jednoduchý projekt. Nakoniec prišiel moment, keď sme sa rozhodli vyskúšať programovanie vo dvojici. A na dosiahnutie tohto úspechu sme museli tvrdo pracovať. Spočiatku naši vývojári považovali túto metódu za mimoriadne nepohodlnú; Chvíľu trvalo, kým som si zvykol a cítil sa v ňom celkom pohodlne.

Po roku a pol sa počet porúch systému znížil natoľko, že naši zákazníci a manažment mohli konštatovať výrazne vyššiu stabilitu systému. Pre nás to symbolizovalo úspech princípov XP.

Tarifný systém: testy, ktoré si môžete prečítať

Rob Mi

tím: traja vývojári

Aplikácia: systém výpočtu prepravnej tarify

Doba realizácie: 3 mesiace

Tarifný systém je súčasťou veľkého projektu realizovaného pomocou SmallTalk/GemStone v jednej z významných medzinárodných spoločností špecializujúcich sa na kontajnerovú prepravu. Prístup XP umožnil prejsť všetkými fázami vývoja tohto subsystému, od koncepcie až po uvedenie do prevádzky, za tri mesiace troma ľuďmi. Výsledok bol pozoruhodne stabilný a ľahko sa udržiaval.

Po začatí práce na projekte sme sa hneď rozhodli pevne dodržiavať niekoľko základné princípy XP: vždy kódujte v pároch, udržujte architektúru čo najjednoduchšiu, aktívne prerábajte systém a píšte veľa jednotkových testov. Všetky tieto princípy sa ukázali ako účinné. Jedna myšlienka XP sa nám spočiatku zdala trochu pritažená za vlasy – napísať testy pre kód skôr, ako sa napíše skutočný kód. O to viac nás prekvapilo zistenie, že tento princíp nám umožňuje identifikovať architektonické problémy a urýchľuje proces vývoja.

Od začiatku sme používali inú XP metódu – zbieranie požiadaviek používateľov formou príbehov. Výsledky neboli úplne jednoznačné. Sme programátori a venujeme sa predovšetkým kódovaniu, teda hľadaniu bežný jazyk s používateľmi sa pre nás stalo výzvou. Aby sme to ešte viac skomplikovali, chceli sme príbehy od používateľov, ktoré boli relevantné a jednoznačné, a preto sme im museli aktívne pomáhať. Nakoniec sme prišli na to, že XP chýbala jedna špeciálna rola. Potrebovali sme človeka, ktorého hlavnou úlohou by bola interakcia s používateľmi. Je zrejmé, že musí mať zodpovedajúce schopnosti.

Pri vytváraní a prepracovaní testovacích prípadov sme si uvedomili, že na písanie základných doménových objektov budú veľmi užitočné malé jazyky špeciálne vymyslené pre ne, vďaka čomu sa testovací kód stane oveľa prehľadnejším a čitateľnejším. Okrem toho sme prestali strácať čas vymýšľaním spôsobov, ako nastaviť inštancie objektov v procese písania testov, a definovali sme gramatiky pre desať doménových tried. Gramatika automaticky generuje syntaktický analyzátor, ktorý používa konštruktor na vytvorenie objektu domény. Kód na vytvorenie inštancie objektu pomocou štandardných konštruktorov bude veľmi dlhý, takmer nečitateľný a bude sa len málo podobať na samotný testovací prípad.

Prijatie zmien pomocou extrémneho programovania, Kent Beck. Počítač, október 1999, str. 70-77, Pretlačené so súhlasom, Copyright IEEE, 1999, Všetky práva vyhradené.

Extreme Programming (XP) je zjednodušená metodika vývoja softvéru pre malé až stredne veľké vývojové tímy, ktoré vytvárajú softvérový produkt s nejasnými alebo rýchlo sa meniacimi požiadavkami.

Hlavnými cieľmi XP sú zvýšenie dôvery zákazníkov k softvérovému produktu poskytnutím reálnych dôkazov o úspešnosti vývoja procesu vývoja a výrazné skrátenie času vývoja produktu . XP je zároveň zameraný na minimalizáciu chýb v raných fázach vývoja. To umožňuje dosiahnuť najvyššia rýchlosť uvoľnenie hotového výrobku a umožňuje hovoriť o predvídateľnosti práce. Takmer všetky techniky XP sú zamerané na zlepšenie kvality softvérového produktu.

Princípy XP

Hlavné zásady sú:

• Iterácia. Vývoj prebieha v krátkych iteráciách za prítomnosti aktívneho vzťahu so zákazníkom. Iterácie ako také sú navrhované ako krátke, odporúčaná dĺžka trvania je 2-3 týždne a nie viac ako 1 mesiac. V jednej iterácii musí skupina programátorov implementovať niekoľko funkcií systému, z ktorých každá je opísaná v používateľskom príbehu. Používateľské príbehy (UI) sú v tomto prípade prvotné informácie, na základe ktorých je modul vytvorený. Líšia sa od prípadov použitia (UT). Popis PI je krátky - 1-2 odseky, pričom PI je zvyčajne popísaný dostatočne podrobne, s hlavnými a alternatívnymi tokmi a je doplnený o model. Používateľské rozhrania sú písané samotnými používateľmi, ktorí sú v XP súčasťou tímu, na rozdiel od používateľských rozhraní, ktoré popisuje systémový analytik. Nedostatok formalizácie popisu vstupných údajov projektu v XP sa snaží kompenzovať aktívnym začlenením zákazníka do procesu vývoja ako plnohodnotného člena tímu.
• Jednoduchosť riešení. Je prijaté prvé najjednoduchšie pracovné riešenie. Extrémna povaha metódy je spojená s vysoký stupeň riziko rozhodnutia v dôsledku povrchnosti analýzy a rigidného časového harmonogramu. Minimálny súbor hlavných funkcií systému je implementovaný pri prvej a každej ďalšej iterácii; funkčnosť sa rozširuje pri každej iterácii.
• Intenzívny vývoj v malých tímoch(nie viac ako 10 ľudí) a párové programovanie(keď dvaja programátori spoločne vytvárajú kód na jednom spoločnom pracovisku), aktívna komunikácia v rámci skupiny a medzi skupinami. To všetko je zamerané na čo najskoršie odhalenie problémov (chyby aj zmeškané termíny). Párové programovanie je zamerané na riešenie problému stabilizácie projektu. Pri použití metodiky XP je vysoké riziko straty kódu v dôsledku odchodu programátora, ktorý nevydržal intenzívny pracovný režim. V tomto prípade hrá druhý programátor z dvojice úlohu „dediča“ kódu. Dôležité je aj to, ako sú skupiny rozmiestnené v pracovnom priestore – XP používa otvorený pracovný priestor, čo znamená rýchly a bezplatný prístup pre každého ku každému.
• Spätná väzba od zákazníka, ktorej zástupca sa skutočne podieľa na procese vývoja.
• Dostatočná miera odvahy a ochotu riskovať.

XP triky (cvičenia)

XP sa zvyčajne vyznačuje súborom 12 pravidiel (praxov), ktoré sa musia dodržiavať, aby sa dosiahli dobrý výsledok. Žiadna z praktík nie je zásadne nová, ale sú spojené v XP.

1. Plánovanie procesov. Zíde sa celý vývojový tím, prijme sa kolektívne rozhodnutie o tom, ktoré vlastnosti systému budú implementované v ďalšej iterácii. Zložitosť implementácie každej vlastnosti určujú samotní programátori.
2. Úzka interakcia so zákazníkom. Zástupca zákazníka musí byť členom tímu XP. Napíše používateľské rozhranie, vyberie príbehy, ktoré budú implementované v konkrétnej iterácii, a odpovie na otázky súvisiace s podnikaním. Zástupca zákazníka musí byť odborník v automatizovanej tematickej oblasti. Je potrebné mať neustálu spätnú väzbu od zástupcu zákazníka.
3. Všeobecné pravidlá pre pomenovanie systému. Dobré konvencie pomenovania systému jednoduchosť pomenovania triedy a premenné. Vývojový tím by mal mať jednotné konvencie pomenovania.
4. Jednoduchá architektúra. Akákoľvek vlastnosť systému by mala byť implementovaná čo najjednoduchšie. Programátori v tíme XP pracujú pod heslom: „Nič viac!“. Je prijaté prvé jednoduché pracovné riešenie, v súčasnosti sa implementuje požadovaná úroveň funkčnosti. To šetrí čas programátora.
5. Refaktorovanie. Ide o optimalizáciu existujúceho kódu za účelom jeho zjednodušenia. Takáto práca by mala byť vykonávaná neustále. Tým, že kód bude transparentný a jeho prvky budú definované iba raz, programátori znížia počet chýb, ktoré musia byť neskôr opravené. Pri implementácii každej novej vlastnosti systému musí programátor zvážiť, či je možné existujúci kód zjednodušiť a ako to pomôže implementovať novú vlastnosť. Okrem toho nemôžete kombinovať refaktoring s dizajnom: ak tvoríte nový kód, refaktoring by sa mal odložiť.
6. Párové programovanie. Všetci programátori by mali pracovať vo dvojiciach: jeden píše kód, druhý sa pozerá. Preto je potrebné umiestniť skupinu programátorov na jedno miesto. XP funguje najlepšie v nedistribuovaných tímoch programátorov a používateľov.
7. 40 hodinový pracovný týždeň. Programátor by nemal pracovať viac ako 8 hodín denne. Potreba nadčasov je jasným indikátorom problému v tejto konkrétnej oblasti rozvoja. Hľadanie príčin nadčasov a ich promptné odstraňovanie je jedným zo základných pravidiel.
8. Kolektívne vlastníctvo kódu. Každý programátor v tíme musí mať prístup ku kódu ktorejkoľvek časti systému a právo vykonávať zmeny v akomkoľvek kóde. Povinné pravidlo: ak programátor urobil zmeny a systém potom nefunguje správne, potom je to programátor, ktorý musí opraviť chyby.
9. Jednotné štandardy kódovania.Štandardy kódovania sú potrebné na podporu iných postupov: zdieľanie kódu, párové programovanie a refaktoring. Bez jediného štandardu je vykonávanie týchto praktík prinajmenšom ťažšie, ale v skutočnosti je to vo všeobecnosti nemožné: skupina bude pracovať v režime neustáleho nedostatku času. Tím pracuje na projekte už dlho. Ľudia prichádzajú a odchádzajú. Nikto nekóduje sám a kód patrí všetkým. Vždy budú chvíle, keď bude potrebné pochopiť a opraviť kód niekoho iného. Vývojári odstránia duplicitný kód, analyzujú a vylepšia triedy iných ľudí atď. Postupom času nebude možné zistiť, kto je autorom konkrétnej triedy. Preto sa každý musí podriadiť bežným štandardom kódovania – formátovanie kódu, pomenovanie tried, premenná, konštantné pomenovanie, štýl komentára. Vyššie uvedené znamená, že všetci členovia tímu sa musia dohodnúť na spoločných štandardoch kódovania. Bez ohľadu na to, ale každý je povinný ich poslúchať.
10. Malé vydania. Minimálna iterácia je jeden deň, maximálna je mesiac; čím častejšie sa budú uvoľňovať, tým viac chýb v systéme bude odhalených. Prvé vydania pomáhajú identifikovať nedostatky v najskorších štádiách, potom sa funkčnosť systému rozširuje na základe používateľského rozhrania. Keďže používateľ je zahrnutý do procesu vývoja od prvého vydania, hodnotí systém a vydáva používateľský príbeh a komentáre. Na základe toho sa určí ďalšia iterácia, teda aké bude nové vydanie. Všetko o XP je o poskytovaní nepretržitej spätnej väzby používateľom.
11. Nepretržitá integrácia. K integrácii nových častí systému by malo dochádzať čo najčastejšie, aspoň raz za niekoľko hodín. Základné pravidlo integrácie je nasledovné: integráciu je možné vykonať, ak úspešne prejdú všetky testy. Ak testy neprejdú, potom musí programátor buď vykonať opravy a následne komponenty systému integrovať, alebo ich neintegrovať vôbec. Toto pravidlo je pevné a jednoznačné. Ak je vo vytvorenej časti systému aspoň jedna chyba, integráciu nie je možné vykonať. Častá integrácia vám umožňuje rýchlejšie získať hotový systém namiesto toho, aby ste strávili týždeň montážou.
12. Testovanie. Na rozdiel od väčšiny ostatných metodík je testovanie v XP jednou z najdôležitejších súčastí. Extrémny prístup to predpokladá testy sa píšu pred napísaním kódu . Každý modul musí mať unit test – test pre tento modul. XP teda pri pridávaní funkcionality vykonáva regresné testovanie, „neznižovanie kvality“. Väčšina chýb je opravená vo fáze kódovania. Testy si píšu programátori sami, každý z nich má právo napísať test pre ktorýkoľvek modul. Ďalší dôležitý princíp: test určuje kód a nie naopak (testom riadený vývoj), to znamená, že časť kódu sa umiestni do úložiska vtedy a len vtedy, ak všetky testy prešli úspešne, inak je táto zmena kódu zamietnutá.

Proces XP je neformálny, ale vyžaduje si vysokú úroveň sebadisciplíny. Ak sa toto pravidlo nedodrží, XP sa okamžite zmení na chaotický a nekontrolovaný proces. XP nevyžaduje od programátorov, aby písali veľa správ a zostavovali veľa modelov. V XP je každý programátor považovaný za kvalifikovaného pracovníka, ktorý je profesionálny a zodpovedný za svoje povinnosti. Ak to tím nemá, potom je absolútne zbytočné implementovať XP - je lepšie začať s prestavbou tímu. Riziko vývoja sa znižuje iba v tíme, ktorý sa ideálne hodí pre XP, vo všetkých ostatných prípadoch je XP vývojovým procesom s najvyšším stupňom rizika, pretože jednoducho neexistujú žiadne iné metódy znižovania komerčných rizík, okrem ľudského faktora. XP.

A ďalšie.

Názov metodiky pochádza z myšlienky použiť užitočnú tradičné metódy a postupy vývoja softvéru, ktoré ich povýšia na novú „extrémnu“ úroveň. Takže napríklad prax vykonávania revízie kódu, ktorá spočíva v tom, že jeden programátor kontroluje kód napísaný iným programátorom, v „extrémnej“ verzii je „párové programovanie“, keď jeden programátor kóduje a jeho partner na zároveň priebežne kontroluje novo napísaný kód.

Encyklopedický YouTube

1 / 5

Extrémne programovanie (XP) – základné techniky

Hexlet Webinár č. 6: Extrémne programovanie

rady do života. Prečo sa zúčastniť programátorských súťaží?

032. Párové programovanie - Sergey Berezhnoy

Kanál extrémneho programovania v. 2.0

titulky

XP základné triky

Dvanásť základných techník extrémneho programovania (podľa prvého vydania knihy Extrémne programovanie vysvetlené) možno rozdeliť do štyroch skupín:

• Krátky cyklus spätnej väzby (spätná väzba v jemnom rozsahu)
  • Vývoj cez testovanie (testom riadený vývoj)
  • Plánovacia hra
  • Zákazník je vždy prítomný (celý tím, zákazník na mieste)
  • Párové programovanie
• Nepretržitý, nie dávkový proces
  • Nepretržitá integrácia
  • Refaktoring (vylepšenie dizajnu, Refaktoring)
  • Časté malé uvoľnenia
• Porozumenie zdieľané všetkými
  • Jednoduchosť
  • Metafora systému
  • Kolektívne vlastníctvo kódu alebo vybrané vzory návrhu (kolektívne vlastníctvo vzorov)
  • Kódovací štandard alebo kódovacie konvencie
• Sociálne zabezpečenie programátora (Programmer welfare):
  • 40-hodinový pracovný týždeň (trvalo udržateľné tempo, 40-hodinový týždeň)

Testovanie

XP zahŕňa písanie automatických testov (programový kód napísaný špeciálne na testovanie logiky iného programový kód). Osobitná pozornosť sa venuje dvom typom testovania:

• jednotkové testovanie modulov;

Vývojár si nemôže byť istý správnosťou kódu, ktorý napíše, kým nefungujú absolútne všetky unit testy systému, ktorý vyvíja. Unit testy (unit testy) umožňujú vývojárom uistiť sa, že každý z nich samostatne funguje správne. Pomáhajú tiež ostatným vývojárom pochopiť, prečo je konkrétny kód potrebný a ako funguje - v priebehu štúdia testovacieho kódu sa logika testovaného kódu vyjasní, pretože je jasné, ako by sa mal používať. Jednotkové testy tiež umožňujú vývojárovi refaktorovať bez akéhokoľvek strachu.

Funkčné testy sú určené na testovanie fungovania logiky tvorenej interakciou niekoľkých (často dosť pôsobivých rozmerov) častí. Sú menej podrobné ako unit testy, ale pokrývajú oveľa viac – teda testy, ktoré pri svojom vykonávaní ovplyvňujú väčšie množstvo kódu, majú samozrejme väčšiu šancu odhaliť nejaké nesprávne správanie. Z tohto dôvodu má v priemyselnom programovaní písanie funkčných testov často prednosť pred písaním jednotkových testov.

Pre XP je vyššou prioritou prístup nazývaný TDD (z anglického test-driven development - vývoj cez testovanie). V súlade s týmto prístupom sa najskôr napíše test, ktorý na začiatku zlyhá (pretože logika, ktorú by mal kontrolovať jednoducho ešte neexistuje), potom sa implementuje logika potrebná na to, aby test prešiel. TDD vám v istom zmysle umožňuje písať kód, ktorý je pohodlnejší na použitie - pretože pri písaní testu, keď ešte neexistuje logika, je najjednoduchšie postarať sa o pohodlie budúceho systému.

Plánovacia hra

Hlavným cieľom plánovacej hry je rýchlo vytvoriť hrubý pracovný plán a neustále ho aktualizovať, keď sa podmienky úlohy vyjasnia. Artefakty plánovacej hry sú súbor papierových kartičiek obsahujúcich priania zákazníka (príbehy zákazníkov) a hrubý pracovný plán na vydanie ďalšej jednej alebo viacerých malých verzií produktu. Kritickým faktorom, ktorý robí tento štýl plánovania efektívnym, je, že v tomto prípade je zákazník zodpovedný za obchodné rozhodnutia a vývojový tím je zodpovedný za technické rozhodnutia. Ak sa toto pravidlo nedodrží, celý proces sa rozpadne.

Zákazník je tu vždy

„Zákazník“ v XP nie je ten, kto platí účty, ale konečný užívateľ softvérového produktu. XP tvrdí, že zákazník musí byť neustále v kontakte a dostupný pre otázky.

Párové programovanie

Párové programovanie predpokladá, že celý kód vytvárajú dvojice programátorov pracujúcich na tom istom počítači. Jeden z nich pracuje priamo s textom programu, druhý sa pozerá na jeho prácu a sleduje celkový obraz toho, čo sa deje. V prípade potreby sa klávesnica voľne prenáša z jednej na druhú. Pri práci na projekte nie sú dvojice pevne dané: odporúča sa ich pomiešať, aby mal každý programátor v tíme dobrú predstavu o celom systéme. Týmto spôsobom párové programovanie zlepšuje interakciu v rámci tímu.

Nepretržitá integrácia

Ak dostatočne často integrujete vyvíjaný systém, môžete sa vyhnúť väčšine problémov s tým spojených. V tradičných metódach sa integrácia spravidla vykonáva na samom konci práce na produkte, keď sa predpokladá, že všetky komponenty vyvíjaného systému sú úplne pripravené. V XP sa kódová integrácia celého systému vykonáva niekoľkokrát denne po tom, čo sa vývojári ubezpečia, že všetky testy jednotiek fungujú správne.

Refaktorovanie

Refaktoring je technika na zlepšenie kódu bez zmeny jeho funkčnosti. XP znamená, že akonáhle je kód napísaný, bude takmer určite mnohokrát prepracovaný v priebehu projektu. Vývojári XP nemilosrdne prepracúvajú predtým napísaný kód, aby ho vylepšili. Tento proces sa nazýva refaktoring. Nedostatočné pokrytie testov vyvoláva odmietnutie refaktoringu z dôvodu strachu z prelomenia systému, čo vedie k postupnej degradácii kódu.

Časté malé uvoľnenia

Verzie (vydania) produktu by mali ísť do výroby čo najčastejšie. Práca na každej verzii by mala trvať čo najmenej času. Každá verzia by mala byť zároveň dostatočne zmysluplná z hľadiska užitočnosti pre podnikanie.

Čím skôr je vydaná prvá pracovná verzia produktu, tým skôr zákazník vďaka nej začne získavať dodatočný zisk. Pamätajte, že peniaze zarobené dnes majú väčšiu hodnotu ako peniaze zarobené zajtra. Čím skôr začne zákazník produkt používať, tým skôr od neho vývojári dostanú informácie o tom, čo spĺňa požiadavky zákazníka. Tieto informácie môžu byť mimoriadne užitočné pri plánovaní ďalšieho vydania.

Jednoduchosť dizajnu

XP vychádza zo skutočnosti, že v procese práce sa podmienky problému môžu opakovane meniť, čo znamená, že vyvíjaný produkt by nemal byť navrhnutý vopred úplne a úplne. Pokúšať sa navrhnúť systém do detailov hneď na začiatku práce je strata času. XP naznačuje, že návrh je taký dôležitý proces, že sa musí vykonávať nepretržite počas životnosti projektu. Návrh by sa mal vykonávať v malých krokoch, pričom treba brať do úvahy neustále sa meniace požiadavky. V každom okamihu by ste sa mali pokúsiť použiť najjednoduchší návrh, ktorý vyhovuje aktuálnemu problému, a zmeniť ho podľa toho, ako sa zmenia podmienky problému.

Metafora systému

Architektúra je reprezentácia komponentov systému a ich vzájomných vzťahov. Vývojári musia analyzovať softvérovú architektúru, aby pochopili, kde v systéme potrebujú pridať novú funkčnosť a s čím bude nový komponent interagovať.

Metafora systému je analogická tomu, čo väčšina techník nazýva architektúra. Metafora systému dáva tímu predstavu o tom, ako systém momentálne funguje, kde sa pridávajú nové komponenty a akú formu by mali mať.

Výber dobrej metafory uľahčuje vývojovému tímu pochopiť, ako systém funguje. Niekedy to nie je jednoduché.

Štandardy kódovania

Všetci členovia tímu musia v priebehu práce spĺňať požiadavky spoločných kódovacích štandardov. Týmto:

• členovia tímu nestrácajú čas dohadovaním sa o veciach, ktoré v skutočnosti nemajú vplyv na rýchlosť práce na projekte;
• je zabezpečená efektívna implementácia iných postupov.

Ak tím nepoužíva jednotné kódovacie štandardy, pre vývojárov je ťažšie refaktorovať; pri výmene partnerov v pároch je viac ťažkostí; vo všeobecnosti je postup projektu ťažký. V rámci XP je potrebné zabezpečiť, aby bolo ťažké pochopiť, kto je autorom toho či onoho kódu - celý tím pracuje jednotne, ako jedna osoba. Tím musí vytvoriť súbor pravidiel a každý člen tímu musí tieto pravidlá počas procesu kódovania dodržiavať. Zoznam pravidiel by nemal byť vyčerpávajúci ani príliš objemný. Úlohou je sformulovať všeobecné pokyny, vďaka ktorým bude kód zrozumiteľný pre každého člena tímu. Kódovací štandard by mal byť spočiatku jednoduchý, potom sa môže postupne stať zložitejším, keď bude vývojový tím získavať skúsenosti. Nie je potrebné venovať príliš veľa času predbežnému návrhu normy.

Kolektívne vlastníctvo

Kolektívne vlastníctvo znamená, že každý člen tímu je zodpovedný za všetok zdrojový kód. Každý má teda právo vykonávať zmeny v ktorejkoľvek časti programu. Párové programovanie podporuje túto prax: všetci programátori sa pri práci v rôznych pároch zoznámia so všetkými časťami kódu systému. Dôležitou výhodou kolektívneho vlastníctva kódu je, že urýchľuje proces vývoja, pretože keď sa vyskytne chyba, každý programátor ju môže opraviť.