Antipatrón

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 29 de mayo de 2022; la verificación requiere 1 edición .

Un antipatrón es un  enfoque común para resolver una clase de problemas comunes que son ineficientes, riesgosos o improductivos [1] . A diferencia de un patrón de diseño , la consideración de un antipatrón incluye tanto una solución incorrecta a un problema con sus signos y consecuencias, como una salida a la situación [2] .

El término proviene de la informática , del libro " Design Patterns " de Gang of Four, que establecía ejemplos de buenas prácticas de programación. Los autores han llamado a estas buenas prácticas "patrones" y lo contrario de ellos son "anti-patrones". Parte de una buena práctica de programación es evitar antipatrones. Antes de que apareciera el término, todos los problemas se llamaban trampas ( pitfalls ) . Por lo tanto, los antipatrones son las trampas más comunes, pero no todas las trampas serán antipatrones.

Los antipatrones son conceptualmente similares a los patrones en el sentido de que documentan soluciones repetitivas a problemas comunes. Se les conoce como antipatrones porque su uso (o abuso) tiene consecuencias negativas [3] .

Historia

Con el desarrollo de la industria de TI, la escala de los proyectos de software y el costo de los recursos para ellos crecieron rápidamente, lo que dio lugar a una gran cantidad de problemas que enfrentaron los programadores. La mayoría de estos problemas eran típicos y ocurrieron en casi todos los proyectos importantes. A principios de los años 90, los catálogos de patrones de diseño , "patrones" ( ing.  patrones de diseño ), formas elegantes y probadas de resolver problemas típicos, ganaron una popularidad considerable. Los patrones siguen siendo poderosos y extremadamente populares hoy en día, sin embargo, muchos desarrolladores que utilizan patrones populares en situaciones para las que no estaban destinados crearon más problemas de los que resolvieron. Además, los ingenieros de TI, como los trabajadores de cualquier otro campo de actividad, pueden identificar los errores típicos cometidos debido a una base de conocimientos insuficiente o falta de experiencia, prisa y presión debido a los plazos de los proyectos, restricciones financieras y otros.

Por primera vez, el término "antipatrón" en el sentido de una descripción generalizada de una típica solución fallida fue utilizado en 1996 por Michael Akroyd en la Object World West Conference, dedicada a aspectos de la programación orientada a objetos . [4] En su presentación Anti-Patterns: Preventing Object Misuse, Aykroyd llamó la atención sobre construcciones de programación dañinas pero comunes, en particular aquellas que van en contra de los principios de OOP. Además, para cada diseño de este tipo, ofreció un reemplazo efectivo.

El término en el sentido de "mala idea" apareció antes de Aykroyd, pero no se publicó y no fue particularmente popular. Y, sin embargo, no vale la pena atribuir la autoría a una sola persona. Según William Brown, autor de Antipatterns: Refactoring Applications, Architectures, and Projects, un antipatrón es una etapa en la evolución del concepto de patrón de diseño, una extensión de su modelo.

Clasificación

William Brown distingue los antipatrones desde tres puntos de vista: desarrollador , arquitecto y gestor :

• Antipatrones de desarrollo ]
• Antipatrones arquitectónicos [ ]
• Antipatrones organizacionales ( antipatrones gerenciales )

Neil y Laplante dan un cuarto tipo [5] [6] :

• Antipatrones ambientales ]

Además, se han descrito antipatrones para tecnologías de la información individuales como [6] :

• seguridad de la información [7]
• reutilización de código [8]
• interacción humano-computadora [9]
• arquitectura orientada a servicios [10]
• sistema de información inteligente [11]

Antipatrones de desarrollo

Problemas técnicos y soluciones a los que se enfrentan los programadores [6] :

Anti-patrones en programación orientada a objetos

• Clase de utilidad base (BaseBean [12] ): hereda la funcionalidad de la clase de utilidad en lugar de delegarla.
• Modelo de dominio anémico [12]  : miedo a colocar la lógica en los objetos del dominio.
• Llamar a un ancestro (Call super): Para implementar la funcionalidad de la aplicación, un método de una clase descendiente debe necesariamente llamar a los mismos métodos de la clase ancestro.
• Error de subclase vacía : creación de una clase (en Perl ) que falla la "Prueba de subclase vacía" debido a un comportamiento diferente en comparación con una clase que hereda de ella sin cambios.
• Dios objeto: La concentración de demasiadas funciones en una parte del sistema (clase).
• Pozo negro de objetos : reutilizar objetos que se encuentran en un estado inservible.
• Poltergeist 13] :Objetos cuyo único propósito es transmitir información a otros objetos.
• Yo- yo problem (Yo-yo problem): Desenfoque excesivo de código estrechamente acoplado (por ejemplo, ejecutado en orden) a lo largo de la jerarquía de clases.
• Soledad (Singletonitis): Uso inapropiado del patrón singleton .
• Zona de amigos : uso inapropiado de clases de amigos y funciones de amigos en C++.
• Sopa de interfaces [14] : combinación de varias interfaces separadas según el principio de aislamiento de interfaces (segregación de interfaces) en una sola.
• Extremos colgantes : una interfaz, la mayoría de cuyos métodos no tienen sentido y están implementados por "dummy".
• Stub: un intento de "tirar" de una interfaz ya existente que es de poca utilidad para un objeto, en lugar de crear una nueva.

Antipatrones al escribir código

• Complejidad accidental : Agregar complejidad innecesaria a una solución.
• Acción a distancia Una interacción inesperada entre partes muy separadas de un sistema.
• Acumular y disparar: establece los parámetros de la subrutina en un conjunto de variables globales.
• Fe ciega : Verificación insuficiente de la corrección de la corrección del error o del resultado de la subrutina.
• Boat Anchor (Ancla de barco) [13] : Guardar una parte del sistema que ya no se usa.
• Giro ocupado, espera ocupada : consumo de recursos de CPU tiempo de procesador) mientras se espera un evento, generalmente mediante la repetición constante de la verificación, en lugar de usar programación asíncrona (por ejemplo, sistema de mensajes o eventos).
• Fallo de almacenamiento en caché : Olvidar restablecer el indicador de error después de manejarlo.
• El patrón del pañal apesta: restablezca el indicador de error sin manipularlo o pasarlo a un controlador ascendente.
• Comprobación de tipo en lugar de pertenencia, Comprobación de tipo en lugar de interfaz: Comprobación de que un objeto es de un tipo específico en un momento en que solo se requiere una interfaz específica.
• Impulso del código: sobrelimitar una parte de un sistema implicando constantemente su comportamiento en otras partes del sistema .
• Codificación por excepción : Adición de nuevo código para admitir cada caso especial reconocido.
• Código críptico : uso de abreviaturas en lugar de nombres nemotécnicos.
• Codificación dura : inyectar suposiciones sobre el entorno de un sistema en demasiados puntos de implementación.
• Codificación suave : un miedo patológico a la codificación dura que lleva a que todo se configure, mientras que la configuración del sistema en sí se convierte en programación.
• Flujo de lava 13] : Mantener el código no deseado (redundante o de baja calidad) porque es demasiado costoso eliminarlo o tendrá consecuencias impredecibles.
• Números mágicos : Usar constantes numéricas sin explicar su significado.
• Código procesal : Cuando otro paradigma es más apropiado.
• Código espagueti (a veces "pasta") [13] : código con un orden de ejecución demasiado confuso.
• Código de lasagnia (Código de lasagnia, o "cebolla" (cebolla)): Acoplamiento excesivo entre capas de abstracción, lo que lleva a la incapacidad de cambiar un nivel sin cambiar los demás.
• Código Ravioli (o "dumplings"): Los objetos están tan "pegados" entre sí que prácticamente no permiten la refactorización.
• Burbuja de jabón : un objeto inicializado con basura pretende contener algunos datos durante el mayor tiempo posible.
• Mutex hell: Inyectar demasiados objetos de sincronización entre subprocesos.
• Cáncer de (meta)plantillas: el uso generalizado de plantillas (principalmente C++), incluso cuando su uso no está justificado. Esto reduce la comprensión y el mantenimiento del código y ralentiza la compilación.

Antipatrones metodológicos

• Copiar y pegar programación [13] : Copiar (y modificar ligeramente) el código existente en lugar de crear soluciones genéricas.
• Desfactorización : El proceso de destruir la funcionalidad y reemplazarla con documentación.
• Martillo dorado [13] : Una fuerte creencia de que una solución favorita es universalmente aplicable. El nombre proviene del dicho “cuando sostienes un martillo, todos los problemas parecen clavos”.
• Factor de improbabilidad : La suposición de que es imposible que se active un error conocido.
• Optimización prematura : una optimización en la etapa de diseño de un segmento de código que lo hace más complejo o corrupto.
• Programación por permutación: Una aproximación al desarrollo de software con pequeños cambios.
• Reinventar la rueda [ 13] : construir desde cero en lugar de usar una buena solución lista para usar.
• Reinventar la rueda cuadrada : crear una mala solución, dado que ya existe una solución más conocida.
• Autodestrucción : un error fatal o un comportamiento no estándar del programa que conduce a una denegación de servicio, como resultado de otro error menos grave. Por ejemplo, cuando ocurre un error, la aplicación comienza a escribir en el registro muy rápidamente y escribe mucho en el registro, como resultado, el espacio del disco duro se agota más rápido de lo que detecta el monitoreo.
• Dos túneles : llevar la nueva funcionalidad a una aplicación separada en lugar de ampliar una existente. Se usa con mayor frecuencia cuando, por alguna razón (principalmente debido a la falta de tiempo o la falta de voluntad de la administración), realizar cambios en un código existente es más costoso que crear uno nuevo. En este caso, el cliente termina con dos aplicaciones que se ejecutan simultáneamente o alternativamente.
• Commit assassin : Hacer cambios individuales al sistema de control de versiones sin verificar su impacto en otras partes del programa. Como regla general, después de tales compromisos, el trabajo del equipo se paraliza mientras se solucionan problemas en lugares que antes funcionaban sin errores.

Antipatrones de gestión de configuración

• Infierno de dependencia ( también llamado " infierno de DLL " o "infierno de DLL" en la plataforma Microsoft Windows ): crecimiento del gráfico de dependencias mutuas de productos de software y bibliotecas, lo que genera la dificultad de instalar nuevos y eliminar los antiguos. En casos complejos, diferentes productos de software instalados requieren diferentes versiones de la misma biblioteca. En los casos más complejos, un producto puede requerir indirectamente dos versiones de la misma biblioteca a la vez.

Varios

• Humo y espejos [13] : una demostración de cómo se verían las funciones no escritas (el nombre proviene de dos formas favoritas en que los magos ocultan sus secretos).
• Inflación de software : Permitir que versiones sucesivas de un sistema requieran más y más recursos.
• Funciones de casilla de verificación : convertir un programa en un conglomerado de funciones mal implementadas y no relacionadas (generalmente para anunciar que la función está allí).

Antipatrones arquitectónicos

Problemas típicos asociados con la estructura del sistema [6] :

• Inversión de abstracción : ocultar una parte de la funcionalidad del uso externo, con la esperanza de que nadie la use.
• Punto de vista ambiguo [ 13] : Una representación de un modelo sin especificar su punto de vista.
• Gran bola de barro: Un sistema con una estructura irreconocible.
• Blob (Blob [13] ): ver objeto de Dios .
• Fábrica de gas : Complejidad de diseño opcional.
• Kludge de entrada [13] : Olvidar la especificación e implementación del soporte para una posible entrada no válida.
• Inflación de la interfaz: el desarrollo de la interfaz es muy poderoso y muy difícil de implementar.
• Pulsador mágico : realizar los resultados de las acciones del usuario en una interfaz inapropiada (no lo suficientemente abstracta). Por ejemplo, en sistemas como Delphi , esto es escribir la lógica de la aplicación en los controladores de clic de botón.
• Re -acoplamiento: El proceso de introducir una dependencia innecesaria .
• Chimenea (Stovepipe System [13] ): un conjunto de componentes mal acoplados que rara vez se apoya.
• Peligro de carrera (Condición de carrera): La falta de anticipación de la posibilidad de que los eventos ocurran en un orden diferente al esperado .
• Carrera de ratas : creación injustificada de muchas clases pequeñas y abstractas para resolver una tarea específica de un nivel superior.
• Mutilación : "afilar" innecesariamente un objeto para una determinada tarea muy limitada de tal manera que no podrá trabajar con ninguna otra tarea, aunque sea muy similar.
• Guardar o morir: guardar los cambios de configuración en el disco duro solo cuando finaliza la aplicación; lleva a que, en caso de fallo del programa, estos datos se pierdan

Anti-patrones organizacionales

Problemas que enfrentan los gerentes (o grupos de gerentes) [6] :

• Parálisis del análisis [13] : costos irrazonablemente altos para el análisis y el diseño. A menudo conduce al cierre del proyecto antes de que comience su implementación.
• Vaca de efectivo : si hay un producto que brinda beneficios sin una inversión significativa, no se invierten fondos en el desarrollo y desarrollo de nuevos productos.
• Obsolescencia continua 13] : dedicar una cantidad desproporcionada de esfuerzo a portar un sistema a nuevos entornos.
• Migración de costos : transferir los costos del proyecto a un departamento o socio comercial débil.
• Característica progresiva: agregar nuevas características a expensas de la calidad general del sistema.
• Elegancia inflada (elegancia progresiva): una mejora desproporcionada en la belleza del código en detrimento de la funcionalidad y la calidad general del sistema.
• Diseño por comité [13] : desarrollo de un proyecto sin control centralizado o sin liderazgo competente.
• Escalada de compromiso: implementando una decisión después de que se ha demostrado que es incorrecta.
• Te lo dije: ignorando la opinión de los expertos.
• Gestión por números: un énfasis excesivo en los números que están muy indirectamente relacionados con el sistema gestionado, son difíciles de obtener o están sujetos al efecto Goodhart .
• Medidas draconianas (Gestión por perkele): estilo de gestión irrazonablemente rígido.
• Manejo de hongos [ [13] : información insuficiente a los trabajadores sobre el trabajo realizado.
• del alcance : pérdida de control sobre el crecimiento del proyecto.
• Bloqueo de proveedor [13] : Bloqueo de proveedor.
• Warm Bodies [13] : Una persona cuya contribución al proyecto está en duda.
• Cabeza única de conocimiento (SHOK): cuando solo una persona en el equipo tiene información o habilidades vitales para el proyecto, y cuando se va, el trabajo se detiene.
• Caballero de brillante armadura (KISA): cuando un hombre aparece en escena tratando de arreglarlo todo sin decirle a nadie lo que hizo ni por qué.

Neil y LaPlante proporcionan los siguientes antipatrones [5] :

• Gerente ausente : el gerente es evasivo o invisible durante mucho tiempo; se esconde en algún lugar de la oficina o fuera de la oficina.
• Have only a hammer (All You Have Is A Hammer): control unidireccional, donde se utilizan las mismas técnicas sobre todos los subordinados y en todas las situaciones. A veces también llamado "One-Trick Pony".
• Wild Manager (Negociador de partidas de jaula): cualquier gerente que sea testarudo más allá de la razón y utilice un enfoque de gestión de "ganar a toda costa" o "yo tengo razón y tú estás equivocado". Suelen tener una taza de café con las Reglas de Gestión: “Regla #1: El jefe siempre tiene la razón. Regla n.º 2: si el jefe está equivocado, consulte la regla n.º 1".
• Doppelganger : un gerente o colega con el que es fácil o difícil trabajar.
• Aros infructuosos : les da a los gerentes más y más datos que necesitan para tomar una decisión, pero los gerentes nunca toman una decisión y continúan pidiéndole datos. No sabes por qué necesitan estos datos.
• Niño de Oro : El Niño de Oro ocurre cuando un gerente otorga una responsabilidad, oportunidad, reconocimiento o recompensa especial a un miembro de su equipo basado en una relación personal con él y a pesar de sus acciones reales. Todos están molestos por Golden Child, pero el verdadero problema radica en el gerente.
• Pollo sin cabeza : un gerente sin enfoque ni plan que nunca termina nada.
• Líder, no gerente: enfatiza la importancia de un liderazgo efectivo.
• Parrot Manager (Clonación Gerencial): Mandos intermedios que eventualmente comienzan a comportarse como sus jefes.
• Gerente no líder: este gerente es bueno en tareas administrativas y gerenciales, pero carece de capacidad de liderazgo.
• Abuso de métricas: uso indebido de métricas debido a incompetencia o manipulación deliberada de datos .
• Buen tipo: un gerente que se enfoca en ser amigo de todos termina decepcionando a todos y fallando en hacer su trabajo.
• Manejo de hongos : una situación en la que la gerencia no puede comunicarse de manera efectiva con el personal. Básicamente, la información se retiene intencionalmente para que todos sean "gordos, estúpidos y felices". El nombre está relacionado con una analogía: los champiñones se cultivan en la oscuridad y en estiércol.
• Plate Spinning: El gerente oculta su ineficiencia obligando a los trabajadores a realizar trabajos laboriosos e inútiles.
• Héroe del Proletariado : El gerente trata a sus subordinados como trabajadores ideales, pero esto es solo su muleta, utilizada para enmascarar la mala gestión. Es una forma de "motivación" del personal que le da a la gerencia una razón para aumentar los resultados esperados u obtener más por menos.
• Rising Upstart : superestrellas que no pueden perder el tiempo aprendiendo y encontrando su lugar. A veces puede ser por desconocimiento (no saben lo que no saben), ya veces puede ser por impaciencia (saben lo que los demás no saben). Tal advenedizo presenta un verdadero desafío para todos, excepto para los gerentes más experimentados.
• Road to Nowhere: La falta de un plan causa confusión y crisis de liderazgo.
• Ejecutivo cobarde : Cualquier gerente que no tiene el coraje para enfrentar la confrontación necesaria o manejar una situación difícil. En cambio, evita la confrontación o la situación por completo, o te pide que le des malas noticias.
• Caballero de tres cabezas : un gerente indeciso.
• Ultimate Weapon: el gerente anuncia que todos pueden confiar en empleados sobresalientes para que estos empleados se conviertan en el conducto para todo.
• Warm Bodies: Situación gerencial en la que un trabajador que apenas cumple con los requisitos mínimos se mueve de proyecto en proyecto o de equipo en equipo. A un trabajador débil se le llama "cuerpo tibio", aunque el verdadero problema radica en el gerente. Este antipatrón es lo opuesto a Starburst en términos de habilidad y potencial.

Antipatrones ambientales

Problemas causados ​​por la estructura dominante de la organización y el modelo social, que son el resultado de la política pública en la organización [15] [6] [5] [16] :

• Colonia de hormigas : bajo la belleza externa se encuentra la plantación de objetivos .[ aclarar ] .
• Atlas Shrugs ( Atlas Shrug ) - después de un éxito temporal, comienza el declive[ aclarar ] .
• Colectivo Autónomo - la autogestión conduce a la pasividad[ aclarar ] .
• Síndrome de la rana hervida ( Síndrome de la rana hervida ): se notan cambios negativos graduales cuando ya es demasiado tarde.
• Burning Bag of Dung : el gerente deja a los vecinos (subordinados, pupilos, sucesores) en una situación delicada.
• Fascinación por las palabras de moda ( Buzzword Mania ): la gerencia hace malabarismos con palabras que pocos de los pupilos entienden.
• Globo desinflado - Los mejores años de la empresa quedaron atrás, pero no puede darse cuenta de esto y reducir costos.
• Objetivos divergentes _ _[ aclarar ]
• Dogmática sobre la disfunción _
• Coraje inquebrantable ( Espíritu de Dunkerque )[ aclarar ]
• El nuevo vestido del rey ( Emperor's New Clothes ) - basado en el cuento de hadas del mismo nombre
• Doctrina de la equidad _ _[ aclarar ]
• Date prisa, haz reír a la gente ( Fools Rush In )[ aclarar ]
• Enfermedad del fundador ( Founderitis )[ aclarar ]
• Síndrome del camarero francés : un ambiente poco saludable en la empresa (opinión estadounidense estereotipada sobre los pequeños restaurantes franceses) .
• Novatadas ( Geek Hazing ): los principiantes están cargados de muchas tareas triviales que no les ayudan a aprender.
• Desconfianza Institucional _ _[ aclarar ]
• Ciudad de puestos ( Kiosk City ): cada departamento desarrolla su propio mecanismo de intercambio de información.
• Poder de Grey ( Mediocracia )
• Rey tuerto ( Rey tuerto )[ aclarar ]
• Orange Stand Economics es una mala estimación de costos.
• Isla Pitcairn ( Isla Pitcairn )[ aclarar ]
• Pueblos Potemkin
• Procesos en Conflicto ( Choque de Procesos )[ aclarar ]
• Cubo de Rubik _[ aclarar ]
• Niños sin zapatos ( Niños sin zapatos )[ aclarar ]
• Becerro de Oro ( Adorando al Becerro de Oro )[ aclarar ]

Véase también

• Lista de sesgos cognitivos
• Categoría:Antipatrones

Notas

1. ↑ Budgen, D. Diseño de software. - Addison-Wesley, 2003. - ISBN 0-201-72219-4 .
2. ↑ Marrón, 1998 , Capítulo 2.
3. ↑ Universidad de Smith, 2000 .
4. ↑ http://c2.com/cgi/wiki?AntiPattern . Cunningham & Cunningham Inc. . Consultado el 15 de febrero de 2006. Archivado desde el original el 3 de abril de 2005. (indefinido)
5. ↑ 1 2 3 Neill, Laplante, 2005 .
6. ↑ 1 2 3 4 5 6 Settas, 2011 .
7. ↑ Miroslav Kis. Antipatrones de seguridad de la información en ingeniería de requisitos de software. En Actas de la 9.ª Conferencia sobre lenguaje de patrones de programas (Plop), 2002.
8. ↑ John Long. Antipatrones de reutilización de software. En ACM SIGSOFT Software Engineering Notes, volumen 26, página 4, julio de 2001.
9. ↑ Paula Kotze, Karen Renaud y Judy van Biljona. No haga esto: trampas en el uso de anti-patrones en la enseñanza de los principios de interacción humano-computadora. Informática y Educación, 50(3):979-1008, abril de 2008
10. ↑ J. Krai y M. Zemlicka. Los antipatrones orientados a servicios más importantes. En actas de la Conferencia Internacional sobre Avances en Ingeniería de Software (ICSEA), 2007.
11. ↑ P. A. Laplante, R. R. Hoffman y G. Klein. Antipatrones en la creación de sistemas inteligentes. Sistemas inteligentes IEEE, 22:91-95, 2007.
12. ↑ 1 2 Rajiv Ramnath, Cheyney Loffing. Comenzando con la programación de iOS para tontos . — John Wiley & Sons, 2014-04-14. - S. 105. - 470 pág. — ISBN 9781118799277 . Archivado el 23 de julio de 2016 en Wayback Machine .
13. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 William J. Brown. Antipatrones: refactorización de software, arquitecturas y proyectos en crisis . — Wiley, 1998-04-03. — 156 págs. — ISBN 0-471-19713-0. Archivado el 22 de diciembre de 2015 en Wayback Machine .
14. ↑ Gary McLean Hall. Código adaptativo a través de C#: Codificación ágil con patrones de diseño y principios SOLID. - Microsoft Press, 2014. - S. 267-268. — ISBN 978-0735683204 .
15. ↑ Original: fuerzas sociopolíticas
16. ↑ Phillip Laplante The Burning Bag of Dung—and Other Environmental Antipatterns Archivado el 19 de septiembre de 2015 en Wayback Machine ACM Queue 30 de noviembre de 2004 Volumen 2, número 7

Literatura

• Libro de patrones de diseño de Perl|Patrones de diseño de Perl  - Un libro en línea gratuito y wiki
• William J. Brown, Raphael C. Malveau, Hays W. McCormick III y Thomas J. Mowbray. Antipatrones: refactorización de software, arquitecturas y proyectos en crisis . - John Wiley & Sons, 1998. - ISBN 0471197130 .
• William J. Brown, Hays W. "Skip" McCormick, Scott W. Thomas. Antipatrones y patrones en la gestión de la configuración del software . - Wiley, 1999. - ISBN 978-0-471-32929-9 .
• William J. Brown, Hays W. "Skip" McCormick, Scott W. Thomas. Antipatrones en la gestión de proyectos. - Wiley, 2000. - ISBN 978-0-471-36366-8 .
• Neal Ford, Matthew McCullough, Nathaniel Schutta. Patrones de presentación: técnicas para elaborar mejores presentaciones . — Addison-Wesley, 2012-08-15. — 395 pág. — ISBN 9780132963374 .
• Chad Pytel, Tammer Saleh. Rails AntiPatterns: mejores prácticas de refactorización de Ruby on Rails . — Addison-Wesley Profesional, 2010-11-09. — 347 pág. — ISBN 9780132660068 .
• Neill, Colin J. 9.1.2 Antipatrones en ingeniería de sistemas: un trío de apertura  //  Simposio internacional INCOSE. - 2012. - vol. 22 , núm. 1 . - P. 1233-1245 . — ISSN 2334-5837 .
• Colin J. Neill, Philip A. Laplante. Antipatrones: identificación, refactorización y gestión. - CRC Press, 2005. - ISBN 978-1-4200-3124-9 .
• Dimitrios Settas. Proyecto de software de gestión del conocimiento antipatrones (tesis doctoral). - Salónica, Grecia: Universidad Aristóteles, 2011.
• Allen E. Errores típicos de diseño. - Editorial "Pedro", 2003. - 224 p. — ISBN 5-887827-304-6 .
• Smith CU, Williams LG Software Performance AntiPatterns  //  2.º Taller internacional sobre software y rendimiento. — 2000.

Enlaces

• Tutorial sobre anti-patrones
• Catálogo antipatrones
• Peor que el fracaso
• FuenteMarcado
• Traducción del artículo "Resign Patterns" - Design Disorient Design Breaks  - una parodia del libro "Gangs of Four"
• Libro de patrones de diseño de Perl
• El patrón del pañal apesta
• Una gran lista de antipatrones en ruso.