Extrémne Programovanie (XP)

Extrémne programovanie je množina praktík, ktoré, aplikované vývojovým tímom, pomáhajú znižovať technologický dlh a skvalitniť kód samotný. Výrazne urýchľujú spätnú väzbu.

Extrémne programovanie bolo prvým celkom, ktorý odporúčal jednoduché a ľahko aplikovateľné praktiky v bežnom živote, ktoré podporia rýchlejší vývoj produktov. Neskoršie metodiky a rámce stavajú, alebo priamo sa kombinujú s XP praktikami, a preto je potrebné ich spoznať na začiatku.

XP praktiky sa zavádzajú prakticky okamžite so Scrum, resp. Kanban. Iba ich súčasná aplikácia prinesie rýchlu zmenu fungovania tímu.

Hodnoty

Komunikácia, Jednoduchosť, Spätná väzba, Odvaha, Rešpekt

Princípy

Spätná väzba často a promptne. Očakávanie jednoduchosti. Podpora zmeny.

Praktiky

Kvalita výsledku predurčuje problémy agilného tímu. Ak je kvalita nízka, neustále opravy narušujú rýchlosť dodávok a predikovateľnosť dodávky, keďže tím sa musí neustále vracať k opravám.

Agilné tímy preto namiesto platenia nákladov na opravy radšej investujú prostriedky do lepšej kvality. Náklady opravy sú nižšie pred dodávkou ako po nej, keď navyše vývojári si ani nepamätajú kód čím sa stráca ďalší čas.

Extreme programming sa tak snaží venovať kvalite viacerými praktikami, ktorých aplikácia až tak nebolí a zároveň problémy sú odchytené ešte skôr, než ich zbadá zákazník.

Review kódu

Revízia kódu prebieha typicky po ukončení programátorských prác. Iný vývojár skontroluje kód a spripomienkuje ho. Niekedy sa za týmto účelom používajú nástroje, efektívnejšie je možni spraviť takýto review osobne s autorom.

Počas review je potrebné si všímať aké typy chýb pri písaní kódu boli rozpoznané a pripraviť odporúčania napr. pre štandardy písania kódu. Tie tak vzniknú prirodzene a nie nariadením, ktoré v praxi ľudia nebudú aplikovať, pretože nevychádza z reálneho života.

Review kódu je súčasťou dobrej Definície Hotovo reprezentované samostatnou kartičkou na Kanban tabuli. Na review agilné tímy aj plánuju čas. Tím má tak priestor na zlepšovanie kvality a zároveň sa na chýbajúci review nedá vyhovoriť.

Review typicky trvá do ½ hodiny. Pracovali sme s tímami, ktoré si na review kódu vyhradili čas 15 minút pre bežné požiadavky, no security požiadavky boli dokonca aj hodinové.

Párové programovanie

Review kódu dáva spätnú väzbu na úrovni hodín, resp. na konci dňa. Intenzívnejším prístupom je párové programovanie.

Pri párovom programovaní si sadnú dvaja ľudia za jednu klávesnicu a jeden monitor. Jeden z nich píše kód, kým ten druhý je navigátor. Možno to znie ako neefektívny spôsob práce, má však nasledujúce výhody, ktoré sú z dlhodobého hľadiska dôležitejšie než náklady na takúto formu spolupráce:

• Rýchlejšia identifikácia chýb.
• Rýchlejšia tvorba kódu keďže jedna osoba má priestor sústrediť sa na problém, zatiaľčo druhá píše.
• Prirodzené zdieľanie vedomostí o programovaní, organizácii kódu aj o biznis doméne.
• Postupné vytváranie štandardov kódu, čo vedie k lepšej čitateľnosti kódu a nakoniec aj rýchlejšiemu programovaniu.
• „Emerging design“, postupný vývoj technického dizajnu aplikácie.
• Ak máte problém s komunikáciou v tíme, párové programovanie prirodzene prinúti ľudí spoznať myslenie, schopnosti a prístup k práci toho druhého.

Párové programovanie je náročné vzhľadom na veľkú interakciu. Preto je dobré mať pre párové programovanie vyhradený počítač a miesto. Tímy programujú párovo 1-2 hodiny denne. Neskôr tímy programujú v pároch predovšetkým kritické časti kódu, kde je potrebná okamžití kontrola kvality.

Párovo programovať nemusia iba dvaja programátori. K lepšej kvalite a vytvorenia výsledku bližšieho používateľovi vedie párové programovanie vývojára s testerom, alebo dokonca klientom.

Štandardy písania kódu

Štandardy písania kódu podporujú univerzálnosť vývojárov a zároveň aj testovateľnosť kódu. Tým, že kód sa píše rovnako, urýchľuje sa pochopenie kódu, pretože programátor nemá „orezané ruky“. Jednoducho sa rýchlejšie bude venovať problému samotnému, nie tomu čo je ako napísané.

Pravidlá kódu je dobré vybudovať párovým programovaním a revíziou kódu. Zároveň podľa týchto pravidiel sa dajú nastaviť aj nástroje statickej kontroly kódu (napr. FxCop, JSLint), ktoré pomôžu aspoň z časti automatizovať aj takúto činnosť.

Smrad v kóde

• Duplikovaný kód
• Dlhá metóda
• Veľká trieda
• Dlhý zoznam parametrov

Pravidlo troch

1. Keď vidíte niečo prvýkrát, tak to jednoducho spravte.
2. Keď vidíte niečo druhýkrát, narazili ste na duplikát, ale kľudne kód zduplikujte.
3. Keď narazíte na to isté tretíkrát, zrefaktorujte kód.

Kód meňte v malých dávkach. Nikdy si nevyhraďte na refaktoring dlhé časové obdobie. Nie vždy však refaktoring má zmysel. Sú situácie, kedy je lepšie začať odznova. Týka sa to aj kódu, ktorý je tesne pred míľnikom. V takomto prípade bude zisk zo zvýšenia produktivity veľmi neskorý.

Refaktoring začína uistením sa, že mám automatizované testy, ktoré mi pomôžu overiť zmenený kód. Človek je tvor omylný.

Metódy refaktoringu

Dôraz na jednoduchosť, pripravenosť na rýchlu zmenu a na kvalitu viedol k refaktoringu, technike neustáleho zlepšovania kódu. Ako na refaktoring? Aké možnosti majú vývojári pri zjednodušení kódu?

Tu je niekoľko základných techník refaktoringu: