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

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

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

Velká koule bahna (The Blob)

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)

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)

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)

Č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

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

Příklady

Švýcarský nožík (Swiss Army knife)

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)

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)

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

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

Příklady

Paralýza analýzou

Na tuto kapitolu je přesměrováno heslo Paralýza analýzou.

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.

Související informace naleznete také v článcích agilní řízení projektu a vodopádový model.

Inženýrství grafů (Viewgraph engineering)

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)

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.

Odkazy

Reference

  1. ↑ John Long, Software Reuse Antipatterns, 2001

Literatura

  • LONG, John. Software Reuse Antipatterns. ACM SIGSOFT Software Engineering Notes, 2001

Související články

Externí odkazy