Návrhový antivzor

Návrhový antivzor (angl. anti-pattern) v softwarovém inženýrství představuje obecný postup při řešení opakujících se problémů při návrhu počítačových programů, který je všeobecně vnímán jako nesprávný nebo neefektivní. Tento pojem byl poprvé použit v roce 1995 a byl inspirován knihou Návrhové vzory. Návrhové anti-vzory jsou opakem návrhových vzorů. Návrhové antivzory mohou být přesně popsány ve formě dokumentu, který obsahuje název (alternativní názvy), problém, který se daný antivzor snaží řešit, nejčastější výsledky jeho používání a možné řešení.

Definice[editovat | editovat zdroj]

Návrhové vzory jsou postupy, které úspěšně řeší konkrétní problém softwarového inženýrství. Řešení přitom často není zřejmé na první pohled. Návrhový antivzor se liší tím, že se většinou jedná o zřejmé, ale nesprávné řešení. Tyto postupy jsou používány znovu a znovu, protože se na první pohled zdají být správnými, ve skutečnosti však přinášejí spíše negativní než pozitivní výsledky.^[1] Většinou k nim existuje alternativní řešení, které je prokazatelně efektivnější. Antivzory jsou často důsledkem nedostatku zkušeností a znalostí v dané oblasti nebo využití návrhového vzoru v nesprávném kontextu.

Antivzory při vývoji software[editovat | editovat zdroj]

Tyto antivzory nejenom poukazují na chyby při vývoji softwaru, ale většinou také obsahují postupy pro správné refaktorování.

Příklady[editovat | editovat zdroj]

Velká koule bahna (The Blob)[editovat | editovat zdroj]

Projekt je tvořen jednou hlavní třídou, která má na starosti veškeré procesy, a několika menšími třídami, které většinou obsahují jenom data a jen málo nebo žádné metody. Hlavní třída (někdy nazývaná Božská třída – the God Class) je všemocná a nenahraditelná.

Tento antivzor je v podstatě procedurálním modelem, kde dochází k oddělení dat od procesů. Může vzniknou kvůli nesprávné architektuře (nebo její absenci).

Proud lávy (Lava flow)[editovat | editovat zdroj]

Projekt obsahuje staré části kódu, u kterých není jasné, kdo je vytvořil (nebo byly vytvořeny někým, kdo se na projektu již nepodílí) a k čemu slouží (nebo zdali vůbec k něčemu slouží), přesto nejsou odstraňovány ze strachu, že dojde k porušení funkčnosti celého programu. Pokud nejsou tyto části odstraněny, může dojít k dalšímu zhoršování situace a vytváření nových „proudů“ při snaze obejít tyto části.

Nejlepší způsob, jak předcházet tomuto antivzoru, je pečlivé plánování a vytvoření dobré softwarové architektury před vývojem.

Kotva (Boat anchor)[editovat | editovat zdroj]

Kotva je částí softwaru (nebo hardwaru), která nemá v daném projektu žádný účel. Tato součást je často drahou akvizicí, pro kterou byly v minulosti pádné důvody. K tomuto často dochází kvůli tomu, že rozhodnutí o pořízení této součásti vyšlo od vyššího managementu bez předchozí porady s vývojáři, kteří ji měli používat. Na její zahrnutí do produkce je často vynaloženo mnoho času a úsilí, než se nakonec dospěje k názoru, že je to součást zbytečná, a přejde se k jinému, vhodnějšímu řešení. „Kotva“ (ať už ve formě softwaru nebo hardwaru) pak zůstává nevyužita.

Zlaté kladivo (Golden hammer)[editovat | editovat zdroj]

Často jde o technologii nebo postup, který vývojář (nebo tým vývojářů) nejvíce preferuje, nebo se kterým má nejvíce zkušeností. V důsledku toho je tento postup nebo technologie používána pro řešení všech úkolů, i když se k tomu nehodí. Většinou není vynakládáno téměř žádné úsilí k nalezení alternativních řešení.

Antivzory v softwarové architektuře[editovat | editovat zdroj]

Tyto antivzory se zaměřují na strukturu aplikací a komponent na systémové a podnikové úrovni.

Příklady[editovat | editovat zdroj]

Švýcarský nožík (Swiss Army knife)[editovat | editovat zdroj]

Tento antivzor popisuje přespříliš komplexní třídy, při jejichž tvorbě je snaha zvážit všechna možná využití této třídy. Přidává se velké množství rozhraní, aby se vyhovělo všem možným požadavkům. Taková třída je příliš komplexní, než aby jí mohli porozumět jiní vývojáři, a není jasné, jak by se tato třída měla doopravdy používat. Takové třídy je obtížné udržovat, dokumentovat a opravovat v nich chyby.

Závislost na dodavateli (Vendor lock-in)[editovat | editovat zdroj]

Projekt využívá technologie nebo produkty od dodavatele a je kompletně závislý na jeho implementaci. Když dojde k aktualizaci, nastávají problémy s kompatibilitou a je nutná nepřetržitá údržba. Dodání úprav a nových funkcí se často opožďuje, což způsobuje prodlevy nebo neschopnost dodat požadovanou funkcionalitu projektu.

Vynalézání kola (Reinvent the wheel)[editovat | editovat zdroj]

Systém je vytvářen „od nuly“, i když existuje několik systémů s podobnou funkcionalitou. Nedochází k využívání již existujícího softwaru. Takové systémy často mají nevyspělou architekturu a nemají potenciál k opětovnému využití a dalšímu rozvoji.

Antivzory v projektovém managementu[editovat | editovat zdroj]

Tyto antivzory poukazují na nesprávné postupy při řízení projektů.

Příklady[editovat | editovat zdroj]

Paralýza analýzou[editovat | editovat zdroj]

Antivzor paralýza analýzou (analysis paralysis, paralysis by analysis) nastává, když je v projektu snaha o dokonalost během analytické fáze. Je charakterizován vytvářením a revidováním podrobných modelů, které nejsou příliš užitečné v dalších procesech. Je snaha provést co nejpodrobnější analýzu před začátkem vývoje. Analytická fáze přestává zahrnovat komunikaci se zákazníkem (uživatelem) a staví se čím dál tím více na spekulacích.

Paralýza analýzou je často způsobena tím, že má management větší jistotu během analytické fáze než během fáze vývoje nebo požaduje, aby veškerá analýza byla dokončena před samotným vývojem.

Inženýrství grafů (Viewgraph engineering)[editovat | editovat zdroj]

V některých projektech vývojáři neustále vytvářejí grafy a připravují dokumenty, místo toho, aby vyvíjeli software. Protože často nemají správné nástroje pro vývoj, musejí využívat běžné nástroje pro kancelářskou automatizaci. Výsledkem jsou pseudo-technické dokumenty a diagramy. Tato situace je pro ně často frustrující, protože nejsou využity jejich schopnosti.

Strach z úspěchu (Fear of success)[editovat | editovat zdroj]

Tento jev se často projevuje těsně před úspěšným dokončením projektu. Někteří lidé začínají být posedlí tím, co se může pokazit. Pokud se o těchto obavách diskutuje otevřeně, může dojít k přijetí iracionálních rozhodnutí. Mohou například vytvořit negativní publicitu mimo tým vývojářů, a tím mít destruktivní účinky na výsledek celého projektu.