Antipattern
Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od
verze recenzované 29. května 2022; ověření vyžaduje
1 úpravu .
Anti-vzor je běžný přístup k řešení třídy běžných problémů, který je neefektivní, riskantní nebo neproduktivní [1] . Na rozdíl od návrhového vzoru zahrnuje zvážení antivzoru jak nesprávné řešení problému s jeho znaky a důsledky, tak východisko ze situace [2] .
Termín pochází z informatiky , z knihy Gang of Four „ Design Patterns “, která obsahuje příklady dobrých programovacích postupů. Autoři nazvali tyto dobré postupy „vzory“ a jejich opakem jsou „anti-vzorce“. Součástí správné programátorské praxe je vyhýbat se antivzorkům. Než se tento termín objevil, všechny problémy se nazývaly pasti ( úskalí ) . Antipatterny jsou tedy nejběžnější pasti, ale ne všechny pasti budou antivzory.
Antipatterny jsou koncepčně podobné vzorům v tom, že dokumentují opakující se řešení běžných problémů. Jsou známé jako anti-vzorce, protože jejich použití (nebo zneužití) má negativní důsledky [3] .
Historie
S rozvojem IT průmyslu rychle rostl rozsah softwarových projektů a náklady na jejich zdroje, což dalo vzniknout velkému množství problémů, se kterými se programátoři potýkali. Většina těchto problémů byla typická a vyskytovala se téměř u každého velkého projektu. Počátkem 90. let získaly značnou oblibu katalogy designových vzorů , "patterns" ( angl. design patterns ) - elegantní a osvědčené způsoby řešení typických problémů. Vzory jsou dnes stále silné a extrémně populární, nicméně mnoho vývojářů používajících oblíbené vzory v situacích, pro které nebyly určeny, vytvořilo více problémů, než jich vyřešilo. Kromě toho mohou IT inženýři, stejně jako pracovníci v jakékoli jiné oblasti činnosti, identifikovat typické chyby způsobené nedostatečnou znalostní základnou nebo nedostatkem zkušeností, spěchem a tlakem kvůli termínům projektů, finančním omezením a dalším.
Poprvé byl termín "anti-vzor" ve smyslu zobecněného popisu typického neúspěšného řešení použit v roce 1996 Michaelem Akroydem na Object World West Conference, věnované aspektům objektově orientovaného programování . [4] Aykroyd ve své prezentaci Anti-Patterns: Preventing Object Misuse upozornil na škodlivé, ale běžné programátorské konstrukty, zejména ty, které jsou v rozporu s principy OOP. Ke každému takovému provedení navíc nabízel účinnou náhradu.
Termín ve smyslu „špatný nápad“ se vyskytoval před Aykroydem, ale nebyl publikován a nebyl nijak zvlášť populární. A přesto se nevyplatí připisovat autorství jedné osobě. Podle Williama Browna, autora Antipatterns: Refactoring Applications, Architectures, and Projects, je antipattern fází ve vývoji konceptu návrhového vzoru, rozšířením jejich modelu.
Klasifikace
William Brown rozlišuje anti-vzory ze tří hledisek: vývojář , architekt a manažer :
- Vývojové antivzorce ]
- Architektonické antivzory [ ]
- Organizační antivzory ( manažerské antivzory )
Neil a Laplante dávají čtvrtý typ [5] [6] :
- Environmentální antivzory ]
Navíc byly popsány anti-vzory pro jednotlivé informační technologie , jako jsou [6] :
Vývojové antivzory
Technické problémy a řešení, kterými se programátoři zabývají [6] :
Anti-vzory v objektově orientovaném programování
- Základní obslužná třída (BaseBean [12] ): Zdědit funkce z obslužné třídy namísto delegování na ni.
- Anemic Domain Model [12] - strach z umístění logiky do doménových objektů.
- Volání předka (Call super): Pro implementaci funkčnosti aplikace musí metoda třídy potomka nutně volat stejné metody třídy předka.
- Selhání prázdné podtřídy : Vytvoření třídy (v Perlu ), která neprojde "Testem prázdné podtřídy" kvůli odlišnému chování ve srovnání s třídou, která z ní dědí beze změny.
- Boží objekt: Koncentrace příliš mnoha funkcí v jedné části systému (třídě).
- Objektová žumpa: Znovu použijte objekty, které jsou v nepoužitelném stavu.
- Poltergeist 13] :Objekty, jejichž jediným účelem je předávat informace jiným objektům.
- Yo- yo problem (Yo-yo problem): Nadměrné rozostření těsně spojeného kódu (například spuštěného v pořadí) podél hierarchie tříd.
- Osamělost (Singletonitida): Nevhodné použití ojedinělého vzoru .
- Friend zone: Nevhodné použití tříd přátel a funkcí přátel v C++.
- Interface soup [14] : Kombinace několika rozhraní oddělených podle principu izolace rozhraní (Interface segregation) do jednoho.
- Dangling ends : Rozhraní, jehož většina metod postrádá smysl a jsou implementovány pomocí „figuríny“.
- Útržek: Pokus o "vytažení" již existujícího rozhraní, které má malý význam pro objekt, namísto vytvoření nového.
Antivzory při psaní kódu
- Náhodná složitost : Přidání zbytečné složitosti řešení.
- Akce na dálku Neočekávaná interakce mezi široce oddělenými částmi systému.
- Accumulate and fire: Nastavte parametry podprogramu v sadě globálních proměnných.
- Slepá víra : Nedostatečné ověření správnosti opravy chyby nebo výsledku podprogramu.
- Boat anchor (Boat anchor) [13] : Uložení části systému, která se již nepoužívá.
- Busy spin, busy waiting : Spotřeba zdrojů CPU procesorového času) při čekání na událost, obvykle neustálým opakováním kontroly, namísto použití asynchronního programování (např. systém zpráv nebo událostí).
- Selhání mezipaměti : Zapomenutí resetovat příznak chyby po jejím zpracování.
- Vzor plenky smrdí: Resetujte příznak chyby, aniž byste jej zpracovávali nebo jej předali obslužnému programu proti proudu.
- Kontrola typu místo členství, Kontrola typu místo rozhraní: Kontrola, zda je objekt specifického typu v době, kdy je vyžadováno pouze specifické rozhraní.
- Dynamika kódu: Omezování části systému neustálým implikováním jejího chování v jiných částech systému .
- Kódování podle výjimky : Přidání nového kódu na podporu každého rozpoznaného speciálního případu.
- Kryptický kód : Použití zkratek místo mnemotechnických jmen.
- Pevné kódování : Vkládání předpokladů o prostředí systému do příliš mnoha implementačních bodů.
- Měkké kódování : Patologický strach z tvrdého kódování, který vede k tomu, že vše je nakonfigurováno, zatímco konfigurace samotného systému se mění v programování.
- Lava flow 13] : Uchovávání nechtěného (nadbytečného nebo nekvalitního) kódu, protože jeho odstranění je příliš nákladné nebo bude mít nepředvídatelné následky.
- Magická čísla: Použití číselných konstant bez vysvětlení jejich významu.
- Procedurální kód : Když je vhodnější jiné paradigma .
- Kód špaget (někdy „těstoviny“) [13] : Kód s příliš matoucím pořadím provedení.
- Lasagnia code (Lasagnia code, nebo "cibule" (cibule)): Nadměrná vazba mezi vrstvami abstrakce, vedoucí k neschopnosti změnit jednu úroveň, aniž by se změnily ostatní.
- Ravioli kód (neboli "knedlíky"): Předměty jsou tak "slepené" dohromady, že prakticky neumožňují refaktorování.
- Mýdlová bublina : Objekt inicializovaný odpadky předstírá, že obsahuje nějaká data tak dlouho, jak je to možné.
- Mutex hell: Vkládání příliš mnoha synchronizačních objektů mezi vlákna.
- Rakovina (Meta-)Template: Široké používání šablon (většinou C++), včetně případů, kdy jejich použití není odůvodněné. To snižuje porozumění a údržbu kódu a zpomaluje kompilaci.
Metodologické antivzory
- Kopírovat a vložit programování [13] : Kopírování (a lehké úpravy) existujícího kódu namísto vytváření obecných řešení.
- Defaktoring : Proces zničení funkčnosti a její nahrazení dokumentací.
- Zlaté kladivo [13] : Pevné přesvědčení, že oblíbené řešení je univerzálně použitelné. Název pochází z úsloví „když držíte kladivo, všechny problémy vypadají jako hřebíky“.
- Faktor nepravděpodobnosti : Předpoklad, že je nemožné, aby se spustila známá chyba.
- Předčasná optimalizace : Optimalizace ve fázi návrhu segmentu kódu, která jej činí složitějším nebo poškozeným.
- Programování permutací: Přístup k vývoji softwaru s malými změnami.
- Znovuobjevení kola [ 13] : Stavíme od nuly namísto použití dobrého standardního řešení.
- Znovuobjevení čtvercového kola : Vytvoření špatného řešení vzhledem k tomu, že známější řešení již existuje.
- Sebedestrukce : Fatální chyba nebo nestandardní chování programu vedoucí k odmítnutí služby v důsledku jiné méně závažné chyby. Například když dojde k chybě, aplikace začne zapisovat do logu velmi rychle a hodně zapisuje do logu, v důsledku čehož dochází místo na pevném disku rychleji, než monitoring detekuje.
- Dva tunely : Přenesení nových funkcí do samostatné aplikace namísto rozšiřování stávající. Nejčastěji se používá, když je z nějakého důvodu (především z důvodu nedostatku času nebo neochoty vedení) provádění změn ve stávajícím kódu dražší než vytváření nového. V tomto případě klient skončí se dvěma aplikacemi spuštěnými současně nebo střídavě jedna od druhé.
- Commit assassin : Provádění jednotlivých změn v systému správy verzí bez kontroly jejich dopadu na ostatní části programu. Zpravidla je po takových commitech paralyzována práce týmu při odstraňování problémů na místech, která dříve fungovala bez chyb.
Anti-vzory správy konfigurace
- Závislostní peklo ( na platformě Microsoft Windows také nazývané " DLL peklo " nebo " DLL peklo " ): Růst grafu vzájemných závislostí softwarových produktů a knihoven, což vede k obtížnosti instalace nových a odstranění starých. Ve složitých případech vyžadují různé nainstalované softwarové produkty různé verze stejné knihovny. V nejsložitějších případech může jeden produkt nepřímo vyžadovat dvě verze stejné knihovny najednou.
Různé
- Kouř a zrcadla [13] : Ukázka, jak by vypadaly nepsané funkce (název pochází ze dvou oblíbených způsobů, jak kouzelníci skrývají svá tajemství).
- Softwarová nadýmání: Umožňuje postupným verzím systému vyžadovat stále více zdrojů.
- Funkce zaškrtávacího políčka : Přeměna programu na konglomerát špatně implementovaných a nesouvisejících funkcí (obvykle za účelem reklamy , že funkce existuje).
Architektonické anti-vzory
Typické problémy spojené se strukturou systému [6] :
- Inverze abstrakce : Skrytí části funkce před externím použitím v naději, že ji nikdo nepoužije.
- Nejednoznačný úhel pohledu [ 13] : Reprezentace modelu bez určení jeho úhlu pohledu.
- Velká koule bahna: Systém s nerozpoznatelnou strukturou.
- Blob (Blob [13] ): viz Bůh objekt.
- Plynárna : Volitelná složitost návrhu.
- Input kludge [13] : Zapomenutí specifikace a implementace podpory pro možný neplatný vstup.
- Rozhraní bloat : Vývoj rozhraní je velmi výkonný a velmi obtížně implementovatelný.
- Magické tlačítko : Provádění výsledků uživatelských akcí v nevhodném (ne dostatečně abstraktním) rozhraní. Například v systémech, jako je Delphi , se jedná o zápis aplikační logiky do obslužných programů pro kliknutí na tlačítka.
- Re -Coupling: Proces zavedení zbytečné závislosti .
- Komín (Stopepipe System [13] ): Zřídka podporovaná sestava špatně spojených součástí.
- Race hazard (Race condition): Nepředvídatelnost možnosti událostí, které nastanou v jiném než očekávaném pořadí .
- Krysí závod : Neodůvodněné vytváření mnoha malých a abstraktních tříd pro řešení jednoho konkrétního úkolu vyšší úrovně.
- Zmrzačení : Zbytečné "ostření" předmětu pro určitý velmi úzký úkol takovým způsobem, že nebude schopen pracovat s žádnými jinými, byť velmi podobnými úkoly.
- Save or die: Uložení změn konfigurace na pevný disk pouze po ukončení aplikace; vede k tomu, že v případě selhání programu dojde ke ztrátě těchto dat
Organizační anti-vzory
Problémy, kterým čelí manažeři (nebo skupiny manažerů) [6] :
- Analytická paralýza [13] : nepřiměřeně vysoké náklady na analýzu a návrh. Často vede k uzavření projektu ještě před zahájením jeho realizace.
- Cash cow : pokud existuje produkt, který přináší výhody bez výrazných investic, neinvestují se žádné prostředky do vývoje a vývoje nových produktů.
- Neustálé zastarávání 13] : věnování neúměrného úsilí portování systému do nových prostředí.
- Migrace nákladů : Přenesení nákladů projektu na slabé oddělení nebo obchodního partnera.
- Plíživý featurismus: Přidávání nových funkcí na úkor celkové kvality systému.
- Nabušená elegance (Plížející elegance): neúměrné vylepšení krásy kódu na úkor funkčnosti a celkové kvality systému.
- Design by Committee [13] : vývoj projektu bez centralizované kontroly nebo bez kompetentního vedení.
- Eskalace závazku: v implementaci rozhodnutí poté, co se ukázalo, že je špatné.
- Řekl jsem vám to: ignorování znaleckého posudku.
- Správa podle čísel: Přílišný důraz na čísla, která velmi nepřímo souvisí s řízeným systémem, je obtížné je získat nebo podléhají Goodhartově efektu .
- Drakonická opatření (Management by perkele): nepřiměřeně rigidní styl řízení.
- Houbaření [ [13] : nedostatečné informování pracovníků o vykonávané práci.
- Scope : Ztráta kontroly nad růstem projektu.
- Vendor lock-in [13] : Vendor lock-in.
- Warm Bodies [13] : Osoba, jejíž přínos k projektu je na pochybách.
- Single head of knowledge (SHOK): když pouze jedna osoba v týmu má důležité informace nebo dovednosti pro projekt, a když odejde, práce se zastaví.
- Rytíř v lesklém brnění (KISA): když se na scéně objeví muž, který se snaží vše napravit, aniž by komukoli řekl, co udělal nebo proč.
Neil a LaPlante poskytují následující antivzory [5] :
- Nepřítomný manažer: Manažer je vyhýbavý nebo dlouhodobě neviditelný – skrývá se někde v kanceláři nebo mimo kancelář.
- Have only a hammer (All You Have Is A Hammer): jednosměrné ovládání, kdy se na všechny podřízené a ve všech situacích používají stejné techniky. Někdy se také nazývá "One-Trick Pony".
- Divoký manažer (Cage Match Negotiator): Každý manažer, který je svéhlavý nad rozum a používá k řízení přístup „vyhrát za každou cenu“ nebo „já mám pravdu a ty se mýlíš“. Často mají hrnek na kávu s Pravidly řízení: „Pravidlo č. 1: Šéf má vždy pravdu. Pravidlo 2: Pokud se šéf mýlí, viz pravidlo 1."
- Doppelganger : Manažer nebo kolega, se kterým je snadné nebo obtížné pracovat.
- Fruitless Hoops: Manažerům dáváte stále více údajů, které potřebují k rozhodnutí, ale manažeři se nikdy nerozhodnou a nadále po vás žádají data. Nevíte, proč tato data potřebují.
- Zlaté dítě: Zlaté dítě nastává, když manažer udělí zvláštní odpovědnost, příležitost, uznání nebo odměnu členovi svého týmu na základě osobního vztahu s ním a navzdory jeho skutečným činům. Zlaté dítě všechny štve, ale skutečný problém je v manažerovi.
- Bezhlavé kuře: Manažer bez zaměření a plánu, který nikdy nic nedokončí.
- Vedoucí , nikoli manažer: Zdůrazňuje důležitost efektivního vedení.
- Parrot Manager (Manažerské klonování): Střední manažeři, kteří se nakonec začnou chovat jako jejich šéfové.
- Manažer není vůdce: Tento manažer je dobrý v administrativních a manažerských povinnostech, ale postrádá vůdčí schopnosti.
- Zneužití metriky: Zneužití metrik v důsledku nekompetence nebo záměrné manipulace s daty .
- Milý chlap: Manažer, který se zaměřuje na to, aby byl přítelem všech, nakonec všechny zklame a nezvládne svou práci.
- Houbový management: Situace, kdy management nemůže efektivně komunikovat se zaměstnanci. V podstatě jsou informace záměrně zamlčovány, aby byli všichni „tlustí, hloupí a šťastní“. Název je spojen s přirovnáním: žampiony se pěstují ve tmě a v hnoji.
- Předení talířů : Manažer skrývá svou neefektivitu tím, že nutí dělníky do pracné a zbytečné práce.
- Hrdina proletariátu : Manažer jedná se svými podřízenými jako s ideálními pracovníky, ale to je jen jeho berlička, sloužící k maskování špatného managementu. Je to forma „motivace“ zaměstnanců, která dává vedení důvod zvýšit očekávané výsledky nebo získat více za méně.
- Rising Upstart : Superhvězdy, které nemohou ztrácet čas učením se a hledáním svého místa. Někdy to může být z neznalosti (nevědí, co nevědí) a někdy z netrpělivosti (vědí, co ostatní nevědí). Takový povýšenec představuje skutečnou výzvu pro všechny kromě těch nejzkušenějších manažerů.
- Cesta do nikam: Absence plánu způsobuje zmatek a krizi vedení.
- Bezpáteřní manažer: Každý manažer, který nemá odvahu čelit nutné konfrontaci nebo zvládnout obtížnou situaci. Místo toho se konfrontaci nebo situaci zcela vyhýbá, nebo vás požádá, abyste mu oznámili špatné zprávy.
- Tříhlavý rytíř : Nerozhodný manažer.
- Ultimátní zbraň: Manažer oznamuje, že každý se může spolehnout na vynikající zaměstnance, aby se tito zaměstnanci stali prostředníkem všeho.
- Warm Bodies: Manažerská situace, ve které pracovník, který stěží splňuje minimální požadavky, přechází od projektu k projektu nebo týmu k týmu. Slabému pracovníkovi se říká „teplé tělo“, ačkoli skutečný problém leží na manažerovi. Tento anti-vzor je opakem Starburstu, pokud jde o dovednosti a potenciál.
Antivzory prostředí
Problémy způsobené dominantní strukturou a sociálním modelem organizace, které jsou výsledkem veřejné politiky v organizaci [15] [6] [5] [16] :
- Mravenčí kolonie - pod vnější krásou se skrývá vysazování terčů[ upřesnit ] .
- Atlas Shrugs ( Atlas Shrug ) - po dočasném úspěchu začíná úpadek[ upřesnit ] .
- Autonomní kolektiv - sebeřízení vede k pasivitě[ upřesnit ] .
- Syndrom uvařené žáby ( Boiling Frog Syndrome ) – postupné negativní změny zaznamenáváme, když už je pozdě.
- Hořící pytel hnoje - manažer nechává sousedy (podřízené, svěřence, nástupce) v choulostivé situaci.
- Fascinace módními slovy ( Buzzword Mania ) – management žongluje se slovy, kterým málokterý ze svěřenců rozumí.
- Deflated Balloon - nejlepší roky firmy jsou za námi, ale nedokáže si to uvědomit a snížit náklady.
- Rozdílné cíle _ _[ vyčistit ]
- Dogmatický o dysfunkci _
- Neochvějná odvaha ( Dunkirk Spirit )[ vyčistit ]
- Nové šaty krále ( Císařovy nové šaty ) - na motivy stejnojmenné pohádky
- Doktrína spravedlnosti _ _[ vyčistit ]
- Pospěšte si – rozesmějte lidi ( Fools Rush In )[ vyčistit ]
- Founderova nemoc ( Funderitis )[ vyčistit ]
- Syndrom francouzského číšníka - nezdravá atmosféra v podniku (stereotypický americký názor na malé francouzské restaurace) .
- Hazing ( Geek Hazing ) – začátečníci jsou zatíženi spoustou triviálních úkolů, které jim nepomohou se učit.
- Institucionální nedůvěra _ _[ vyčistit ]
- Město stánků ( Kiosk City ) - každé oddělení vyvíjí svůj vlastní mechanismus výměny informací.
- Power of Gray ( Mediokracie )
- Jednooký král ( jednooký král )[ vyčistit ]
- Orange Stand Economics je špatný odhad nákladů.
- Pitcairn Island ( Pitcairn Island )[ vyčistit ]
- Potěmkinovy vesnice
- Konfliktní procesy ( Process Clash )[ vyčistit ]
- Rubikova kostka _ _[ vyčistit ]
- Děti bez bot ( děti bez bot )[ vyčistit ]
- Zlaté tele ( Uctívání zlatého telete )[ vyčistit ]
Viz také
Poznámky
- ↑ Budgen, D. Návrh softwaru. - Addison-Wesley, 2003. - ISBN 0-201-72219-4 .
- ↑ Brown, 1998 , kapitola 2.
- ↑ Smith CU, 2000 .
- ↑ http://c2.com/cgi/wiki?AntiPattern . Společnost Cunningham & Cunningham Inc. . Získáno 15. února 2006. Archivováno z originálu 3. dubna 2005. (neurčitý)
- ↑ 1 2 3 Neill, Laplante, 2005 .
- ↑ 1 2 3 4 5 6 Settas, 2011 .
- ↑ Miroslav Kis. Antipatterny informační bezpečnosti v inženýrství softwarových požadavků. In Proceedings of the 9th Conference on Pattern Language of Programs (Plop), 2002.
- ↑ John Long. Softwarové opětovné použití antivzorů. V ACM SIGSOFT Software Engineering Notes, svazek 26, strana 4, červenec 2001.
- ↑ Paula Kotze, Karen Renaud a Judy van Biljona. Nedělejte to – úskalí používání anti-vzorců při výuce principů interakce člověk-počítač. Computers and Education, 50(3):979-1008, duben 2008
- ↑ J. Krai a M. Zemlicka. Nejdůležitější antivzory orientované na služby. Ve sborníku z Mezinárodní konference o pokrokech softwarového inženýrství (ICSEA), 2007.
- ↑ P. A. Laplante, R. R. Hoffman a G. Klein. Antipatterny při tvorbě inteligentních systémů. IEEE Intelligent Systems, 22:91-95, 2007.
- ↑ 1 2 Rajiv Ramnath, Cheyney Loffing. Začínáme s programováním iOS pro figuríny . — John Wiley & Sons, 2014-04-14. - S. 105. - 470 s. — ISBN 9781118799277 . Archivováno 23. července 2016 na Wayback Machine
- ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 William J. Brown. AntiPatterns: Refaktoring softwaru, architektur a projektů v krizi . — Wiley, 1998-04-03. — 156 str. — ISBN 0-471-19713-0. Archivováno 22. prosince 2015 na Wayback Machine
- ↑ Gary McLean Hall. Adaptivní kód přes C#: Agilní kódování s návrhovými vzory a SOLID principy. - Microsoft Press, 2014. - S. 267-268. — ISBN 978-0735683204 .
- ↑ Originál: sociálně-politické síly
- ↑ Phillip Laplante Hořící pytel hnoje – a další environmentální antipatterny Archivováno 19. září 2015 na Wayback Machine ACM Queue 30. listopadu 2004 Volume 2, issue 7
Literatura
- Perl Design Patterns Book|Perl Design Patterns - bezplatná online kniha a wiki
- William J. Brown, Raphael C. Malveau, Hays W. McCormick III a Thomas J. Mowbray. AntiPatterns: Refaktoring softwaru, architektur a projektů v krizi . - John Wiley & Sons, 1998. - ISBN 0471197130 .
- William J. Brown, Hays W. "Skip" McCormick, Scott W. Thomas. AntiPatterns a Patterns ve správě konfigurace softwaru . - Wiley, 1999. - ISBN 978-0-471-32929-9 .
- William J. Brown, Hays W. "Skip" McCormick, Scott W. Thomas. AntiPatterns v projektovém řízení. - Wiley, 2000. - ISBN 978-0-471-36366-8 .
- Neal Ford, Matthew McCullough, Nathaniel Schutta. Vzory prezentací: Techniky pro vytváření lepších prezentací . — Addison-Wesley, 2012-08-15. — 395 s. — ISBN 9780132963374 .
- Chad Pytel, Tammer Saleh. Rails AntiPatterns: Best Practice Ruby on Rails Refactoring . — Addison-Wesley Professional, 2010-11-09. — 347 s. — ISBN 9780132660068 .
- Neill, Colin J. 9.1.2 Antipatterns in System Engineering: An Opening Trio // INCOSE International Symposium. - 2012. - Sv. 22 , č. 1 . - S. 1233-1245 . — ISSN 2334-5837 .
- Colin J. Neill, Philip A. Laplante. Antipatterns: Identifikace, Refaktoring a Management. - CRC Press, 2005. - ISBN 978-1-4200-3124-9 .
- Dimitrios Settas. Softwarový projekt antipattern knowledge management (doktorská práce). - Thessaloniki, Řecko: Aristotelova univerzita, 2011.
- Allen E. Typické chyby návrhu. - Nakladatelství "Peter", 2003. - 224 s. — ISBN 5-887827-304-6 .
- Smith CU, Williams LG Software Performance AntiPatterns // 2. mezinárodní seminář o softwaru a výkonu. — 2000.
Odkazy