Antipatró de disseny

Un antipatró de disseny és un patró de disseny que invariablement condueix a una mala solució per a un problema.

Quan es documenten els antipatrons, a més dels patrons de disseny, es proporciona informació i detalls als dissenyadors de sistemes per tal que no escullin mals camins, partint de documentació disponible en lloc de simplement de la intuïció.

El terme s'origina inspirat en el llibre Design Patterns, escrit per un grup d'autors conegut com a Gang of Four, i que aglutina un conjunt de bones solucions de programació. Els autors van batejar aquestes solucions amb el nom de "patrons de disseny" per analogia amb el mateix terme, usat en arquitectura. El llibre Anti-Patterns (de William Brown, Raphael Malveau, Skip McCormick i Tom Mowbray, juntament amb la més recent incorporació d' Scott Thomas) descriu als antipatrons com la contrapartida natural a l'estudi dels patrons de disseny. L'estudi formal d'errors que es repeteixen permet reconèixer i reconduir els elements involucrats cap a una millor solució. Els antipatrons no s'esmenten al llibre original de Design Patterns, ja que aquest és anterior.

Els antipatrons es consideren una part important de les bones pràctiques de programació. És a dir, un bon programador mirarà d'evitar els antipatrons sempre que sigui possible, la qual cosa requereix el seu reconeixement i identificació tan aviat com sigui possible, dins del cicle de vida del programari.

El concepte d'antipatró es pot aplicar a l'enginyeria en general, i fins i tot a qualsevol tasca realitzada per l'home. Encara que no s'escolta gaire fora del camp l'enginyeria, la noció està àmpliament estesa.

Alguns antipatrons de desenvolupament de programari

Antipatrons de gestió de projectes

• Fum i miralls (smoke and mirrors): Mostrar com serà una funcionalitat abans que estigui implementada.
• Mala gestió (bad management): Gestionar un projecte sense tenir suficients coneixements sobre la matèria.
• Programari inflat (software bloat): Permetre que les successives versions d'un sistema exigeixin cada vegada més recursos.

Antipatrons generals de disseny de programari

• Base de dades com a comunicador de processos (database as an IPC): Usar una base de dades per comunicar processos en un o diversos ordinadors, quan la comunicació entre processos directa és més adequada.
• Blob: Vegeu Objecte totpoderós.
• BOMQ (Batch Over MQ): Abús en l'ús d'integració basada en missatges en temps real per a transferències esporàdiques de gran grandària en segon pla.
• Classe Grossa: Dotar a una classe amb gaires atributs i/o mètodes, fent-la responsable de la majoria de la lògica de negoci.
• Botó màgic (magic pushbutton): Tendir, al desenvolupar interfícies, a programar la lògica de negoci en els mètodes d'interacció, implementant els resultats de les accions de l'usuari en termes no suficientment abstractes.
• Carrera d'obstacles (race hazard): Incapacitat de preveure les conseqüències de diferents successions d'esdeveniments.
• Entrada nyap (input kludge): No especificar ni implementar el tractament d'entrades invàlides.
• Fàbrica de combustible (gas factory): Dissenyar de forma innecessàriament complexa.
• Gran bola de fang (big ball of mud): Construir un sistema sense estructura definida.
• Interfície inflada (interface bloat): Pretendre que una interfície sigui tan potent que resulta extremadament difícil d'implementar.
• Inversió d'abstracció (abstraction inversion): No exposar les funcionalitats implementades que els usuaris necessiten, forçant a que es reimplementin a més alt nivell.
• Punt de vista ambigu (ambiguous viewpoint): Presentar un model sense concretar certs aspectes, postergant així decisions conflictives.
• Re-dependència (re-coupling): Introduir dependències innecessàries entre objectes.
• Sistema de canonades de calefacció (stovepipe system): Construir un sistema difícilment mantenible, acoblant components poc relacionats.

Antipatrons de disseny orientat a objectes

• Acoblament seqüencial (sequential coupling): Construir una classe que necesita que els seus mètodes s'invoquin en un ordre determinat.
• BaseBean: Heretar funcionalitat d'una classe utilitat en lloc de delegar en ella.
• Fallada de classe buida (empty subclass failure): Crear una classe que no supera el test de la subclasse buida, és a dir, que es comporta de forma diferent quan s'invoca des d'una subclasse que no afegeix cap modificació.
• Cridar a super (callsuper): Obligar a les subclasses a cridar a un mètode de la superclase que ha estat sobreescrit.
• Model de domini anémico (anemic domain model): Usar un model del domini sense cap lògica de negoci. Això no és un enfocament orientat a objectes perquè cada objecte hauria de tenir tant propietats com un comportament associat.
• Objecte embornal (object cesspool): Reutilitzar objectes no adequats realment per a la fi que es persegueix.
• Objecte totpoderós (god object): Concentrar massa funcionalitat en una única part del disseny (classe).
• Poltergeist (informàtica): Emprar objectes que tenen com a únic propòsit passar la informació a tercers objectes.
• Problema del cercle-el·lipse (circle-ellipse problem): Crear variables de tipus pensant en els valors de possibles subtipus.
• Problema del yoyó (jo-jo problem): Construir estructures (per exemple, d'herència) que són difícils d'entendre a causa de la seva excessiva fragmentació.
• Singletonitis: Abús de la utilització del patró singleton.
• YAFL'' (yet another fucking layer, i una altra maleïda capa més) o 'Codi Lasagna': Afegir capes innecessàries a un programa, biblioteca o framework. Aquesta tendència es va estendre força després que es publiqués el primer llibre sobre patrons.

Antipatrons de programació

• Nomenclatura heroica (heroic naming): Identificar els membres d'un programa (interfícies, classes, propietats, mètodes...) amb noms que fan que el conjunt aparenti estandardització d'acord amb l'enginyeria del programari però que en realitat oculta una implementació anàrquica.
• Acció a distància (action at a distance): Provocar la interacció no prevista de components molt distants d'un sistema.
• Acumular i disparar (accumulate and fire): Establir una col·lecció de variables globals per ser usades per un conjunt de subrutines.
• Ancora del vaixell (boat anchor): Retenir parts del sistema que ja no tenen utilitat.
• Bucle actiu (busy spin): Utilitzar espera activa quan existeixen alternatives.
• Codi dur (hard code): Fer suposicions sobre l'entorn del sistema en massa llocs de la implementació.
• Complexitat no indispensable (accidental complexity): Dotar de complexitat innecessària a una solució.
• Codi espagueti (spaghetti code): Construir sistemes l'estructura dels quals és difícilment comprensible, sobretot a causa de l'escassa utilització d'estructures de programació.
• Codi ravioli (ravioli code): Construir sistemes amb multitud d'objectes molt feblement connectats.
• Comprovació de tipus en lloc d'interfície (checking type instead of interface): Comprovar que un objecte és d'un tipus concret quan l'única cosa necessaria és verificar si compleix un contracte determinat.
• Confiança cega (blind faith): Descuidar la comprovació dels resultats que produeix una subrutina, o bé l'efectivitat d'un pegat o solució a un problema.
• Doble comprovació de bloqueig (double-checked locking): Comprovar, abans de modificar un objecte, si cal fer aquesta modificació, però sense bloquejar per comprovar-ho, de forma que la comprovació pot fallar.
• Fallada de caché (caching failure): Oblidar restablir una marca d'error quan aquest ja ha estat tractat.
• Lava seca (lava flow): Codi mort i informació de disseny oblidada que romanen congelats en un disseny canviant. Això és anàleg a un flux de lava en el qual es van solidificant trossos de roca. La solució inclou un procés de gestió de la configuració que elimina el codi mort i permet evolucionar o refer el disseny per fer créixer la qualitat.
• Lògica super-booleana (superboolean logic):Fer ús de comparacions o abstraccions de la lògica booleana innecessàries.
• Maneig d'excepcions (exception handling): Utilitzar el mecanisme de maneig d'excepcions del llenguatge per implementar la lògica general del programa.
• Maneig d'excepcions inútil (useless exception handling): Introduir condicions per evitar que es produeixin excepcions en temps d'execució, però llançar manualment una excepció si aquesta condició falla.
• Moment del codi (code momentum) : Establir massa restriccions sobre una part del sistema a causa de l'assumpció de moltes de les seves propietats des d'altres llocs del propi sistema.
• Nombres màgics (magic numbers): Incloure en els algorismes nombres concrets sense cap explicació aparent.
• Ocultació d'errors (error hiding): Capturar un error abans que es mostri a l'usuari, i reemplaçar-ho per un missatge sense importància o cap missatge.
• Packratting: Consumir memòria en excés a causa de no alliberar objectes reservats dinàmicament quan ja no són més necessaris.
• Programació per excepció (coding by exception): Afegir trossos de codi per tractar casos especials a mesura que s'identifiquen.
• Seqüència de bucle per casos (Loop-switch sequence): Programar un conjunt de passos seqüencials usant un bucle en combinació amb una estructura de control per casos.
• Cadenes màgiques (magic strings): Incloure cadenes de caràcters determinades per a fer comparacions dins el codi font, les quals el programador creu que no s'introduiran externamanet per part d'un usuari, i que poden activar certa funcionalitat oculta, esdeveniments, etc. Així, si l'usuari proporciona de manera innocent l'entrada predefinida en la cadena màgica, invocant la funcionalitat interna, la resposta del programa sovint és força inesperada per a l'usuari (apareixent així com "màgica").

Antipatrons metodològics

• Bala de plata (silver bullet): Assumir que la nostra solució tècnica favorita pot resoldre un problema molt major.
• Desenvolupament conduït per qui ho prova (tester driven development): Permetre que un projecte de programari avanci a base d'obtenir els seus nous requisits dels informes d'errors.
• Desfactorizació (de-factoring): Eliminar funcionalitat i reemplaçar-la amb documentació.
• Factor d'improbabilitat (improbability factor): Assumir que és improbable que un error conegut causi veritables problemes.
• Martell d'or (golden hammer): Assumir que la nostra solució favorita és universalment aplicable, fent bo la dita a un martell, tot són claus.
• Optimització prematura (premature optimization): Realitzar optimitzacions sense disposar de la informació suficient per fer-ho amb garanties, sacrificant decisions de disseny.
• Programació de copiar i pegar (copy and paste programming): Programar copiant i modificant codi existent en lloc de crear solucions genèriques.
• Programació per permutació (programming by permutation): Tractar d'aproximar-se a una solució modificant el codi una vegada i una altra per veure si acaba per funcionar.
• Reinventar la roda (reinventing the wheel): Enfrontar-se a les situacions buscant solucions des de zero, sense tenir en compte altres solucions que potser ja existeixen i que permeten solucionar els mateixos problemes.
• Reinventar la roda quadrada (reinventing the square wheel): Crear una solució pobra quan ja n'existeix una de bona.

Antipatrons de gestió de la configuració

• Conflicte d'extensions (extension conflict): Problemes amb diferents extensions que tracten de gestionar les mateixes parts del sistema (específic de Mac OS).
• Infern de dependències (dependency hell): Escenari de problemes produïts per les versions d'altres productes que es necessiten per fer funcionar un tercer.
  • Infern DLL (DLL hell): Problemes amb les versions, disponibilitat o proliferació de DLLs (específic de Microsoft Windows)
  • Infern JAR (JAR hell): Problemes amb diferents versions o ubicacions de fitxers JAR (Java), típicament causats per la falta de comprensió del model de càrrega de classes.

Alguns antipatrons organitzacionals

• Abast incremental (scope creep): Permetre que l'abast d'un projecte creixi sense el control adequat.
• Dependència de proveïdor (vendor lock-in): Construir un sistema que depengui massa d'un component proporcionat per un tercer.
• Disseny en comitè (design by committee): Comptar amb moltes opinions sobre un disseny, però sofrir la mancança d'una visió unificada.
• Escalada de compromís (escalation of commitment): No ser capaç de revocar una decisió a la vista de que no ha estat encertada.
• Funcionalitis creixent (creeping featuritis): Afegir noves funcionalitats al sistema en detriment de la seva qualitat.
• Gestió basada en nombres (management by numbers): Prestar massa atenció a criteris de gestió quantitatius, quan no són essencials o difícils de complir.
• Gestió de xampinyons (mushroom management): Tractar als empleats sense miraments, sense informar-los de les decisions que els afecten (mantenint-los coberts i en la foscor, com els xampinyons).
• Gestió perquè ho dic jo (management by perkele): Aplicar una gestió autoritària amb tolerància nul·la davant les dissensions.
• Migració de costos (cost migration): Traslladar les despeses d'un projecte a un departament o soci de negoci vulnerable.
• Obsolescència contínua (continuous obsolescence): Destinar esforços desproporcionats a adaptar un sistema a nous entorns.
• Organització de corda de violí (violin string organization): Mantenir una organització afinada i en bon estat, però sense cap flexibilitat.
• Paràlisi per anàlisi (analysis paralysis): Dedicar esforços desproporcionats a la fase d'anàlisi d'un projecte, eternitzant el procés de disseny iterant sobre la cerca de millors solucions o variants.
• Perill moral (moral hazard): Aïllar a qui ha pres una decisió arran de les conseqüències de la mateixa.
• Sistema de canonades (stovepipe): Tenir una organització estructurada de forma que afavoreix el flux d'informació vertical, però inhibeix la comunicació horitzontal.
• T'ho vaig dir (I told you so): Permetre que l'atenció se centri en que el desatés advertiment d'un expert s'ha demostrat justificat.
• Gallina dels ous d'or (cash cow): Pecar d'autocomplaença respecte a nous productes pel fet de disposar d'un producte legacy molt lucratiu.

Altres antipatrons

• Llançar a l'altre costat del mur (thrown over the wall): Quan un projecte involucra a diversos grups de treball i va passant seqüencialment d'un a l'altre, amb escassa o nul·la comunicació entre ells.
• Bitllet llop (wolf tiquet): Declarar compatibilitat amb un estàndard quan aquesta no existeix, o bé quan l'estàndard només inclou recomanacions no obligatòries que, de fet, no se segueixen.
• Festa dels bocazas (Blowhard Jamboree): Quan s'intenta que les decisions tècniques del projecte siguin les basades en opinions d'experts publicades a la premsa.
• Cadena sense longitud (string without length).
• Caixes de diàlegs en cascada (cascading dialog boxes).
• Atzucac (dead end): Trobar un problema que impedeix de continuar treballant, però la direcció no permet corregir el problema. L'equip queda estancat.
• Caminar per un camp de mines (walking through a mini field): Treballar amb un component poc provat (usualment inestable), i per tant poc confiable.
• Boc expiatori (scape goat): Davant circumstàncies de crisis en un projecte es pren la decisió de culpar a una persona o a un grup de persones concretes sense analitzar si veritablement la naturalesa del problema es troba en elles.
• Codificació brutal: Pressionar als programadors a treballar sobre una arquitectura sense dissenyar i sense requisits evidents.
• Comitè designat (appointed team): Crear un comitè o grup de treball per resoldre un problema i no encarregar-se d'aconseguir que el grup funcioni.
• Compensació equitativa (egalitarian compensation): Compensar al personal pel treball individual fet.
• Contenidor màgic (magic container): La implementació de mètodes que intenten ser prou flexibles per a adaptar el seu comportament a multitud de circumstàncies, sobrepassant el llindar que permet mantenir aquest comportament adequadament.
• Cossos tebis (warm bodies).
• Culte al vaixell de càrrega (cargo cult): Consisteix a copiar certes pràctiques que podrien ser considerades (no sempre) bones pràctiques sense conèixer massa bé els beneficis o avantatges que proporcionen, provocant esforç innecessari al projecte per incorporar-les o problemes.
• Cultura de la por (fear culture)): Ambient en el qual cada empleat té por de mostrar el resultat del seu treball per por de ser acomiadat per tenir errors.
• Cultura de l'heroi (hero culture): Es produeix quan una o poques persones prenen la responsabilitat de l'èxit de tot l'equip o projecte, sovint treballant de més.
• Decisió aritmètica (decision by arithmetic): En lloc d'intentar prendre una decisió basada en les dades disponibles i el coneixement i experiència dels nostres col·laboradors i nostre, es preten justificar la mateixa sobre la base d'uns factors presumptament objectius.
• Desenvolupament distribuït geogràficament (geographically distributed development).
• Desenvolupament marcat per les eines (autogenerated stovepipe): Preferir una solució generada automàticament abans que la millor solució.
• Descomposició funcional (functional decomposition): Traduir un programa escrit en un llenguatge estructurat a un llenguatge OO usant una sola classe i molts mètodes privats.
• Dissenyar per dissenyar (design for the sake of design): Realitzar un disseny excessivament complex sense cap necessitat real.
• Disseny amb arquitectura imposada (architecture as requirement): Imposar que el disseny consideri, obligatòriament, l'ús d'eines o mètodes no necessàriament idonis.
• Disseny d'aigüera (kitchen sink design).
• Dissenyadors empírics (architects don't code): Incapacitat del grup de disseny per avaluar la complexitat de l'objecte dissenyat.
• El correu electrònic és perillós (email is dangerous): Perill d'oblidar que darrere dels emails rebuts hi ha persones de carn i os.
• El gestor controla el procés (manager controls process).
• El vestit nou de l'emperador (emperor's new clothes): Por a assenyalar els defectes d'un producte o procés que un gerent o manager creu que funciona bé.
• El vell gran duc de York (the grand old Duke of York): Situació que esdevé quan els arquitectes o analistes no intervenen (un o els dos), deixant als programadors (especialistes en la implementació) pràcticament totes les decisions a nivell d'execució de les especificacions de l'usuari.
• Ells em van entendre (they understood me): Explicar a programadors o dissenyadors junior el que s'espera d'ells molt breument, i assumir que van entendre el que se'ls va demanar.
• Embut d'excepcions (exception funnel): Atrapar una excepció i ignorar-la, sense reportar-ho.
• Entrenar a l'entrenador (train the trainer): Contractar una formació sense haver precisat amb certa exactitud la matèria sobre la qual es desitja aquesta. Això pot provocar que la formació no s'enfoqui de forma adequada, tractant aspectes que no són necessaris en el projecte o deixant fora aspectes fonamentals. Contractar una formació sense tenir referències del formador, ja que potser el seu nivell de coneixement no és l'adequat a la naturalesa de la formació a impartir.
• És un problema d'operadors (it is an operator problem).
• Amagar les armes (cover your assets).
• Falsa economia (false economy): Permetre que les retallades de pressupost afectin l'eficiència dels treballadors (les pèrdues acaben sent més grans que el que s'estalvia).
• Fals punt final subrogat (false surrogate endpoint).
• Dates en punt flotant (floating point times).
• Fes la teva pròpia base de dades (roll your own database): Davant la necessitat de persistència de dades s'utilitza una solució que no es basa en un estàndard.
• Enginyers compatibles i intercanviables (plug compatible interchangeable engineers).
• Introducció de dificultat per analogia (analogy breakdown): Dissenyar per analogia amb problemes resolts, possiblement introduint dificultats no inherents al problema, o no tenir en compte dificultats pròpies del nou cas que es tracta.
• Invocar a constructors amb nuls (passing nulls to constructors).
• La disputa familiar (the feud): Quan existeix un conflicte entre gestors de projectes i no se li busca una solució definitiva al mateix.
• L'experiència mata el disseny (architecture by implication): No tenir cura del disseny per confiar excessivament en l'experiència prèvia.
• Els clients són ximples (customers are idiots): Pensar que un sap més que el client, i per tant no és necessària una recerca amb el client.
• Maníaco del control (control freak): El desig de control porta a la microgestió i aquesta al seu torn a una pèrdua important de la capacitat d'autogestió de l'equip, ja que tots els passos es mesuren mil·limètricament.
• Màquina de Rube Goldberg (Rube Goldberg machine): Realitzar implementacions molt complexes per a tasques senzilles.
• Matar el missatger (shoot the messenger).
• Matar dos ocells d'un sol tret (kill two birds with one stone).
• Matrimoni sumaríssim (sumo marriage): Sol tenir lloc en qualsevol situació en què existeixi una dependència d'un element o d'una sèrie de factors que dificulten el manteniment o evolució del sistema.
• Panotxa de blat de moro (corn cob): Mantenir persones dins el projecte que resulten difícils, conflictives o que funcionen absolutament al marge del que és qualsevol treball en equip o d'un comportament solidari i que trenquen amb l'harmonia del grup.
• Mecanismes de recompensa discordants (discordant reward mechanisms): Un equip rep reconeixement per ser el que més treball executa sobre la base de criteris objectius que no són vàlids per mesurar el nivell de productivitat o qualitat.
• Mesclador de programari (programari merger).
• Por a l'èxit (fear of success): Permetre que les úniques raons de que els treballs no s'acabin siguin de caràcter social.
• Moneda en punt flotant (floating point currency): Utilitzar una representació en punt flotant per a valors que representen diners, la qual cosa pot provocar pèrdua de precisió.
• Morir planificant (death by planning): Invertir més esforç (i temps) del necessari per establir un pla que després pot no ser idoni per les mateixes contingències del procés de desenvolupament, o quan no s'és flexible davant una planificació inicial, conservant-se al llarg del projecte encara que es pugui apreciar que resulta absolutament irreal.
• Nacionalisme (nationalism).
• Navalla suïssa (swiss army knife): Intentar crear un producte que solucioni diversos problemes poc relacionats entre si.
• No és el meu treball (Not my job): No solucionar algun problema evident argumentant que és problema o errada d'un altre.
• No especificar (specify nothing).
• No inventat aquí (not invented here): Quan l'organització o un es nega a utilitzar solucions, metodologies, pràctiques, eines, etc. externes només perquè no ens van passar pel cap prèviament.
• Una altra reunió més ho resoldrà (yet another meeting will solve it): Davant un problema en la planificació d'un projecte, es convoquen reunions per intentar solucionar el problema. En aquestes reunions participen els membres de l'equip del projecte que hauran de deixar la seva feina habitual, produint-se nous retards.
• Un altre programador més (yet another programmer).
• Presumpte hereu (heir apparent): Quan veiem que els possibles buits que podrien quedar per seguir progressant en la nostra organització ja tenen noms i cognoms (quan a més els seus mèrits són més que discutibles). Això provocarà la sortida de l'organització a la recerca d'altres alternatives o es produirà una pèrdua de motivació que impactarà directament en la productivitat.
• Procés a prova d'idiotes (idiot proof process).
• Programador discordante (net negative producing programmer): Hi ha projectes on el rendiment d'un o més membres de l'equip és molt inferior a l'esperat, fins al punt de que la seva productivitat neta en el projecte és negativa (el projecte milloraria amb el simple fet de prescindir d'aquestes persones, sense necessitat de substituir-les per una altra)
• Projecte del dia de la marmota (ground hog day project): Discutir els mateixos temes en totes les reunions, només per arribar a la conclusió que "alguna cosa s'ha de fer".
• Prova incompleta (asynchronous unit testing): Passar per alt en l'etapa de proves, algunes unitats en tots els casos, o totes les unitats en alguns casos.
• Vull estimacions ara (give me estimates now): Donar estimacions sense tenir suficients dades per fer-les.
• Requisits escampats per la paret (requirements tossed over the wall): Existeix un desordre general en els requisits: es troben en diferent grau de terminació, no hi ha priorització dels mateixos o és molt general com per poder fer una ordenació adequada per aquest criteri, etc. Això normalment és provocat per una col·laboració inadequada per part dels usuaris.
• Requisits ocults (Hidden requirements): L'equip del projecte coneixedor de la dificultat d'implementar un determinat requisit l'òbvia dins del catàleg de requisits, li assigna una prioritat molt baixa o ho engloba dins d'un requisit de major nivell quedant difuminat dins d'aquest. Els usuaris no especifiquen un requisit o no ho especifiquen de forma adequada, sol·licitant explicacions a posteriori per la no implementació d'aquest requisit o pel seu comportament incorrecte.
• Si funciona, no ho toquis (if it is working don't change):.
• Som ximples (we are idiots): Pensar que el coneixement intern del problema és perillós (pel risc que sigui pobre o equivocat), i demanar validació del client per a cada característica o gran decisió.
• Targetes CRCI (CRCI cards): Quan s'usa la tècnica de targetes CRC, s'aprofita i s'inclou en la mateixa la implementació de la classe, convertint-se automàticament la targeta CRC (Class-Responsibility-Collaboration) en CRCI (Class-Responsibility-Collaboration-Implementation).
• Tempesta de retrets (blame storming): En un equip de projecte s'arriba a la conclusió que la millor forma d'analitzar les causes de no haver assolit els objectius és que es discuteixi qui ha tingut la culpa internament.
• Torre de vudú (tower of voodoo): Es té un codi que se sap que funciona (encara que generalment no se sap molt bé com) i es vol afegir algun tipus de funcionalitat addicional, a vegades poc cohesionada amb la ja implementada i se li afegeix un embolcall (wrapper) proporcionant una nova interfície d'accés a aquest nou component.
• Parany per a ossos (bear trap): Invertir molt en una eina poc adaptada o factible, de forma que després és impossible desfer-se d'ella.
• Únic punt de sortida de funció (single function exit point).
• Valor per defecte indefinit (zero means null): Escollir un valor arbitrari per representar la indefinició, sense garantir que aquest valor no pot realment succeir.
• Violència intel·lectual (intellectual violence): De forma interna en un equip de treball o en una reunió amb el client i/o amb usuaris s'utilitzen termes, generalment tècnics, que no són entesos o coneguts per la majoria dels interlocutors.

Vegeu també

• Patró de disseny
• Crisi del programari

Bibliografia

• Brown. (en anglès). Wiley. ISBN 9780471197133. 

Enllaços externs

• C2.com (antipatrons) Portland Pattern Repository's Wiki