Anti-patrones: ejemplos bien documentados de malas soluciones para diseñar un pésimo sistema de software.

Desarrollar un nuevo software no es tarea fácil por muy simple que sean las funcionalidades solicitadas, hay muchas etapas a seguir y muchas cosas pueden salir mal, en especial si se parte de una mala conceptualización.

Esto es lo que hace un anti-patrón.

Los anti-patrones surgen principalmente de la falta de experiencia o conocimiento, no seguir los estándares, falta de documentación, de ser subjetivo a la hora de escoger una solución efectiva. Se estudian a fin de poderlos evitar en el futuro, y en su caso, para que su presencia pueda ser reconocida fácilmente.

Un anti-patrón de diseño software es un patrón de diseño que invariablemente conduce a una mala solución para un problema.

De una forma análoga podríamos decir por ejemplo, que si una persona no cae en el anti-patrón «estereotipo» criminal, terrorista, estafador, dictador, y similares, entonces podríamos afirmar que no es una mala persona. Lo cual no implica, que sea una buena; para serlo debería no sólo no encajar en los anti-patrones mencionados, sino además, cumplir con uno o más patrones «cualidades» tales como ser honesto, trabajador, responsable, etc.

En la elaboración de un sistema, intervienen al menos, diversos actores: arquitectos de software, administradores de proyecto y desarrolladores. Para cada uno de ellos, existen anti-patrones que describen comportamientos y soluciones incorrectas Los anti-patrones (una vez conocidos) constituyen para cada uno de los actores involucrados, descripciones de problemas recurrentes en la construcción de software, les proporcionan un vocabulario común para identificar problemas y discutir posibles soluciones y les sugieren pasos para la re-ingeniería, y re-organización estructural de un sistema.

Los anti-patrones los podemos agrupar de la siguiente manera:

Anti-patrones de Administración de Proyecto

• Software bloat: Es también conocido como el “súper equipo de programadores”. Consiste en la creencia de que asignar más personal a un proyecto, acotará el tiempo de entrega. Regularmente como una forma desesperada de intentar corregir retraso del proyecto.
• Smoke and mirrors: Ocurre cuando el equipo se compromete a cumplir expectativas del cliente que escapan las capacidades tecnológicas de la organización. Es importante la correcta administración de las expectativas del cliente.
• Corncob: Los empleados se obstaculizan unos a otros. Personas conflictivas o difíciles de tratar que forman parte del equipo de desarrollo, desvían u obstaculizan el proceso de producción, porque transfieren sus problemas personales o diferencias, con otros miembros del equipo al proyecto.
• Bad management: Gestionar un proyecto sin tener suficientes conocimientos sobre la materia. El proyecto se descuida y no se monitorea de manera adecuada, es muy difícil de detectar en etapas iniciales, pero repentinamente emerge de golpe y suele voltear de cabeza la situación del proyecto. Se manifiesta con retrasos en las fechas de entrega y/o áreas incompletas.
• Absentee manager: Situación en la que el principal responsable o coordinador se ausenta o permanece en paradero desconocido o no localizable durante importantes períodos de tiempo.
• All you have is a hammer: Gestión gris y plana, incapaz de tratar a los subordinados de manera personalizada y acorde con sus necesidades particulares.
• Fruitless hoops: Gestor o coordinador que solicita grandes cantidades de datos (en ocasiones sin relevancia alguna) antes de tomar una decisión.
• Golden child: Situación en la que ciertas responsabilidades, oportunidades, reconocimientos o recompensas van a parar a un determinado miembro del equipo como consecuencia de una relación personal o en clara contradicción con su rendimiento real.
• Headless chicken: Se aplica al gestor, coordinador o responsable que vive en una permanente situación de pánico y medidas desesperadas.
• Metric abuse: Utilización manipuladora o incompetente de las medidas y las métricas.
• Mr. Nice Guy: Se aplica al gestor que pretende convertirse en amigo de todos.
• Spineless executive: Gestor, coordinador o responsable que no tiene el coraje de enfrentarse a las situaciones, asumir las responsabilidades de los errores, o dar la cara por sus subordinados.

Anti-patrones de Diseño de Software

• The God: Un objeto omnipresente y desconocido. Todo sistema donde una sola clase ó modulo (la función main o equivalente) hace toda la funcionalidad. En consecuencia, tenemos un código desorganizado y fuertemente acoplado a dependencias.
• Golden Hammer: Conocida también como la vara mágica. Es un vicio relacionado con aferrarse a un solo paradigma, para solucionar todos los problemas que se nos presentan al desarrollar software, como por ejemplo, siempre querer usar el mismo lenguaje de programación para todos los desarrollos, sea o no conveniente. Lo cual conlleva frecuentemente a consumir mucho más esfuerzo para resolver un problema.
• Lava Flow: Tal como lo indica su nombre “programar al estilo volcán”. Es construir grandes cantidades de código de manera desordenada, con poca documentación y poca claridad de su función en el sistema. Conforme el sistema avanza en su desarrollo, y crece, se dice que estos flujos de lava se solidifican, es decir, se vuelve mucho más complicado corregir los problemas que originan, y el desorden va creciendo geométricamente.
• Spaghetti Code: Son todos aquellos fragmentos código no documentado, donde cualquier pequeña variación provoca un cambio estructural completo del sistema. Si se quiere ir al extremo de manera coloquial seria como codificar con los “pies”. A diferencia del estilo volcán, donde la crítica es a la forma en que el sistema crece (se anexan módulos), aquí la crítica es a la forma en que se escribe cada una de las líneas, desde la indentación hasta el lenguaje o lenguajes utilizados y su integración. El spaghetti es causa directa del síndrome del programador desesperado. Pero si para colmo, tenemos sólo un chef, o en el contexto un “Programador Solitario”. ¿Quién era ese hombre tras el monitor? Que no está ya disponible para explicarnos su receta. Simplemente se tienen problemas, muchos problemas.
• Poltergeist: Son diseños no dimensionados correctamente, es decir se tienen demasiadas clases en un programa o tablas en una base de datos. También puede ser clases o tablas con mínimas responsabilidades. Muchas veces se utiliza para disfrazar la presencia del anti-patrón The God. Se colocan clases inútiles, que disfrazan el hecho que todo el sistema se encuentra construido en uno, o unos cuantos archivos, módulos o clases. Este anti-patrón sugiere un modelo de análisis y/o diseño inestable: el diseño no coincide con la implementación, y por ello es imposible hacer extensiones al sistema, porque entre tanto “fantasma”, encontrar los elementos relevantes es imposible.
• Input kludge: No especificar e implementar el manejo de entradas inválidas.
• Sequential coupling: Construir una clase que necesita que sus métodos se invoquen en un orden determinado.
• Heroic naming: Identificar los componentes de un programa (interfaces, clases, propiedades, métodos…) con nombres que provocan aparente una estandarización con la ingeniería del software pero que en realidad oculta una implementación anárquica.
• Boat anchor: Retener partes del sistema que ya no tienen utilidad.
• Hard code: Hacer supuestos sobre el comportamiento del sistema en su estructura o secuencia de implementación, por ejemplo: flujos estáticos e invariables debido a falta de previsión sobre elementos que puedan variar en el futuro.
• Blind faith: Despreocuparse de la comprobación de los resultados que produce una subrutina, o bien de la efectividad de un parche o solución a un problema.
• Exception handling: Emplear mecanismos de manejo de excepciones del lenguaje para implementar la lógica general del programa. Por otro lado, también es un problema común introducir condiciones para evitar que se produzcan excepciones en tiempo de ejecución, lanzando una excepción si dicha condición falla.
• Packratting: Consumir recursos de memoria en exceso debido a no liberar objetos reservados dinámicamente una vez que ya han dejado de ser utilizados.

Anti-patrones de Arquitectura

• Stovepipe: También conocido como “cocinado en caliente”. Es la forma breve de referirse a la creación de islas dentro de la misma empresa (cada departamento crea su propio subdepartamento de sistemas). “Islas” independientes, y en conflicto unas con otras. Cada isla desarrolla la parte del sistema que necesita para satisfacer sus requerimientos, sin preocuparse por el resto (no existe una buena gestión), el escenario resultante implica una pobre o nula interoperabilidad, obviamente, no existe la reutilización y, consecuentemente se incrementan costos. Contrario a lo que se podría suponer, cada vez es más común este tipo de acciones, dada la premura de varios departamentos de la empresa, por contar con un entregable en el menor tiempo posible.

• Casarse con el diablo: Crear una dependencia fuerte hacia un fabricante o proveedor para obtener una solución. El problema es inminente: se depende completamente de un ente externo, la calidad de los productos se comprometen, al ser una dependencia fuerte estamos propensos a sus excusas, justificaciones y ritmo de trabajo.

• Reinventing the wheel: Se refiere a reimplementar componentes que ya existen o cuya funcionalidad es similar. Por lo general, es consecuencia del poco conocimiento de la organización o trabajo ya existente por parte del arquitecto, lo que conlleva a buscar soluciones para problemas ya solucionados.

• Architecture as requirement: Imponer que el diseño considere, obligatoriamente, el uso de herramientas o métodos no necesariamente idóneos.
• Bear trap: Invertir mucho en una herramienta poco adaptada o factible, de manera que después es imposible deshacerse de ella.
  

Anti-patrones Organizacionales

• Scope creep: Permitir que el alcance de un proyecto crezca sin el control adecuado.
• Design by committee: Contar con muchas opiniones sobre un diseño, pero adolecer de falta de una visión unificada.
• Escalation of commitment: No ser capaz de revocar una decisión a la vista de que no ha sido acertada.
• Mushroom management: Tratar a los empleados sin miramientos, sin informarles de las decisiones que les afectan (manteniéndolos cubiertos y en la oscuridad, como los champiñones).
• Management by perkele: Aplicar una gestión autoritaria con tolerancia nula ante las disensiones.
• Cost migration: Trasladar los gastos de un proyecto a un departamento o socio de negocio vulnerable.
• Continuous obsolescence: Destinar desproporcionados esfuerzos a adaptar un sistema a nuevos entornos.
• Violin string organization: Mantener una organización afinada y en buen estado, pero sin ninguna flexibilidad.
• Analysis paralysis: Dedicar esfuerzos desproporcionados a la fase de análisis de un proyecto, eternizando el proceso de diseño iterando sobre la búsqueda de mejores soluciones o variantes.
• I told you so: Permitir que la atención se centre en que la desoída advertencia de un experto se ha demostrado justificada.
• Cash cow: Pecar de autocomplacencia frente a nuevos productos por disponer de un producto legacy muy lucrativo.

Anti-patrones de Configuración

• Extension conflict: Problemas con diferentes extensiones que tratan de gestionar las mismas partes del sistema (específico de Mac OS).
• Dependency hell: Escenario de problemas producidos por las versiones de otros productos que se necesitan para hacer funcionar un tercero.
  • DLL hell: Problemas con las versiones, disponibilidad o proliferación de DLLs (específico de Microsoft Windows)
  • JAR hell: Problemas con diferentes versiones o ubicaciones de ficheros JAR (Java), típicamente causados por la falta de comprensión del modelo de carga de clases.

Conclusiones

La idea no es tanto decir “no hagas esto” sino “tal vez no sepas que haces esto…, pero no funciona”.

Algunos de estos patrones, son tan risibles que se puede suponer que nadie podría cometerlos, y sin embargo, muchos de nosotros, estudiantes, profesionales, especialistas, hemos caído en al menos uno de ellos. Por lo que conocerlos nos ayuda a identificar de forma oportuna problemas o consecuencias futuras.

Es importante reflexionar que la tecnología avanza en un rumbo tan acelerado que las mejores prácticas de esta época, pueden evolucionar y convertirse en anti-patrones en un futuro próximo.

La programación estructural podría ser un ejemplo futuro, en cierto contexto: “solución sencilla y rápida con consecuencias negativas a largo plazo”.

Referencias

1. William J. Brown. Ed. John Wiley & Sons, 2000. Antipatterns in Project Management. ISBN: 0471363669
2. Bill Dudney, Stephen Asbury, Joseph Krozak, and Kevin Wittkopf. Ed. John Wiley & Sons, 2003. J2EE AntiPatterns. ISBN: 0471146153.
3. William J. Brown. Ed. John Wiley & Sons, 1998. Antipatterns: Refactoring Software, Architectures, and Projects in Crisis. ISBN: 0471197130.
4. Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2.

5. Junta de Andalucía. (2014). Especificación de los Anti patrones de diseño de Arquitectura de Software. Recuperado el 12 de Octubre de 2014, de Junta de Andalucía: http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/820