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:
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:
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.
parece una solución, pero no lo es.
