Autor en Google+
Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET, ASP.NET Core, MVC, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

10 años online 🎂

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET, ASP.NET Core, MVC, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
miércoles, 27 de febrero de 2008
Bonito plato de spaghettiSabemos que los patrones son plantillas reutilizables que podemos usar para solucionar problemas habituales en el proceso de desarrollo de software. Así, permiten utilizar soluciones fiables y bien conocidas a problemas concretos, aprovechando experiencias previas como base para la consecución de mejores resultados en los nuevos desarrollos.

Pues bien, justo en el lado opuesto se encuentran los antipatrones, que definen situaciones y comportamientos que, según experiencias anteriores, nos conducen al fracaso en proyectos de desarrollo de software, es decir, son soluciones o planteamientos que se han demostrado incorrectos.

Y es ahí donde radica su interés: la observación y conocimiento de los mismos puede evitarnos resultados desastrosos, o actuar como alertas tempranas ante decisiones o dinámicas incorrectas, permitiéndonos prevenir, evitar o recuperarnos de estos problemas.

Al igual que en los patrones, su descripción está relativamente formalizada y suele recoger los siguientes aspectos:
  • nombre del antipatrón, así como su "alias"
  • su tipología: organizacional, de análisis, desarrollo... (veremos esto más tarde)
  • contexto y entorno en el que se aplica
  • descripción del problema concreto
  • síntomas, y consecuencias de la aplicación del antipatrón
  • causas típicas y raíces del problema
  • refactorización a aplicar, es decir, una descripción de cómo podríamos replantear el problema y conseguir una solución positiva.
  • ejemplos y escenarios para su comprensión.
  • soluciones relacionadas con la propuesta.

Por ejemplo, un resumen del clásico antipatrón que reconoceréis muy rápidamente, el llamado spaghetti code:

Nombre:Spaghetti Code
Tipología:Desarrollo
Problema:Existencia de una pieza de código compleja y sin apenas estructura que dificulta enormemente su mantenimiento posterior
Síntomas y consecuencias:
  • Tiempo de mantenimiento excesivo debido a la necesidad de estudio del código
  • Código no reutilizable
  • Aparición del temido "es mejor reescribirlo"
  • Métodos y funciones muy extensas
  • Abuso de variables globales
Causas:
  • Inexperiencia de desarrolladores
  • Reutilización de código de prototipos rápidos
  • Ausencia de diseño previo a la implementación
  • Desarrolladores trabajando en solitario
  • Falta de revisiones de código
Solución positiva:
  • Aplicar refactorización mientras se programa
  • Usar disciplinas de desarrollo específicas, métricas y buenas prácticas
  • Realizar y desarrollar el diseño del sistema antes de implementar

Según según la Wikipedia, los antipatrones se clasifican en los siguientes grupos, atendiendo a las áreas a las que afectan:
  • Antipatrones Organizacionales, que incluyen prácticas nocivas a este nivel, como pueden ser, entre otros:
    • Gestión de champiñones (Mushroom management), o mantener al equipo en la oscuridad, desinformado, y cubierto de porquería.
    • Parálisis en análisis (Analysis paralysis), o quedar inmovilizado debido a un análisis o precaución excesiva, en contraposición a la siguiente:
    • Extinción por intuición (Extint by instinct), llegar a la muerte por adelantarse demasiado y usar la intuición para la toma de decisiones.
  • Antipatrones de Gestión de proyectos, describiendo problemas en la gestión de proyectos, como los célebres:
    • Marcha de la muerte (Death march), que describe el avance de determinados proyectos hacia el fracaso aunque todo el personal, excepto los gerentes, saben que al final se darán el castañazo.
    • Humo y espejos (Smoke and mirrors), o la demostración de funcionalidades o características no implementadas como si fueran reales, lo que siempre he llamado "enseñar cartón piedra".
  • Antipatrones de Gestión de equipos, que recoge problemas relacionados con la relación con y de equipos de trabajo, como:
    • Doble diabólico (traducción libre del término Doppelganger), personas que dependiendo del día pueden ser magníficos colaboradores o auténticos demonios.
    • Gestor ausente (Absentee manager), describiendo situaciones en las que el director está invisible periodos prolongados
  • Antipatrones de Análisis, categoría que engloba antipatrones relacionados con la fase analítica de los proyectos software, entre otros:
    • Retroespecificación (Retro-specification), o lo que viene a ser la realización del análisis una vez implementada la solución.
    • Especificación de servilleta (Napkin specification), también muy socorrida, que consiste en pasar al equipo de desarrollo las especificaciones del producto a crear descritas con muy poco detalle o informalmente.
  • Antipatrones de Diseño, que incluye malas prácticas de diseño de software que dan lugar a aplicaciones y componentes estructuralmente incorrectos:
    • Gran bola de lodo (Big ball of mud), realización de aplicaciones sin estructura reconocible.
    • Factoría de gas (Gas factory), diseños innecesariamente complejos.
    • Botón mágico (Magic Pushbutton), o implementación de funcionalidades directamente en los manejadores de evento (p.e., click) del interfaz.
  • Antipatrones en Orientación a objetos, como una especialización del anterior, describe problemas frecuentes en los diseños creados bajo este paradigma, como:
    • Llamar al super (Call super), obligar a las subclases a llamar a la clase de la que heredan.
    • Singletonitis, abuso del patrón singleton.
    • Orgía de objetos (Object orgy), o encapsulación incorrecta en clases que permite el acceso incontrolado a sus métodos y propiedades internas.
    • Otra jodida capa más (YAFL, Yet another fucking layer), o la inclusión excesiva de capas en un sistema.
  • Antipatrones de Programación, con un gran número de errores frecuentes a evitar, como:
    • Spaghetti code, comentando anteriormente.
    • Ravioli code, que consiste en la existencia de un gran número de objetos desconectados o débilmente acoplados entre sí.
    • Ocultación de errores (Error hiding), o capturar errores antes de que lleguen usuario, mostrando mensajes incomprensibles o simplemente no mostrar nada.
    • Números mágicos (Magic numbers), incluir números inexplicables en el código.
  • Antipatrones Metodológicos, o formas de desarrollar que se han demostrado incorrectas a lo largo del tiempo, como pueden ser:
    • Programación copy & paste, también llamada herencia de editor, consiste en copiar, pegar y modificar, en contraposición a la estritura de software reutilizable.
    • Factor de improbabilidad (Improbability factor), asumir que un error conocido es improbable que ocurra.
    • Optimización prematura (Premature optimization), según algunos la raíz de todos los males, consiste en sacrificar el buen diseño y mantebilidad de un software en benecificio de la eficiencia.
    • Programación por permutación (Programming by permutation), o intentar dar con una solución modificando sucesivamente el código para ver si funciona.
  • Antipatrones de Gestión de configuración, hace referencia a antipatrones relacionados con la gestión de los entornos de desarrollo y explotación del software, como las variantes del infierno de las dependencias (Dependency hell), o problemas de versionado de librerías y componentes:
    • DLL's Hell, el conocido y traumático mundo de las librerías dinámicas en Windows.
    • JAR's Hell, idem, pero relativo a las librerías Java.

Por no hacer el post eterno sólo he recogido unos cuantos, aunque existen cientos de ellos, y con una gran variedad temática: antipatrones para el desarrollo guiado por pruebas (TDD), antipatrones de manejo de excepciones, para el uso de arquitecturas orientadas al servicio (SOA), de rendimiento, de seguridad, centrados en tecnologías (p.e., J2EE antipatterns) o según el tipo de software (sistemas de gestión, tiempo real, videojuegos, etc.).

Y como conclusión personal, decir que me he visto reconocido en multitud de ellos, lo cual significa que muy descaminados no andan. Es más, si hiciera una lista con patrones y otra con los antipatrones que utilizo o he utilizado, la segunda tendría más elementos que la primera... ¿quizás es momento de reflexionar un poco?

Publicado en: http://www.variablenotfound.com/.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

3 Comentarios:

Josepzin dijo...

Muy buen listado!!! por si te sirve de consuelo yo también me he visto reflejado en varios de ellos! :D:D:D

lluis dijo...

Yo he acuñado uno propio a partir del proyecto actual en el que estoy enfrascado : Caja de Pandora (Pandora's Box). Durante la etapa de diseño aparecen dudas de análisis, que al ser planteadas al analista producen un aluvión de Retro-Specifications y nuevos requerimientos. Si a esto le añadimos una metodologia en cascada, el resultado es un infierno.

AcP dijo...

Podría aportar algunos otros que encontré hace un tiempo en inglés y traduje bastante libremente, para tener bien cerca aquí en la pizarra. Antipatrones de diseño (a ver si de paso me ayudan con algunas lagunas de traducción que nunca resolví).