Antimodel
Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de
versiunea revizuită pe 29 mai 2022; verificarea necesită
1 editare .
Un anti-pattern este o abordare comună pentru rezolvarea unei clase de probleme comune care este ineficientă, riscantă sau neproductivă [1] . Spre deosebire de un model de design , luarea în considerare a unui antipattern include atât o soluție incorectă a unei probleme cu semnele și consecințele acesteia, cât și o cale de ieșire din situație [2] .
Termenul provine de la informatică , din cartea Gang of Four „ Design Patterns ”, care a prezentat exemple de bune practici de programare. Autorii au numit aceste bune practici „patterns” iar opusul lor sunt „anti-patterns”. O parte a bunei practici de programare este evitarea antipattern-urilor. Înainte de apariția termenului, toate problemele erau numite capcane ( capcane ) . Astfel, antipatternele sunt cele mai comune capcane, dar nu toate capcanele vor fi antipattern.
Antimodelurile sunt conceptual similare cu tiparele prin faptul că documentează soluții repetitive la probleme comune. Sunt cunoscute ca anti-pattern deoarece folosirea (sau abuzul) lor are consecințe negative [3] .
Istorie
Odată cu dezvoltarea industriei IT, amploarea proiectelor software și costul resurselor pentru acestea au crescut rapid, ceea ce a dat naștere unui număr mare de probleme cu care se confruntau programatorii. Cele mai multe dintre aceste probleme au fost tipice și au apărut în aproape fiecare proiect major. La începutul anilor 90, cataloagele de modele de design , "modele" ( ing. modele de design ) - modalități elegante și dovedite de a rezolva problemele tipice, au câștigat o popularitate considerabilă. Modelele sunt încă puternice și extrem de populare astăzi, cu toate acestea, mulți dezvoltatori care folosesc modele populare în situații pentru care nu au fost destinate au creat mai multe probleme decât au rezolvat. În plus, inginerii IT, ca și lucrătorii din orice alt domeniu de activitate, pot identifica greșelile tipice făcute din cauza bazei de cunoștințe insuficiente sau a lipsei de experiență, a grabei și a presiunii din cauza termenelor limită ale proiectelor, a constrângerilor financiare și altele.
Pentru prima dată, termenul „anti-pattern” în sensul unei descrieri generalizate a unei soluții tipice nereușite a fost folosit în 1996 de Michael Akroyd la Object World West Conference, dedicată aspectelor programării orientate pe obiecte . [4] În prezentarea sa Anti-Patterns: Preventing Object Misuse, Aykroyd a atras atenția asupra constructelor de programare dăunătoare, dar comune, în special asupra celor care contravin principiilor OOP. În plus, pentru fiecare astfel de design, el a oferit un înlocuitor eficient.
Termenul în sensul de „idee proastă” a apărut înainte de Aykroyd, dar nu a fost publicat și nu a fost deosebit de popular. Și totuși nu merită să-i atribui autoritatea unei singure persoane. Potrivit lui William Brown, autorul cărții Antipatterns: Refactoring Applications, Architectures, and Projects, un antipattern este o etapă în evoluția conceptului de model de design, o extensie a modelului lor.
Clasificare
William Brown distinge anti-modele din trei puncte de vedere: dezvoltator , arhitect și manager :
- Antimodeluri de dezvoltare ]
- Antimodele arhitecturale [ ]
- Antimodele organizaționale (antimodele manageriale )
Neil și Laplante dau un al patrulea tip [5] [6] :
În plus, au fost descrise anti-modele pentru tehnologiile informaționale individuale, cum ar fi [6] :
Antipatterns de dezvoltare
Probleme tehnice și soluții cu care se confruntă programatorii [6] :
Anti-modele în programarea orientată pe obiecte
- Clasa de utilitate de bază (BaseBean [12] ): Moșteniți funcționalitatea din clasa de utilitate în loc să o delegeți.
- Anemic Domain Model [12] - teama de a plasa logica în obiectele de domeniu.
- Apelarea unui strămoș (Call super): Pentru a implementa funcționalitatea aplicației, o metodă a unei clase descendente trebuie să apeleze în mod necesar aceleași metode ale clasei strămoși.
- Eșec subclasa goală : Crearea unei clase (în Perl ) care eșuează „Testul subclasei goale” din cauza comportamentului diferit față de o clasă care moștenește din aceasta neschimbată.
- Obiectul lui Dumnezeu : concentrarea prea multor funcții într-o singură parte a sistemului (clasă).
- Poznă de obiecte : Reutilizați obiectele care sunt într-o stare inutilizabilă.
- Poltergeist 13] :Obiecte al căror singur scop este de a transmite informații către alte obiecte.
- Yo- yo problem (Yo-yo problem): estomparea excesivă a codului strâns cuplat (de exemplu, executat în ordine) de-a lungul ierarhiei clasei.
- Singurătate (singletonită): Utilizarea inadecvată a modelului singleton .
- Zona de prieteni : Utilizarea necorespunzătoare a claselor de prieteni și a funcțiilor de prietenie în C++.
- Supa de interfață [14] : Combinând mai multe interfețe separate după principiul izolării interfeței (segregarea interfeței) într-una singură.
- Dangling ends : o interfață, ale cărei cele mai multe metode sunt lipsite de sens și sunt implementate de „dummy”.
- Stub: O încercare de a „trage” o interfață deja existentă, care este de puțin folos în sensul unui obiect, în loc să creeze una nouă.
Antipatterns la scrierea codului
- Complexitate accidentală : Adăugarea de complexitate inutilă unei soluții.
- Acțiune la distanță o interacțiune neașteptată între părți larg separate ale unui sistem.
- Acumulați și declanșați: setați parametrii subrutinei într-un set de variabile globale.
- Blind faith : Verificare insuficientă a corectitudinii corectării erorilor sau a rezultatului subrutinei.
- Boat anchor (Boat anchor) [13] : Salvarea unei părți a sistemului care nu mai este utilizată.
- Învârtire ocupată, așteptare ocupată : consumarea resurselor CPU timp procesor) în timp ce așteptați un eveniment, de obicei prin repetarea constantă a verificării, în loc să utilizați programarea asincronă (de exemplu, mesaje sau sistem de evenimente).
- Eroare de stocare în cache : Am uitat să resetați indicatorul de eroare după ce l-am gestionat.
- Modelul scutecului miroase: resetați indicatorul de eroare fără a-l manipula sau a-l transmite unui handler din amonte.
- Verificarea tipului în loc de apartenență, Verificarea tipului în loc de interfață: Verificarea faptului că un obiect este de un anumit tip într-un moment în care este necesară doar o anumită interfață.
- Momentul codului: supralimitarea unei părți a unui sistem prin implicarea constantă a comportamentului acesteia în alte părți ale sistemului .
- Codare prin excepție : Adăugarea unui cod nou pentru a sprijini fiecare caz special recunoscut.
- Cod criptic : Utilizarea abrevierilor în locul numelor mnemonice.
- Hard coding : injectarea de ipoteze despre mediul unui sistem în prea multe puncte de implementare.
- Soft coding : O teamă patologică de codare hard care duce la configurarea totul, în timp ce configurarea sistemului în sine se transformă în programare.
- Flux de lavă 13] : Păstrarea codului nedorit (redundant sau de calitate scăzută) deoarece este prea scump de eliminat sau va avea consecințe imprevizibile.
- Numere magice : Folosind constante numerice fără a explica semnificația lor.
- Cod de procedură : Când o altă paradigmă este mai potrivită.
- Cod spaghete (uneori „paste”) [13] : Cod cu o ordine de execuție prea confuză.
- Cod lasagnia (cod lasagnia, sau „ceapă” (ceapă)): cuplare excesivă între straturi de abstractizare, ceea ce duce la incapacitatea de a schimba un nivel fără a le schimba pe celelalte.
- Cod ravioli (sau „găluște”): obiectele sunt atât de „lipite” între ele încât practic nu permit refactorizarea.
- Balon de săpun : un obiect inițializat cu gunoi pretinde că conține unele date cât mai mult timp posibil.
- Mutex hell: se injectează prea multe obiecte de sincronizare între fire.
- (Meta-)Template cancer: Utilizarea pe scară largă a șabloanelor (mai ales C++), inclusiv acolo unde utilizarea lor nu este justificată. Acest lucru reduce înțelegerea și întreținerea codului și încetinește compilarea.
Anti-tipare metodologice
- Copiere și lipire de programare [13] : Copierea (și modificarea ușoară) a codului existent în loc de a crea soluții generice.
- Defactoring : Procesul de distrugere a funcționalității și înlocuirea acesteia cu documentație.
- Ciocanul de aur [13] : O convingere puternică că o soluție preferată este aplicabilă universal. Numele provine de la zicala „când ții un ciocan, toate problemele arată ca niște cuie”.
- Factorul de improbabilitate : ipoteza că este imposibil ca o eroare cunoscută să se declanșeze.
- Optimizare prematură : O optimizare în etapa de proiectare a unui segment de cod care îl face mai complex sau mai corupt.
- Programare prin permutare: O abordare a dezvoltării software cu mici modificări.
- Reinventarea roții [ 13] : Construiți de la zero în loc să folosiți o soluție bună disponibilă la raft.
- Reinventarea roții pătrate : Crearea unei soluții proaste, având în vedere că o soluție mai cunoscută există deja.
- Autodistrugere : o eroare fatală sau un comportament nestandard al programului care duce la refuzul serviciului, care rezultă dintr-o altă eroare mai puțin gravă. De exemplu, atunci când apare o eroare, aplicația începe să scrie în jurnal foarte repede și scrie mult în jurnal, drept urmare spațiul pe hard disk se epuizează mai repede decât detectează monitorizarea.
- Două tuneluri : Aducerea de noi funcționalități într-o aplicație separată în loc de extinderea uneia existente. Este cel mai adesea folosit atunci când dintr-un anumit motiv (în principal din cauza lipsei de timp sau a lipsei de voință a managementului) a face modificări la un cod existent este mai costisitoare decât a crea unul nou. În acest caz, clientul ajunge să aibă două aplicații care rulează simultan sau alternativ una de cealaltă.
- Commit assassin : Efectuarea de modificări individuale la sistemul de control al versiunilor fără a verifica impactul acestora asupra altor părți ale programului. De regulă, după astfel de comiteri, munca echipei este paralizată în timp ce se remediază probleme în locuri care anterior funcționau fără erori.
Anti-modele de management al configurației
- Dependency Hell ( numit și „ DLL hell ” sau „DLL hell” pe platforma Microsoft Windows ): Creșterea graficului dependențelor reciproce ale produselor software și bibliotecilor, ceea ce duce la dificultatea instalării celor noi și a eliminării celor vechi. În cazuri complexe, diferite produse software instalate necesită versiuni diferite ale aceleiași biblioteci. În cele mai complexe cazuri, un produs poate necesita indirect două versiuni ale aceleiași biblioteci simultan.
Diverse
- Fum și oglinzi [13] : O demonstrație a cum ar arăta funcțiile nescrise (numele provine de la două moduri preferate în care magicienii își ascund secretele).
- Balonare software : Permiterea versiunilor succesive ale unui sistem să necesite din ce în ce mai multe resurse.
- Caracteristici casete de selectare : Transformarea unui program într-un conglomerat de funcții prost implementate și fără legătură (de obicei, pentru a face publicitate că funcția este acolo).
Anti-modele arhitecturale
Probleme tipice asociate cu structura sistemului [6] :
- Inversarea abstracției : Ascunderea unei piese de funcționalitate de la utilizarea externă, în speranța că nimeni nu o va folosi.
- Punct de vedere ambiguu [ 13] : O reprezentare a unui model fără a specifica punctul de vedere al acestuia.
- Minge mare de noroi: Un sistem cu o structură de nerecunoscut.
- Blob (Blob [13] ): vezi obiectul lui Dumnezeu .
- Fabrică de gaz : complexitate opțională de proiectare.
- Input kludge [13] : Uitarea specificației și implementarea suportului pentru posibile intrări invalide.
- Balonarea interfeței : Dezvoltarea interfeței este foarte puternică și foarte dificil de implementat.
- Buton magic : Efectuarea rezultatelor acțiunilor utilizatorului într-o interfață neadecvată (nu suficient de abstractă). De exemplu, în sisteme precum Delphi , aceasta este scrierea logicii aplicației în manipulatoarele de clic pe buton.
- Re -Coupling: Procesul de introducere a unei dependențe inutile .
- Coș de fum (Stovepipe System [13] ): Un ansamblu rar susținut de componente prost cuplate.
- Pericol de cursă (condiție de cursă): neanticiparea posibilității ca evenimentele să se producă într-o altă ordine decât cea așteptată .
- Cursa de sobolani : Crearea nejustificată a multor clase mici și abstracte pentru a rezolva o sarcină specifică de un nivel superior.
- Mutilarea : „Ascuțirea” inutilă a unui obiect pentru o anumită sarcină foarte îngustă, astfel încât să nu poată lucra cu alte sarcini, deși foarte asemănătoare.
- Salvați sau muriți: salvarea modificărilor de configurare pe hard disk numai când aplicația se termină; duce la faptul că, în cazul unei erori în program, aceste date se vor pierde
Anti-modele organizaționale
Probleme cu care se confruntă managerii (sau grupurile de manageri) [6] :
- Paralizia analizei [13] : costuri nerezonabil de mari pentru analiză și proiectare. Adesea duce la închiderea proiectului înainte de începerea implementării acestuia.
- Cash cow : dacă există un produs care aduce beneficii fără investiții semnificative, nu se investesc fonduri în dezvoltarea și dezvoltarea de noi produse.
- Învechire continuă 13] : devotați o cantitate disproporționată de efort pentru a porta un sistem în medii noi.
- Migrarea costurilor : transferul costurilor proiectului către un departament sau partener de afaceri slab.
- Featurism înfiorător: Adăugarea de noi funcții în detrimentul calității generale a sistemului.
- Inflated elegance (Creeping elegance): o îmbunătățire disproporționată a frumuseții codului în detrimentul funcționalității și calității generale a sistemului.
- Proiectare de către comitet [13] : dezvoltarea unui proiect fără control centralizat sau fără conducere competentă.
- Escaladarea angajamentului: implementării unei decizii după ce s-a dovedit că aceasta este greșită.
- Ți- am spus așa: ignorând opinia experților.
- Managementul după numere: O accentuare excesivă a numerelor care sunt foarte indirect legate de sistemul gestionat, greu de obținut sau supuse efectului Goodhart .
- Măsuri draconice (Management de perkele): stil de management nerezonabil de rigid.
- Managementul ciupercilor [ [13] : informarea insuficientă a lucrătorilor cu privire la munca prestată.
- Creptarea domeniului aplicare : Pierderea controlului asupra creșterii proiectului.
- Vendor lock-in [13] : Blocare furnizor.
- Warm Bodies [13] : O persoană a cărei contribuție la proiect este pusă la îndoială.
- Șef unic de cunoștințe (SHOK): atunci când o singură persoană din echipă are informații sau abilități vitale pentru proiect, iar când pleacă, munca se oprește.
- Cavaler în armură strălucitoare (KISA): când un bărbat apare pe scenă încercând să repare totul fără să spună nimănui ce a făcut sau de ce.
Neil și LaPlante oferă următoarele antimodeluri [5] :
- Manager absent : Managerul este evaziv sau invizibil pentru o lungă perioadă de timp - se ascunde undeva în birou sau departe de birou.
- Have only a hammer (All You Have Is A Hammer): control unidirecțional, în care aceleași tehnici sunt folosite pe toți subordonații și în toate situațiile. Uneori numit și „One-Trick Pony”.
- Manager sălbatic (Negotiator Cage Match): Orice manager care este încăpățânat dincolo de rațiune și folosește o abordare de management „Câștigă cu orice preț” sau „Am dreptate și tu greșești”. Ei au adesea o cană de cafea cu Regulile de management: „Regula #1: șeful are întotdeauna dreptate. Regula #2: Dacă șeful greșește, vezi Regula #1.”
- Doppelganger : un manager sau coleg cu care este fie ușor, fie greu de lucrat.
- Cercuri infructuoase : oferiți managerilor din ce în ce mai multe date de care au nevoie pentru a lua o decizie, dar managerii nu iau niciodată o decizie, continuând să vă solicite date. Nu știi de ce au nevoie de aceste date.
- Copilul de Aur : Copilul de Aur apare atunci când un manager acordă o responsabilitate specială, oportunitate, recunoaștere sau recompensă unui membru al echipei sale pe baza unei relații personale cu el și în ciuda acțiunilor sale reale. Toată lumea este enervată de Copilul de Aur, dar adevărata problemă este a managerului.
- Pui fără cap : un manager fără nicio concentrare sau plan care nu termină niciodată nimic.
- Lider, nu manager: subliniază importanța unui leadership eficient.
- Parrot Manager (Clonare managerială): Manageri de mijloc care în cele din urmă încep să se comporte ca șefii lor.
- Manager nu lider: Acest manager este bun la sarcini administrative și manageriale, dar nu are capacitatea de conducere.
- Abuz de valori: utilizarea greșită a valorilor din cauza incompetenței sau manipulării deliberate a datelor .
- Tip simpatic: Un manager care se concentrează pe a fi prietenul tuturor ajunge să-i dezamăgească pe toți și să nu-și facă treaba.
- Managementul ciupercilor : o situație în care conducerea nu poate comunica eficient cu personalul. Practic, informațiile sunt ascunse în mod intenționat, astfel încât toată lumea să fie „grasă, proastă și fericită”. Numele este legat de o analogie: șampioanele sunt cultivate în întuneric și în gunoi de grajd.
- Învârtirea plăcilor : managerul își ascunde ineficiența forțând muncitorii să lucreze laborios și inutil.
- Erou Proletariat : Managerul își tratează subalternii ca pe lucrători ideali, dar aceasta este doar cârja lui, folosită pentru a masca managementul prost. Este o formă de „motivare” a personalului care oferă managementului un motiv pentru a crește rezultatele așteptate sau pentru a obține mai mult pentru mai puțin.
- Rising Upstart : Superstaruri care nu pot pierde timpul învățând și găsindu-și locul. Uneori se poate datora ignoranței (nu știu ce nu știu), iar uneori poate fi din cauza nerăbdării (știu ceea ce alții nu știu). Un astfel de parvenit reprezintă o adevărată provocare pentru toți managerii, cu excepția celor mai experimentați.
- Drumul spre Nicăieri: Lipsa unui plan provoacă confuzie și criză de conducere.
- Spineless Executive: Orice manager care nu are curajul să facă față confruntării necesare sau să facă față unei situații dificile. În schimb, evită în totalitate confruntarea sau situația sau îți cere să-i dai vești proaste.
- Cavaler cu trei capete : un manager indecis.
- Ultima armă: managerul anunță că toată lumea se poate baza pe angajați excepționali, astfel încât acești angajați să devină conducta pentru orice.
- Corpuri calde : O situație managerială în care un lucrător care abia îndeplinește cerințele minime trece de la proiect la proiect sau de la echipă la echipă. Un muncitor slab este numit „corp cald”, deși adevărata problemă este a managerului. Acest anti-model este opusul Starburst în ceea ce privește abilitățile și potențialul.
Antipatterns de mediu
Probleme cauzate de structura dominantă a organizației și modelul social, care sunt rezultatul politicii publice în organizație [15] [6] [5] [16] :
- Colonia de furnici - sub frumusețea exterioară se află plantarea țintelor[ clarifica ] .
- Atlas Shrugs ( Atlas Shrug ) - după succes temporar, începe declinul[ clarifica ] .
- Colectiv autonom - autogestionarea duce la pasivitate[ clarifica ] .
- Sindromul broaștei fierte ( Boiling Frog Syndrome ) - schimbări negative treptate sunt observate când este prea târziu.
- Burning Bag of Dung - managerul lasă vecinii (subordonați, secții, succesor) într-o situație delicată.
- Fascinație pentru cuvintele la modă ( Buzzword Mania ) - managementul jonglează cu cuvintele pe care puțini dintre secții le înțeleg.
- Balon Dezumflat - cei mai buni ani ai companiei au trecut în urmă, dar nu poate realiza acest lucru și reduce costurile.
- Obiective divergente _ _[ clarifica ]
- Dogmatic despre disfuncție _
- Curaj neclintit ( Dunkirk Spirit )[ clarifica ]
- Noua rochie a regelui ( Hainele noi ale împăratului ) - bazată pe basmul cu același nume
- Doctrina corectitudinii _ _[ clarifica ]
- Grăbește-te - fă oamenii să râdă ( Fools Rush In )[ clarifica ]
- boala fondatorului ( funderita )[ clarifica ]
- Sindromul chelnerului francez - o atmosferă nesănătoasă în companie (opinie stereotipă americană despre restaurantele franțuzești mici) .
- Hazing ( Geek Hazing ) - începătorii sunt încărcați cu o mulțime de sarcini banale care nu îi ajută să învețe.
- Neîncredere instituțională _ _[ clarifica ]
- Orașul tarabelor ( Kiosk City ) - fiecare departament își dezvoltă propriul mecanism de schimb de informații.
- Puterea lui Gray ( Mediocrație )
- Regele cu un ochi ( Regele cu un ochi )[ clarifica ]
- Orange Stand Economics este o estimare slabă a costurilor.
- Insula Pitcairn ( Insula Pitcairn )[ clarifica ]
- sate Potemkin
- Procese conflictuale ( ciocnirea proceselor )[ clarifica ]
- Cubul Rubik _ _[ clarifica ]
- Copii fără pantofi ( Copii fără pantofi )[ clarifica ]
- Vițel de aur ( Închinarea vițelului de aur )[ clarifica ]
Vezi și
Note
- ↑ Budgen, D. Software design. - Addison-Wesley, 2003. - ISBN 0-201-72219-4 .
- ↑ Brown, 1998 , capitolul 2.
- ↑ Smith CU, 2000 .
- ↑ http://c2.com/cgi/wiki?AntiPattern . Cunningham & Cunningham Inc. . Consultat la 15 februarie 2006. Arhivat din original pe 3 aprilie 2005. (nedefinit)
- ↑ 1 2 3 Neill, Laplante, 2005 .
- ↑ 1 2 3 4 5 6 Settas, 2011 .
- ↑ Miroslav Kis. Antimodele de securitate a informațiilor în ingineria cerințelor software. În Proceedings of the 9th Conference on Pattern Language of Programs (Plop), 2002.
- ↑ John Long. Antimodele de reutilizare software. În ACM SIGSOFT Software Engineering Notes, volumul 26, pagina 4, iulie 2001.
- ↑ Paula Kotze, Karen Renaud și Judy van Biljona. Nu faceți asta - capcane în utilizarea anti-modelelor în predarea principiilor interacțiunii om-calculator. Computers and Education, 50(3):979-1008, aprilie 2008
- ↑ J. Krai și M. Zemlicka. Cele mai importante antimodeluri orientate spre servicii. În lucrările Conferinței Internaționale privind Progresele Ingineriei Software (ICSEA), 2007.
- ↑ P. A. Laplante, R. R. Hoffman și G. Klein. Antipatterns în crearea sistemelor inteligente. IEEE Intelligent Systems, 22:91-95, 2007.
- ↑ 1 2 Rajiv Ramnath, Cheyney Loffing. Începeți programarea iOS pentru manechini . — John Wiley & Sons, 2014-04-14. - S. 105. - 470 p. — ISBN 9781118799277 . Arhivat pe 23 iulie 2016 la Wayback Machine
- ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 William J. Brown. AntiPatterns: software de refactorizare, arhitecturi și proiecte în criză . — Wiley, 03-04-1998. — 156 p. — ISBN 0-471-19713-0. Arhivat pe 22 decembrie 2015 la Wayback Machine
- ↑ Gary McLean Hall. Cod adaptiv prin C#: codare agilă cu modele de design și principii SOLIDE. - Microsoft Press, 2014. - S. 267-268. — ISBN 978-0735683204 .
- ↑ Original: forțe socio-politice
- ↑ Phillip Laplante The Burning Bag of Dung—and Other Environmental Antipatterns Arhivat 19 septembrie 2015 la Wayback Machine ACM Queue 30 noiembrie 2004 Volumul 2, numărul 7
Literatură
- Perl Design Patterns Book|Perl Design Patterns - O carte și wiki online gratuite
- William J. Brown, Raphael C. Malveau, Hays W. McCormick III și Thomas J. Mowbray. AntiPatterns: software de refactorizare, arhitecturi și proiecte în criză . - John Wiley & Sons, 1998. - ISBN 0471197130 .
- William J. Brown, Hays W. „Skip” McCormick, Scott W. Thomas. AntiPatterns și Patterns în Software Configuration Management . - Wiley, 1999. - ISBN 978-0-471-32929-9 .
- William J. Brown, Hays W. „Skip” McCormick, Scott W. Thomas. AntiPatterns în managementul proiectelor. - Wiley, 2000. - ISBN 978-0-471-36366-8 .
- Neal Ford, Matthew McCullough, Nathaniel Schutta. Modele de prezentare: tehnici pentru realizarea unor prezentări mai bune . — Addison-Wesley, 15.08.2012. — 395 p. — ISBN 9780132963374 .
- Chad Pytel, Tammer Saleh. Rails AntiPatterns: Cele mai bune practici Ruby on Rails Refactoring . — Addison-Wesley Professional, 2010-11-09. — 347 p. — ISBN 9780132660068 .
- Neill, Colin J. 9.1.2 Antipatterns in Systems Engineering: An Opening Trio // INCOSE International Symposium. - 2012. - Vol. 22 , nr. 1 . - P. 1233-1245 . — ISSN 2334-5837 .
- Colin J. Neill, Philip A. Laplante. Antimodele: identificare, refactorizare și management. - CRC Press, 2005. - ISBN 978-1-4200-3124-9 .
- Dimitrios Settas. Managementul cunoștințelor antipattern de proiect software (teză de doctorat). - Salonic, Grecia: Universitatea Aristotel, 2011.
- Allen E. Erori tipice de proiectare. - Editura „Petru”, 2003. - 224 p. — ISBN 5-887827-304-6 .
- Smith CU, Williams LG Software Performance AntiPatterns // Al 2-lea workshop internațional despre software și performanță. — 2000.
Link -uri