Tipos De Antipatrones De Diseño

Antipatrones

Definiciones

El antipatrón es una forma para capturar la experiencia de los desarrolladores para poder ser asimilada más fácilmente por otros desarrolladores.

Los antipatrones capturan las experiencias que repetidamente han arruinado el desarrollo de los proyectos de software y ofrecen sugerencias de solución a estas situaciones.

La idea que sobre la que descansan los antipatrones es la creencia de que es más fácil detectar lo que se hace mal que proveer un buen comportamiento.

Existen formatos para documentar los antipatrones y una versión abreviada para mini antipatrones.

El estudio de los antipatrones

Es muy útil porque sirve para no escoger malos caminos en el desarrollo de sistemas, teniendo para ello una base documental y así evitar usar simplemente la intuición. Además proporciona una denominación común a problemas que facilita la comunicación entre diferentes desarrolladores.

• Son un método eficiente para vincular una situación general a una clase de solución específica.

• Proveen experiencia del mundo real para reconocer problemas recurrentes en la industria del software, ofreciendo también una solución para sus implicaciones más comunes.

• Establecen un vocabulario común para identificar problemas y discutir soluciones.

• Soportan la resolución holística de conflictos, utilizando recursos organizacionales a diferentes niveles.

Los antipatrones se documentan con cierto cinismo, lo cual los hace bastante graciosos y fáciles de recordar. Los nombres siempre aluden al problema que tratan con humor. Se documentan mediante una plantilla (como los patrones de diseño) que incluye secciones para documentar la solución orígen (que es la causa del problema), el contexto, las fuerzas en conflicto y las soluciones correctas propuestas. Un buen antipatrón explica por qué la solución original parece atractiva, por qué se vuelve negativa y cómo recuperarse de los problemas que ésta genera.

Según James Coplien, un antipatrón es...

“...algo que se ve como una buena idea, pero que falla malamente cuando se la implementa.”

Comparación entre patrones y antipatrones:

Se presentan los antipatrones de los siguientes tipos:

• Desarrollo de Software

• Arquitectura de Software

• Administración o gestión de Proyectos de Software

Desarrollo de software Arquitectura Gestión

The Blob

Lava Flow

Functional Decomposition

Poltergeists

Golden Hammer

Spaghetti Code

Cut and Paste Programming

Mini antipatterns

Continuous Obsolescence

Ambiguous Viewpoint

Boat Anchor

Dead End

Input Kludge

Walking through a Minefield

Mushroom Management Stovepipe Enterprise

Vendor Lock-in

Architecture by Implication

Design by Committee

Reinvent the Wheel

Mini antipatterns

Autogenerated Stovepipe

Jumble

Cover your Assets

Wolf Ticket

Warm Bodies

Swiss Army Knife

The Grand Old Duke of York Analysis Paralysis

Death by Planning

Corncob

Irrational Management

Project Missmanagement

Mini antipatterns

Blowhard Jamboree

Viewgraph Engineering

Fear of Success

Intellectual Violence

Smoke and Mirrors

Throw it over the wall

Fire Drill

The Feud

E-Mail is Dangerous

Antipatrones de desarrollo de software

The Blob: Este antipatrón se da en objetos con muchos atributos o muchas operaciones. Esto rompe las ventajas de la programación OO, ya que estas clases tan grandes son muy difíciles de mantener, de reusar y de probar. Suele aparecer por un diseño malo o debido a sistemas heredados. El tamaño de estos objetos perjudica su tiempo de carga.

Lava Flow: Este anti patrón se da cuando se entrega software antes de ser terminado o suficientemente probado que tiene un código no óptimo y al ser expuesto, sus características no pueden ser modificadas – como un flujo de lava cuando se solidifica.

Poltergeist: Esta mala práctica se refiere a objetos de un ciclo de vida corto cuya única función suele ser invocar métodos de otros objetos. Esto hace que crezca la dificultad para mantener el sistema. Suelen identificarse por su nombre: “start_”, “manager_”. La solución para evitarlos es eliminarlos y poner su funcionalidad en la clase a la que invocan.

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 ser útil.

Antipatrones de arquitectura de software

Stovepipe enterprise: Este mal se da cuando disponemos de varios sistemas aislados entre si – lo que se llama islas de automatización – y que no pueden colaborar entre si para desarrollar otros sistemas más grandes y útiles para la organización. Sucede cuando no se dispone de una planificación de los sistemas y no se ha tenido en cuenta la ínter operatibilidad.

Stovepipe system: Este anti patrón se refiere a 2 posibles circunstancias:

a) Un sistema que no puede ínter operar con el resto de los sistemas de una organización.

b) Un sistema heredado que un ensamblaje de pequeños sistemas que están tan unidos entre si que no es posible diferenciar cada uno de ellos, imposibilitando su actualización, refactorización etc…

Vendor Lock-In: El anti patrón “Vendor Lock-in” sucede cuando dependemos de una arquitectura, plataforma o tecnología. Esta dependencia puede tener unas consecuencias muy negativas puesto que nuestros desarrollos pueden ser dependientes de características proporcionadas por terceros, pueden verse “rotos” por el cambio de las características de estas tecnologías, etc…

Antipatrones de gestión de proyectos de software

Analysis Paralysis: Parálisis del Análisis (en inglés analysis paralysis) sucede cuando se pretende descubrir y modelar todos y cada uno de los detalles de un sistema informático en una fase inicial, invirtiendo un tiempo excesivo con la intención de no regresar a la etapa de análisis. Las dos creencias que provocan este fallo son la creencia de que se ha de codificar solo cuando se ha terminado el análisis y que una vez que hemos comenzado a codificar no se debe volver al análisis.

Corncob: Es habitual que en el desarrollo de un proyecto de un proyecto de software, ciertas personas dificulten su desarrollo. Se ha calculado que al menos la mitad del tiempo en un proceso de desarrollo de software se invierte en la comunicación

...