Los antipatrones (antipatterns) son descripciones de situaciones o soluciones, recurrentes que producen consecuencias negativas. Un antipatrón puede ser el resultado de una decisión equivocada sobre cómo resolver un determinado problema, o bien, la aplicación correcta de un patrón de diseño en el contexto equivocado.
En la actualidad vemos con mucha frecuencia la presencia de situaciones un tanto abrumadoras para la persona que está construyendo software. Sin embargo, esto no quiere decir que el programador pierda su cabeza, como buenos solucionadores de problemas tendemos a activar la chispa creativa, que algunas veces puede ir en nuestra contra si no usamos correctamente las herramientas generando con esto consecuencias negativas para nuestros proyectos.
Los antipatrones existen por muchas razones. Sin embargo, no solo se debe analizar por qué existen, sino también detenerse a pensar por qué estos persisten y se propagan. Brown et al (1998) sostienen que los antipatrones son el lado oscuro de los patrones de diseño, ya que muchas de las veces que se implementan soluciones basadas en patrones no se evalúa que tan aplicables son para el problema que se está intentando resolver. A su vez, muchos desarrolladores conocedores de patrones de diseño tienden a clasificar todo como capaz de ser resuelto con patrones de diseño, previo a haber finalizado el análisis completo del problema. La presencia y perduración de Antipatrones significa una cosa: se están haciendo cosas de forma incorrecta, y cuando esto ocurre es porque no se está tomando la debida responsabilidad en el trabajo.
Al igual que en los patrones de diseño, los antipatrones también deben documentarse y compartir esta información con los demás desarrolladores con la finalidad de que no vuelva a ser usado, y así evitar la propagación de estas malas prácticas. Es importante aclarar que los antipatrones en muchas ocasiones se ven influenciados por múltiples causas como por ejemplo errores recurrentes presentes en el desarrollo de software, exceso de costos, atrasos de acuerdo a lo planificado u objetivos de negocio no cumplidos.
Algunos de los antipatrones con los que nos encontramos con frecuencia son:
The Blob
The Blob, God Class o Winnebago es una clase, o componente, que conoce o hace demasiado, aparece en aquellos diseños donde una clase monopoliza la mayoría del comportamiento del sistema, mientras que el resto de las clases solo encapsulan
información.
Golden Hammer
Este antipatrón se refiere al uso de una tecnología, patrón, arquitectura etc. Para cualquier problema o situación incluso cuando es evidente que no va a ser útil.
Spaghetti Code
Este es el más clásico y famoso antipatrón, el cual pasó de los lenguajes no orientados a objetos. Este antipatrón se manifiesta como un sistema con poca estructura donde los cambios y futuras extensiones se tornan difíciles por haber perdido claridad en el código, incluso para el autor del mismo. Cuando el sistema está desarrollado en un lenguaje orientado a objetos, este suele incluir pocos objetos con métodos cuyas implementaciones suelen ser extensas y terminan invocando a un solo flujo.
Copy-And-Paste Programming
Este antipatrón se basa en la idea de que es más fácil modificar código preexistente que programar desde el comienzo. Se caracteriza por la presencia de fragmentos similares de código diseminados por todo el sistema, que suelen ser modificaciones de otros ya existentes realizadas por desarrolladores poco experimentados. Estos desarrolladores aprenden mediante la modificación de ejemplos producidos por desarrolladores más experimentados. Más aún, es más fácil extender este código, ya que el desarrollador tiene control absoluto sobre él, y puede modificarlo para complementar modificaciones a corto plazo de manera tal, de satisfacer nuevos requerimientos.
La existencia de estos antipatrones ocasiona grandes problemas para el proyecto. Hace que se crezca esa bola de nieve imposible de refactorizar y de mantener por el excesivo tiempo que se debe gastar en entenderlo y por ende, aparece el término “es mejor reescribirlo”. Proyectos con metodologías Ágiles tienen un reto mayor a la hora de su construcción, ya que algunos desarrolladores tienden a interpretar de forma equivocada la palabra velocidad. Cuando existe una mala estimación se tiende a terminar las funcionalidades a como dé lugar. Debemos tener presente que la única forma de avanzar más rápido es avanzar bien.
