Antipatrones de desarrollo de software

Una buena estructura de software es esencial para la extensión y mantenimiento de un sistema. El desarrollo de software es una actividad caótica, por lo tanto, la estructura implementada de un sistema tiende a alejarse de la estructura planificada según la arquitectura, el análisis y el diseño.
El refactoring del software es un enfoque eficaz para mejorar su estructura. La estructura resultante no tiene que se parecida a la estructura originalmente planificada.
Los cambios de estructura debido a que los programadores aprenden limitaciones y enfoques, alteran el contexto de las soluciones codificadas. Cuando es usado apropiadamente, el refactoring es una actividad natural en el proceso de programación.
Por ejemplo, la solución para el Antipatrón Spaghetti Code define un proceso de desarrollo de software que incorpora refactoring. Este es altamente recomendable antes que la optimización de rendimiento. Las optimizaciones, a menudo, implican comprometer la estructura del programa. Idealmente, las optimizaciones afectan a pequeñas partes de un programa.

Los antipatrones de desarrolla utilizan varios enfoque de refactoring, formales e informales. El siguiente sumario proporciona una vista general de los antipatrones de desarrollo que se encuentran en este capítulo y hace foco en los problemas de los mismos. Se incluyen descripciones del desarrollo y antipatrones. Las soluciones refactorizadas aparecen en el post apropiado del antipatrón que siguen a este sumario.

• The Blob: Diseño de tipo procedural que conduce a un objeto con muchas responsabilidades, mientras la mayoría de los otros objetos sólo contienen datos o ejecutan procesos simples. La solución incluye un  refactoring del diseño para distribuir responsabilidades más uniformemente y aislando el efecto de los cambios.
• Countinuous Obsolescense: La tecnología cambia tan rápidamente que los desarrolladores a menudo tienen problemas para mantenerse al día con las versiones actuales de software y encontrando combinaciones de productos que trabajan juntos. Dado que cada línea de producto comercial evoluciona con cada nuevo release, la situación se torna cada vez más difícil para los desarrolladores que lo enfrentan. Encontrar releases de productos que sean compatibles e interactúen exitosamente es incluso más difícil aun.
• Lava Flow: Código "muerto" e información de diseño olvidada es congelada en un diseño que cambia continuamente. Esto es análogo a un flujo de lava con burbujas de material rocoso endureciéndose. La solución refactorizada incluye una configuración del proceso de gestión que elimina el código muerto y evoluciona o refactoriza el diseño hacia el aumento de la calidad.
• Ambiguous Viewpoint: Los modelos de diseño y análisis orientado a objeto (OOA&D) son presentados a menudo sin aclarar el punto de vista representado por el modelo. Por defecto, los modelos OOA&D denotan un punto de vista de la implementación que es potencialmente el menos útil. Puntos de vista mezclados no permiten una separación fundamental de las interfaces de los detalles de implementación, lo cual es uno de los principales beneficios del paradigma de orientación a objetos.
• Functional Descomposition: Este antipatrón es la salida de los desarrolladores experimentados, que desconocen la orientación a objetos, quienes diseñan e implementan una aplicación en un lenguaje orientado a objetos. El código resultante se asemeja a un lenguaje procedural (Pascal, FORTRAN) en una estructura de clases. Puede ser increíblemente complejo cómo inteligentes desarrolladores procedurales diseñan ingeniosas maneras de replicar sus métodos probados por el tiempo en una arquitectura orientada a objetos.
• Poltergeists: Son clases con roles muy limitados y ciclos de vida efectivos. Ellas a menudo inician procesos para otros objetos. La solución refactorizada incluye la reubicación de responsabilidades hacia objetos de mayor vida que eliminen este antipatrón.
• Boat Anchor: Este antipatrón es una pieza de software o hardware que no sirve para ningún propósito en el proyecto actual. A menudo, el antipatrón Boat Anchor es una adquisición costosa, lo que hace que la compra sea más irónica.
• Golden Hammer: Se trata de una tecnología familiar o concepto aplicado obsesivamente a muchos problemas de software. La solución involucra expander el conocimiento de los desarrolladores a través de la educación, entrenamiento y grupos de estudio de libros para exponer a los desarrolladores a tecnologías y enfoques alternativos.
• Dead End: Un callejón sin salida (Dead End) es alcanzado mediante la modificación de un componente reutilizable si el componente modificado ya no es soportado ni mantenido por el proveedor. Cuando estas modificaciones son realizadas, la carga de brindar soporte se transfiere a los desarrolladores de la aplicación. Las mejoras en el componente reusable no son fácilmente integradas y ante cualquier problema se puede culpar a la modificación.
• Spaghetti Code: Estructuras de software Ad hoc hacen que el código sea difícil de extender y optimizar. El refactoring frecuente del código puede mejorar la estructura del software, soportar el mantenimiento del mismo y permitir el desarrollo iterativo.
• Input Kludge: Software que falla pruebas sencillas de comportamiento puede ser un ejemplo de este antipatrón, el cual sólo ocurre cuando algoritmos Ad hoc son empleados para manejar entradas al programa.
• Walking through a Minefield: Usar tecnología de software actual es análogo a caminar en un campo de minas high-tech. Numerosos errores son encontrados en productos liberados; de hecho, los expertos estiman que el código fuente original del producto posee entre 2 y 5 errores por cada línea de código. Esto significa que se necesitarán entre dos y cinco modificaciones por línea para remover todos los defectos.
• Cut and Paste Programming: Código reusado mediante el copiado de sentencias lleva a significativos problemas de mantenimiento. Formas alternativas de reutilización, incluyendo black-box, reducen los problemas de mantenimiento por tener código fuente, testing y documentación únicos.
• Mushroom managment: En algunos círculos de arquitectura y gestión, hay una política explícita de mantener a los desarrolladores aislados de los usuarios finales del sistema. Los requerimientos son pasados de segunda mano a través de intermediarios, incluyendo arquitectos, administradores o analistas funcionales.

Por Juan Barrionuevo