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é jsou všeobecně vnímány 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í.

DefiniceEditovat

Návrhové vzory jsou postupy, které řeší konkrétní problém a byly prokazatelně použity v minulosti (a je prokázáno, že daný problém úspěšně řeší). Řešení není zřejmé na první pohled. Návrhový antivzor je podobný návrhovému vzoru, s tím rozdílem, ž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 výsledku však přinášejí spíše negativní, než pozitivní výsledky.[1]. Většinou 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 softwareEditovat

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

PříkladyEditovat

Velká koule bahna (The Blob)Editovat

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

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 vzoru, je pečlivé plánování a vytvoření dobré softwarové architektury před vývojem.

Kotva (Boat anchor)Editovat

Kotva je jednou částí softwaru (nebo hardwaru), která nemá žádný účel v daném projektu. 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 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

Č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 ne zcela hodí. Většinou není vynakládáno téměř žádné úsilí k nalezení alternativních řešení.

Antivzory v softwarové architektuřeEditovat

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

PříkladyEditovat

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

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. Je přidáváno velké množství rozhraní aby bylo vyhověno všem možným požadavkům. Taková třída je příliš komplexní 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

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

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 managementuEditovat

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

PříkladyEditovat

Paralýza analýzou (Analysis paralysis)Editovat

Tento antivzor vzniká, 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é jsou nepří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

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

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 je o těchto obavách diskutováno 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.

ReferenceEditovat

  1. John Long, Software Reuse Antipatterns, 2001

LiteraturaEditovat

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

Externí odkazyEditovat