Un antipatrón en ingeniería de software , gestión de proyectos y procesos de negocio 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] Otro artículo presentado en 1996 por Michael Ackroyd en la Conferencia Object World West también documentó antipatrones. [3]
Sin embargo, fue el libro AntiPatterns de 1998 el que popularizó la idea y amplió 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 lo han ampliado 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 de un antipatrón que lo distinguen de un mal hábito, una mala práctica o una mala idea:
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 problemático y capturar conocimiento experto. [6]
Si bien algunas descripciones de antipatrón simplemente documentan las consecuencias adversas del patrón, una buena documentación del antipatrón 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, la Clase Dios (donde una sola clase maneja todo el control en un programa en lugar de que el control se distribuya entre múltiples clases), números mágicos (valores únicos con un significado inexplicable o apariciones múltiples que podrían reemplazarse con una constante con nombre) y Poltergeists (clases de controlador efímeras que solo existen para invocar otros métodos en las clases). [7]
Esto indica un sistema de software que carece de una arquitectura perceptible. Aunque no son deseables 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 homónimo de 1997 de Brian Foote y Joseph Yoder, que define el término:
A Big Ball of Mud es una jungla de código espagueti desordenadamente estructurada, extensa, descuidada, con cinta adhesiva y alambre para embalar . Estos sistemas muestran signos inequívocos de crecimiento descontrolado y de reparaciones oportunas y repetidas. La información se comparte promiscuamente entre elementos distantes del sistema, a menudo hasta el punto en que casi toda la información importante se vuelve global o se duplica.
Es posible que la estructura general del sistema nunca haya estado bien definida.
Si lo fuera, es posible que se hubiera erosionado hasta quedar irreconocible. Los programadores con una pizca de sensibilidad arquitectónica evitan estos atolladeros. Sólo aquellos que no se preocupan por la arquitectura y, tal vez, se sienten cómodos con la inercia de la tarea diaria de tapar los agujeros de estos diques defectuosos, se contentan con trabajar en tales sistemas.
— Brian Foote y Joseph Yoder, Gran bola de barro. Cuarta Conferencia sobre patrones de lenguajes de programas (PLoP '97/EuroPLoP '97) Monticello, Illinois, septiembre de 1997
Foote y Yoder han acreditado a Brian Marick como el creador del término "gran bola de barro" para este tipo de arquitectura. [8]
Los antipatrones de gestión de proyectos incluidos en el libro Antipatterns incluyen Blowhard Jamboree (un exceso de expertos de la industria), parálisis del análisis , Viewgraph Engineering (demasiado tiempo dedicado a hacer presentaciones y poco al software real), Death by Planning (de manera similar, demasiado planificación), Miedo al éxito (miedos irracionales cerca de la finalización del proyecto), La mazorca (dificultades con las personas), 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 aceptación), Fire Drill (largos períodos de monotonía interrumpidos por crisis breves), The Feud (conflictos entre gerentes) y e -mail Is Dangerous (situaciones resultantes de mensajes de correo electrónico desacertados). [4]
Como lo describe Long (2001), los antipatrones de diseño son "soluciones obvias, pero erróneas, a problemas recurrentes".
...enfoques comunes para resolver problemas recurrentes que resultan ineficaces. Estos enfoques se denominan antipatrones.
Un antipatrón es como un patrón, excepto que en lugar de una solución proporciona algo que superficialmente parece una solución, pero no lo es.
