Anti-patrón

Un antipatrón en ingeniería de software, gestión de proyectos y procesos comerciales es una respuesta común a un problema recurrente que generalmente es ineficaz y corre el riesgo de ser altamente contraproducente. El término, acuñado en 1995 por el programador de computadoras 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 primero publicado en su artículo en el Journal of Object-Oriented Programming. Otro artículo de 1996 presentado por Michael Ackroyd en la Object World West Conference también documentó antipatrones.

Sin embargo, fue el libro de 1998 AntiPatterns 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. Otros autores lo han ampliado más desde entonces para abarcar antipatrones ambientales/organizacionales/culturales.

Definición

Según los autores de Patrones de diseño, 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 comúnmente utilizado, estructura o patrón de acción que, a pesar de que inicialmente parece ser una respuesta adecuada y efectiva a un problema, tiene más consecuencias malas que las buenas.
2. Otra solución existe al problema que el antipattern está tratando de abordar. Esta solución está documentada, repetible y demostrada ser efectiva cuando el antipatrón no es.

Una guía de lo que se usa comúnmente es una "regla de tres" similar al de los patrones: para ser un anti-patrón debe haber sido presenciado al menos tres veces.

Usos

Documentar los antipatrones puede ser una forma efectiva de analizar un espacio problemático y capturar el conocimiento experto.

Mientras que algunas descripciones antipatrón simplemente documentan las consecuencias adversas del patrón, una buena documentación antipatrón también proporciona una alternativa o un medio para mejorar el antipatrón.

Antipatrones de ingeniería de software

En ingeniería de software, los antipatrones incluyen la gran bola de barro (falta de) diseño; God Class (donde una sola clase maneja todo el control en un programa en lugar de que el control se distribuya entre varias clases); y Poltergeists (clases de controlador efímeras que solo existen para invocar otros métodos en las clases).

Gran bola de barro

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, tales 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 Mud es una jungla estructurada, espeluznante, descuidada, duct-tape-and-baling-wire, espagueti-código. Estos sistemas muestran signos inconfundibles de crecimiento no regulado y reparación reiterada y oportuna. 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 duplicada.

La estructura general del sistema tal vez nunca haya sido bien definida.

Si lo fuera, podría haber erosionado más allá del reconocimiento. Los programadores con un fragmento de sensibilidad arquitectónica arrojaron estos quagmires. Sólo aquellos que no tienen conocimiento de la arquitectura, y, tal vez, se sienten cómodos con la inercia de la tarea cotidiana de parchear los agujeros en estos falsos diques, están contentos de trabajar en tales sistemas.

—Brian Foote y Joseph Yoder, Gran Bola de Mud. Cuarta Conferencia sobre Patrones Idiomas de Programas (PLoP '97/EuroPLoP '97) Monticello, Illinois, septiembre de 1997

Foote y Yoder han acreditado a Brian Marick como el creador de la 'gran bola de barro' término para este tipo de arquitectura.

Antipatrones de gestión de proyectos

Los antipatrones de gestión de proyectos incluidos en el libro Antipatterns incluyen Blowhard Jamboree (un exceso de expertos de la industria), parálisis de análisis, Viewgraph Engineering (demasiado tiempo dedicado a hacer presentaciones y no lo suficiente en el software real), Death by Planning (de manera similar, demasiada planificación), Fear of Success (temores irracionales cerca de la finalización del proyecto), The Corncob (dificultades con las personas), Intellectual Violence (intimidación mediante el uso de jerga o tecnología arcana), Irrational Management (mala hábitos de gestión), Smoke and Mirrors (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 que los compren), Fire Drill (largos períodos de monotonía puntuados por breves crisis), The Feud (conflictos entre directivos), y e-mail Is Dangerous (situaciones derivadas de mensajes de correo electrónico desaconsejados).