Scream

Pokud Vás název tohoto příspěvku pořádně nabudil, splnil účel. Ne, nebojte se, nechci v něm vést polemiku proti agilním technikám při vývoji software. Cílem je poukázat na velmi časté nepochopení agilního vývoje, kdy se ve skutečnosti praktikuje tzv. „Cowboy coding„. Tento jev se, dle mého názoru, projevuje ve zvýšené míře hlavně u méně zkušených, zato ale velmi kreativních developerů, kteří si takříkajíc z agilního přístupu vybírají jen to, co se jim hodí. Druhou skupinou, která je neméně častá, jsou zkušení programátoři, ovšem od přírody „bastlíři“. Každý z nich má spoustu, někdy velmi humorných výmluv a zde je pár příkladů z praxe:

Záminka č.1: Praktikujeme tady agilní development a ty jistě víš, že to znamená, že děláme jen to, co je nutné, nic navíc:

• neukládání zdrojových kódu do CVS, SVN nebo jiného systému pro správu verzí (“na tom dělám jen já, takže je to zbytečné a než to nastavím, tak už to budu mít“) - až odejde disk nebo Frantu srazí tramvaj, tak můžeme odpískat rok práce,
• nepoužíváme patterny, protože jsou zbytečně obecné, je to prostě spousta kódu navíc, který nikdo nepotřebuje – ve výsledku vede k obtížnému rozšiřování aplikace a prodražení maintainance celkově,
• tohle dělat nebudeme, protože to zákazník nechce – ano, zákazník to teď nechce, protože „profesionální“ konzultant to neporadil a zákazník to z logiky dané aplikace bude chtít za měsíc, ale to už náš vývoj bude znamenat přinejmenším refaktoring a prodražení.

Záminka č.2: Snažíme se být agilní, takže analýzu a design nemáme, máme jen testy:

• analýzu nemáme, zákazník nebo „lidi z businessu“ ti stejně neřeknou, co vlastně potřebují -agilní vývoj software bez analýzy má možná své místo ve výzkumu, ale jinak je to čisté mrhání penězi. To, že zákazník nebo „lidé z businessu“ nevědí je běžné a normální, od toho jsou právě profesionální konzultanti, aby poradili s tím, co jde, co ne a co by měli od aplikace chtít. V ideálním případě to vede na reingeneering procesů,
• architekturu a design aplikace nemáme, ale máme jen samé „hodně seniorní“ developery a ti to udělají dobře -zajímavá představa, o které mohu s klidem v duši prohlásit, že prostě nefunguje. Agilní neznamená, že se nezabýváme architekturou a designem. Naopak, klade důraz na jejich kontinuální zlepšování a s tím související refaktoring kódu. Nepochopení často spočívá i v tom, že každý pracuje jen na zvýšení kvality vlastního kódu, ale vázne komunikace mezi jednotlivými developery nebo celými týmy,
• unit testy – ve skutečnosti je pokrytí unit testy často velmi malé, pokrytý je kód, který to potřebuje nejmíň, ale bylo nejsnadnější napsat testy, jsou porušovány zásady pro psaní unit testů (např. test se připojuje k DB, což ve většině případů vede k nemožnosti automatizace jejich spouštění během kontinuálních buildů) a opravdu jen málokdo je píše jako první, před napsáním vlastního kódu,
• E2E testy místo analýzy – obecně jsou automatizované E2E testy naprosto skvělé, ale je k nim potřeba mít analýzu. Z vlastní zkušenosti mohu říct, že opravovat po nejakém čase kód, jehož správnost je ověřována jen „green“ E2E testem, je velmi obtížná. Jakmile je tento test červený, tak ve výsledku nikdo neví, jestli je špatně kód nebo test, funkcionalita je popsána jen testem, ale vlastní test není otestován – ani nemůže být, bez analýzy není vůči čemu.

Takže buďme agilní, ale nezvdávejme se ani toho dobrého z konvenčních metodik typu RUP.