5. diel - Extrémne programovanie

V predchádzajúcej lekcii, Lean Software Development a Kanban , sme sa pozreli na "štíhly" vývoj softvéru a na jednu veľmi nápomocnú nástenku.

V tejto lekcii si vysvetlíme pojem extreme programming. Ukážeme si jeho prvky a popíšeme proces.

Extrémne programovanie

Extreme programming (extrémne programovanie) je ďalší metodika vývoja softvéru. Táto metodika nespočíva v zavádzaní úplne nových postupov a odporúčaní, ale extremizuje tie doterajšie, nám už známej postupy a odporúčania z predošlých lekcií.

Extremizované prvky

Ako presne Extreme Programming (skrátene XP) extremizuje doterajšie princípy? Osvedčila sa revízia kódu? Kód sa teda bude revidovať neustále. Toho je napríklad dosiahnuť spôsobom, ktorému sa hovorí programming in pairs (programovanie v páre), kedy u jednej pracovnej stanice sedia dvaja programátori. Jeden píše kód (driver, vodič) a druhý kód kontroluje (Observer, pozorovateľ). Títo dvaja programátori sa pravidelne vo svojich rolách striedajú. Zatiaľ čo jeden píše kód, druhý pozoruje, aké problémy môžu vzniknúť a ktoré bude potrebné ošetriť a tiež akým strategickým smerom by sa mala práca vydať. To dáva vodičovi možnosť plne sa sústrediť na písanie kódu, zatiaľ čo pozorovateľ slúži ako jeho záchranná sieť. Toto riešenie môže síce zabrať viac času, ale výsledný kód bude obsahovať výrazne menej defektov.

Ďalším zextremizovaným prvkom je testovanie. Dodať niekomu produkt bez toho, aby bol testovaný, je hlúposť. V Extreme Programming sa však testuje stále a neustále. Využívajú sa tu jednotkové testy (unit testing) napísané programátorov. Tieto testy sú svojím rozsahom často oveľa rozsiahlejšie, než výsledný produkt. Snaží sa totiž otestovať každú možnosť, na ktoré by mohol program zlyhať. Netestujú však iba programátori pomocou ručne napísaných testov, ale aj zákazníci, ktorí testujú, či program skutočne robí to, čo po ňom požadujú. Testovanie v oboch prípadoch prebieha neustále. Pred zmenou kódu, po zmene kódu a taky počas zmeny kódu. Testuje sa, či sa funkcionalita programu nijako nepoškodila.

Prípadné bugy v programe nie sú logické chyby, ale chýbajúce testy.

Návrh kódu často robí osoba, ktorá je na to určená. Tu však navrhuje kód každý, kto je toho schopný a robí to neustále. Refaktorizací ( úprava kódu vhodnejšie alternatívou) sa zaoberá každý a návrh kódu môže vhodne upravovať.

Programovať zložité programy by sa malo len v tých najnutnejších prípadoch, kedy to bohužiaľ nejde inak. V Extreme Programming sa vývoj programu snažíme udržať na tej najmenšej možnej úrovni zložitosti. Toho sa darí napríklad programovaním iba toho, čo je pre danú chvíľu naozaj nevyhnutné. Nepridáva sa žiadna omáčka navyše. Snažíme sa vytvoriť čo najjednoduchší program, ktorý bude spĺňať požadovanú funkcionalitu a bude fungovať korektne.

To isté platí aj o nám už dobre známych krátkych vývojových opakovaniach, ktoré poznáme z predchádzajúcich metodík. Tu sa extremizuje skracovaním týchto cyklov na veľmi krátku dobu. Bavíme sa tu o dňoch či hodinách, namiesto týždňov a mesiacov. Akonáhle je nová funkcionalita pripravená a riadne otestovaná, ihneď sa integruje do produkčnej verzie programu.

Hodnoty vhodné k dodržiavaniu

Ako to bolo už v predošlých lekciách, tak aj tu sa uznávajú nejaké základné hodnoty.

• Komunikácia je jedna z najdôležitejších vecí pri vývoji softvéru. Či už je to komunikácia vnútri tímu alebo komunikácie so zákazníkom. Ak zlyhá komunikácia medzi niektorými zainteresovanými subjektmi, veľmi pravdepodobne zlyhá aj výsledný produkt. Bez riadnej komunikácie sa nebude vedieť, aký produkt sa má vlastne vytvoriť. Extreme Programming prichádza s postupmi, ktoré komunikáciu priamo vyžadujú, medzi ktoré patrí napríklad už spomínané párové programovanie.
• Plytvanie sa v Extreme Programming snaží čo najviac predísť. Kód musí byť čo najjednoduchšie, nesmie obsahovať zbytočnosti navyše. Programuje sa len to, čo zákazník naozaj chce. Práca sa sústredí hlavne na aktuálne požiadavky. Nie na to, čo sa očakáva, že zákazník možno bude chcieť. Požiadavky zákazníka sa môžu kedykoľvek zmeniť, a preto sa neprogramuje nič, čo by sa ďalší deň mohlo zahodiť do koša.
• Spätná väzba je dôležitá nielen pri vývoji softvéru. Tú nám svojím spôsobom poskytujú spomínané jednotkové testy, ktoré slúžia na kontrolu, že program pracuje tak, ako má a že sa pri poslednej úprave programu nič nerozbilo. To isté robia aj zákazníci, ktorí testujú, či program spĺňa nimi požadovanú funkcionalitu. Spätnej väzby sa tu dočkajú tiež zákazníci, ktorí sú informovaní o tom, ako vývoj pokračuje a ako dlho bude trvať.
• Ďalšou veľmi uznávanou hodnotou tohto štýlu vývoja softvéru je guráž. Tu napríklad potrebuje programátor, ktorý po celom dni práce nad kusom kódu musí tento kód zahodiť a začať znovu. Nie je jednoduché zahodiť niečo, na čom ste tvrdo pracovali, niekedy je to ale nutné. Niekedy je tiež nutné mať guráž na pustení sa do opravy zložitého kódu, ktorá zaberie pokojne celý deň.
• Rešpekt k práci ostatných, ale aj rešpekt k práci vlastnej je ďalší veľmi cenená hodnota. Musí sa rešpektovať už odvedená práca a nesmie sa robiť zmeny, ktoré by ohrozili integritu programu a ktoré by viedli k zlyhaniu jednotkových testov. Dodržiavanie vyššie zmienených hodnôt tiež vedie k získaniu rešpektu od ostatných členov tímu. Nikto z tímu by sa nemal cítiť menejcenný alebo ignorovaný. To napomáha lepšej motivácii a lepším pracovným výkonom.

Proces vývoja

V každej časti vývoja pomocou Extreme Programming existujú pravidlá ako sú napríklad:

• Súťažné časť Spísanie tzv. "User Stories", teda zistenie rôznych scenárov toho, ako má program fungovať.

  Zákazník môže požiadavky na systém kedykoľvek doplniť alebo pozmeniť. V takom prípade musí už rozbehnutý cyklus začať od začiatku.

• Spísanie tzv. "User Stories", teda zistenie rôznych scenárov toho, ako má program fungovať.
• Zákazník môže požiadavky na systém kedykoľvek doplniť alebo pozmeniť. V takom prípade musí už rozbehnutý cyklus začať od začiatku.
• Plánovacie časť Naplánovanie vydanie hotového produktu. Vďaka toho sa dá lepšie utvoriť pevný časový harmonogram.

  Rozdelenie projektu do iterácií, vďaka čoho sa môžu v každej iterácii častejšie vydávať malé zmeny.

  Konanie rýchlych schôdzí podobne ako u metodiky SCRUM.

• Naplánovanie vydanie hotového produktu. Vďaka toho sa dá lepšie utvoriť pevný časový harmonogram.
• Rozdelenie projektu do iterácií, vďaka čoho sa môžu v každej iterácii častejšie vydávať malé zmeny.
• Konanie rýchlych schôdzí podobne ako u metodiky SCRUM.
• Dizajnová časť Čím jednoduchšie, tým lepšie.

  Nepridávať funkcionality, kým nám zákazník nepovie.

  Častý refaktoring, pokiaľ možno kedykoľvek a kdekoľvek.

• Čím jednoduchšie, tým lepšie.
• Nepridávať funkcionality, kým nám zákazník nepovie.
• Častý refaktoring, pokiaľ možno kedykoľvek a kdekoľvek.
• programovacie časť Najskôr sa píšu jednotkové testy, potom program.

  Všetok kód sa programuje vo dvojiciach. Dva programátori pri jednej stanice.

  Integráciu novovytvorených častí kódu do programového celku vykonáva iba jeden pár programátorov. Integrácia prebieha často.

  Optimalizácia sa vykonáva ako posledný krok.

  Žiadne nadčasy (to by sa určite páčilo každému:) ).

• Najskôr sa píšu jednotkové testy, potom program.
• Všetok kód sa programuje vo dvojiciach. Dva programátori pri jednej stanice.
• Integráciu novovytvorených častí kódu do programového celku vykonáva iba jeden pár programátorov. Integrácia prebieha často.
• Optimalizácia sa vykonáva ako posledný krok.
• Žiadne nadčasy (to by sa určite páčilo každému:) ).
• testovacie časť Všetok napísaný kód musí mať svoje jednotkové testy. Všetky testy musia byť splnené, než je finálna softvér vydaný.

  Ak sa v programe ocitne chyba, je na nej napísaný nový jednotkový test.

  Len jednotkové testy nestačí, treba aj cielené testovanie funkčnosti.

• Všetok napísaný kód musí mať svoje jednotkové testy. Všetky testy musia byť splnené, než je finálna softvér vydaný.
• Ak sa v programe ocitne chyba, je na nej napísaný nový jednotkový test.
• Len jednotkové testy nestačí, treba aj cielené testovanie funkčnosti.

Ukážka procesu vývoja:

Záver

Vďaka tomu, že Extreme Programming vedie už k tradičnej činnosti do extrému, dokáže sa vývoj softvéru vedený touto metodikou lepšie prispôsobiť meniacim sa požiadavkám zo strany zákazníka a je tak dodávaný softvér vyššej kvality.

V ďalšej lekcii, Metodiky ASD, FDD a Crystal methodologies , preberieme metodiky Adaptive Software Development, Feature-Driven Development a Crystal methodologies.