Anti-patrón

Un antipatrón en ingeniería de software , gestión de proyectos y procesos de negocios es una respuesta común a un problema recurrente que suele ser ineficaz y corre el riesgo de ser altamente contraproducente. ^{[1] [2]} El término, acuñado en 1995 por el programador informático Andrew Koenig , se inspiró en el libro Design Patterns (que destaca una serie de patrones de diseño en el desarrollo de software que sus autores consideraron altamente confiables y efectivos) y se publicó por primera vez en su artículo en el Journal of Object-Oriented Programming . ^[3] Un artículo adicional en 1996 presentado por Michael Ackroyd en la Object World West Conference también documentó antipatrones. ^[3]

Sin embargo, fue el libro AntiPatterns de 1998 el que popularizó la idea y extendió su alcance más allá del campo del diseño de software para incluir la arquitectura de software y la gestión de proyectos. ^[3] Otros autores la han extendido aún más desde entonces para abarcar antipatrones ambientales, organizacionales y culturales. ^[4]

Según los autores de Design Patterns , hay dos elementos clave en un antipatrón que lo distinguen de un mal hábito, una mala práctica o una mala idea:

1. El antipatrón es un proceso, estructura o patrón de acción comúnmente utilizado que, a pesar de parecer inicialmente una respuesta apropiada y efectiva a un problema, tiene más consecuencias malas que buenas.
2. Existe otra solución al problema que el antipatrón intenta resolver. Esta solución está documentada, es repetible y se ha demostrado que es eficaz cuando el antipatrón no lo es.

Una guía de lo que se usa comúnmente es una "regla de tres" similar a la de los patrones: para ser un antipatrón, debe haber sido presenciado al menos tres veces. ^[5]

Documentar antipatrones puede ser una forma eficaz de analizar un espacio de problemas y capturar el conocimiento de expertos. ^[6]

Si bien algunas descripciones de antipatrones simplemente documentan las consecuencias adversas del patrón, una buena documentación de antipatrones también proporciona una alternativa o un medio para mejorar el antipatrón. ^[7]

En ingeniería de software, los antipatrones incluyen la gran bola de barro (falta de) diseño, el objeto dios (donde una sola clase maneja todo el control en un programa en lugar de que el control se distribuya entre múltiples clases), los números mágicos (valores únicos con un significado inexplicable o múltiples ocurrencias que podrían reemplazarse con una constante nombrada) y los poltergeists (clases de controlador efímeras que solo existen para invocar otros métodos en las clases). ^[7]

Esto indica que el sistema de software carece de una arquitectura perceptible. Aunque no es deseable desde el punto de vista de la ingeniería de software, estos sistemas son comunes en la práctica debido a las presiones comerciales, la rotación de desarrolladores y la entropía del código .

El término se popularizó en el artículo de 1997 de Brian Foote y Joseph Yoder del mismo nombre, que define el término:

Una gran bola de barro es una jungla de códigos desordenados, extensa, desordenada y llena de cinta adhesiva y alambre de embalar . Estos sistemas muestran signos inequívocos de crecimiento descontrolado y de reparaciones repetidas y oportunas. La información se comparte de forma promiscua entre elementos distantes del sistema, a menudo hasta el punto en que casi toda la información importante se vuelve global o duplicada.

Es posible que la estructura general del sistema nunca haya estado bien definida.

Si así fuera, es posible que se haya erosionado hasta el punto de no ser reconocible. Los programadores con un mínimo de sensibilidad arquitectónica evitan estos atolladeros. Sólo aquellos a quienes no les preocupa la arquitectura y, tal vez, se sienten cómodos con la inercia de la tarea cotidiana de tapar los agujeros de estos diques defectuosos, se conforman con trabajar en esos sistemas.

—  Brian Foote y Joseph Yoder, Big Ball of Mud. Cuarta Conferencia sobre lenguajes de patrones de programas (PLoP '97/EuroPLoP '97) Monticello, Illinois, septiembre de 1997

Foote y Yoder han atribuido a Brian Marick la creación del término "gran bola de barro" para este tipo de arquitectura. ^[8]

Los antipatrones de gestión de proyectos incluidos en el libro Antipatrones incluyen:

• Blowhard Jamboree (un exceso de expertos de la industria)
• Parálisis por análisis
• Ingeniería de Viewgraph (se dedica demasiado tiempo a hacer presentaciones y no lo suficiente al software en sí)
• Muerte por planificación (de manera similar, demasiada planificación)
• Miedo al éxito (miedos irracionales ante la proximidad de la finalización del proyecto)
• La Mazorca de Maíz (dificultades con la gente)
• Violencia intelectual (intimidación mediante el uso de jerga o tecnología arcana)
• Gestión irracional (malos hábitos de gestión)
• Humo y espejos (uso excesivo de demostraciones y prototipos por parte de los vendedores)
• Throw It Over the Wall (imponer prácticas de ingeniería de software de moda a los desarrolladores sin su aceptación)
• Simulacro de incendio (largos períodos de monotonía interrumpidos por breves crisis)
• La disputa (conflictos entre directivos)
• El correo electrónico es peligroso (situaciones resultantes de mensajes de correo electrónico mal aconsejados). ^[4]

• Olor a código  : característica de la programación informática
• Olor a diseño  : término en programación informática
• Patrón oscuro  : diseños de interfaz de usuario engañosos
• Lista de filosofías de desarrollo de software
• Lista de herramientas para el análisis de código estático
• Podredumbre del software  : proceso de deterioro del software
• Principio de Peter del software  : término de ingeniería que designa un proyecto complejo y fallido
• Modelo de inmadurez de capacidades
• ISO/IEC 29110 : Perfiles de ciclo de vida del software y directrices para entidades muy pequeñas (VSE)
• El dilema del innovador  – libro de Clayton M. Christensen, 1997

• Koenig, Andrew (marzo-abril de 1995). "Patrones y antipatrones". Revista de programación orientada a objetos . 8 (1): 46–48.
  • Reimpreso posteriormente en: Rising, Linda (1998). The patterns handbook: technique, strategies, and applications. Cambridge, Reino Unido: Cambridge University Press. p. 387. ISBN 0-521-64818-1Un antipatrón es como un patrón, excepto que en lugar de una solución da algo que superficialmente parece una solución, pero no lo es.
• Laplante, Phillip A.; Neill, Colin J. (2005). Antipatrones: identificación, refactorización y gestión . Auerbach Publications. ISBN 0-8493-2994-9.
• Brown, William J.; Malveau, Raphael C.; McCormick, Hays W.; Thomas, Scott W. (2000). Hudson, Theresa Hudson (ed.). Antipatrones en la gestión de proyectos . John Wiley & Sons . ISBN 0-471-36366-9.
• Stamelos, Ioannis (enero de 2010). "Antipatrones en la gestión de proyectos de software". Journal of Systems and Software . 83 (1): 52–59. doi :10.1016/j.jss.2009.09.016.

• Antipatrón en WikiWikiWeb