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.

A continuación veremos algunos ejemplos muy usuales 🙂

Antipatrón Amarrado por el vendedor (Vendor lock-in)

También conocido como: Arquitectura dependiente de producto, Esclavitud y sumisión,

Escala: Sistema

Corrección: Capa aislante

Tipo de solución: Software

Causas básicas: Pereza, Apatía, Orgullo/Ignorancia

Fuerzas desbalanceadas: Administración de la transferencia de tecnología, Administración de cambio

Forma General

El proyecto de software adopta la tecnología de un producto y queda completamente dependiente del vendedor. Cuando aparecen nuevas versiones del producto cambia el software y aparecen problemas de interoperabilidad que implican el mantenimiento continuo del sistema.

Síntomas y Consecuencias

· Nuevas versiones del producto comercial causan el mantenimiento continuo del software de aplicación.

• Las características prometidas de productos comerciales nunca se cumplen o su entrega se retrasa, en consecuencia causa los retrasos en la entrega de aplicación.
• El producto varía mucho de los estándares de sistemas abiertos.

Causas típicas

• El producto varía con respecto a los estándares de sistemas abiertos porque no existen procesos formales que aseguren la conformancia.
• El producto es seleccionado con base en la propaganda e información del vendedor y no en una inspección técnica más detallada.
• No existe enfoque técnico para aislar el software de aplicación de la dependencia directa del producto.
• La programación de aplicaciones requiere de conocimiento profundo del producto.
• La complejidad y generalidad de la tecnología del producto excede en gran medida las necesidades de la aplicación.

Excepción Conocida

Este patrón es aceptable cuando el código proporcionado por el vendedor cubre la mayoría del código que se necesita para la aplicación.

Corrección

La solución correctiva se conoce como capa aislante. La capa aislante separa el software del vendedor de las aplicaciones. Esto se puede usar para proporcionar la portabilidad.

Antipatrón Arquitectura Implícita (Architecture by Implication)

También conocido como: ¿Qué rollo es esto de arquitectura?

Escala: Sistema

Corrección: Arquitectura basada en objetivo (Goal Question Architecture)

Tipo de corrección: Documentación

Causas básicas: Orgullo, Pereza

Fuerzas desbalanceadas: Administración de Complejidad, Cambios, Riesgo

Forma General

El antipatrón se caracteriza por la falta de la especificación de la arquitectura del sistema que se está desarrollando. Usualmente las personas responsables por el proyecto tienen experiencia de sistemas previamente desarrollados por lo tanto consideran que la documentación no es necesaria. Esta confianza exagerada conlleva a riesgos que pueden afectar el éxito del sistema.

Por lo general las definiciones de la arquitectura carecen de alguno de los siguientes puntos:

· Arquitectura de software y especificación de lenguaje, bibliotecas, estándares de codificación, administración de memoria, etc.

• Arquitectura de hardware que incluye las configuraciones de clientes y servidores.
• Arquitectura de comunicación que incluye a los protocolos y dispositivos de comunicación.
• Arquitectura de persistencia que incluye las bases de datos, manejo de archivos.
• Arquitectura de la seguridad de la aplicación que incluye modelos de hilos de control y sistemas de acceso.
• Arquitectura de administración de sistemas.

Síntomas y Consecuencias

· Falta de planeación de la arquitectura y su especificación.

• Riesgos ocultos causados por la escala del sistema, conocimiento del dominio del problema, tecnología y complejidad, todo esto emergiendo mientras se avanza en el proyecto.
• Ignorancia de nuevas tecnologías.
• Ausencia de soporte técnico y planes de contigencia.

Causas Típicas

· Falta de administración de riesgos

· Demasiada confianza en administradores, arquitectos y desarrolladores.

• Demasiada confianza en éxito de experiencias previas que pueden ser diferentes en áreas cruciales.
• Problemas implícitos y no resueltos de arquitectura causados por faltas en ingeniería del sistema.

Corrección

La solución consiste en la decisión organizacional con respecto a las especificaciones de la arquitectura basadas en múltiples vistas. Cada vista responde a las necesidades de un usuario del sistema. Las vistas comprenden el conjunto de diagramas, tablas o especificaciones que deben ser consistentes.

Antipatrón Arquitectura Implícita (Architecture by Implication)

También conocido como: ¿Qué rollo es esto de arquitectura?

Escala: Sistema

Corrección: Arquitectura basada en objetivo (Goal Question Architecture)

Tipo de corrección: Documentación

Causas básicas: Orgullo, Pereza

Fuerzas desbalanceadas: Administración de Complejidad, Cambios, Riesgo

Forma General

El antipatrón se caracteriza por la falta de la especificación de la arquitectura del sistema que se está desarrollando. Usualmente las personas responsables por el proyecto tienen experiencia de sistemas previamente desarrollados por lo tanto consideran que la documentación no es necesaria. Esta confianza exagerada conlleva a riesgos que pueden afectar el éxito del sistema.

Por lo general las definiciones de la arquitectura carecen de alguno de los siguientes puntos:

· Arquitectura de software y especificación de lenguaje, bibliotecas, estándares de codificación, administración de memoria, etc.

• Arquitectura de hardware que incluye las configuraciones de clientes y servidores.
• Arquitectura de comunicación que incluye a los protocolos y dispositivos de comunicación.
• Arquitectura de persistencia que incluye las bases de datos, manejo de archivos.
• Arquitectura de la seguridad de la aplicación que incluye modelos de hilos de control y sistemas de acceso.
• Arquitectura de administración de sistemas.

Síntomas y Consecuencias

· Falta de planeación de la arquitectura y su especificación.

• Riesgos ocultos causados por la escala del sistema, conocimiento del dominio del problema, tecnología y complejidad, todo esto emergiendo mientras se avanza en el proyecto.
• Ignorancia de nuevas tecnologías.
• Ausencia de soporte técnico y planes de contigencia.

Causas Típicas

· Falta de administración de riesgos

· Demasiada confianza en administradores, arquitectos y desarrolladores.

• Demasiada confianza en éxito de experiencias previas que pueden ser diferentes en áreas cruciales.
• Problemas implícitos y no resueltos de arquitectura causados por faltas en ingeniería del sistema.

Corrección

La solución consiste en la decisión organizacional con respecto a las especificaciones de la arquitectura basadas en múltiples vistas. Cada vista responde a las necesidades de un usuario del sistema. Las vistas comprenden el conjunto de diagramas, tablas o especificaciones que deben ser consistentes.

Antipatrón Arquitectura Implícita (Architecture by Implication)

También conocido como: ¿Qué rollo es esto de arquitectura?

Escala: Sistema

Corrección: Arquitectura basada en objetivo (Goal Question Architecture)

Tipo de corrección: Documentación

Causas básicas: Orgullo, Pereza

Fuerzas desbalanceadas: Administración de Complejidad, Cambios, Riesgo

Forma General

El antipatrón se caracteriza por la falta de la especificación de la arquitectura del sistema que se está desarrollando. Usualmente las personas responsables por el proyecto tienen experiencia de sistemas previamente desarrollados por lo tanto consideran que la documentación no es necesaria. Esta confianza exagerada conlleva a riesgos que pueden afectar el éxito del sistema.

Por lo general las definiciones de la arquitectura carecen de alguno de los siguientes puntos:

· Arquitectura de software y especificación de lenguaje, bibliotecas, estándares de codificación, administración de memoria, etc.

• Arquitectura de hardware que incluye las configuraciones de clientes y servidores.
• Arquitectura de comunicación que incluye a los protocolos y dispositivos de comunicación.
• Arquitectura de persistencia que incluye las bases de datos, manejo de archivos.
• Arquitectura de la seguridad de la aplicación que incluye modelos de hilos de control y sistemas de acceso.
• Arquitectura de administración de sistemas.

Síntomas y Consecuencias

· Falta de planeación de la arquitectura y su especificación.

• Riesgos ocultos causados por la escala del sistema, conocimiento del dominio del problema, tecnología y complejidad, todo esto emergiendo mientras se avanza en el proyecto.
• Ignorancia de nuevas tecnologías.
• Ausencia de soporte técnico y planes de contigencia.

Causas Típicas

· Falta de administración de riesgos

· Demasiada confianza en administradores, arquitectos y desarrolladores.

• Demasiada confianza en éxito de experiencias previas que pueden ser diferentes en áreas cruciales.
• Problemas implícitos y no resueltos de arquitectura causados por faltas en ingeniería del sistema.

Corrección

La solución consiste en la decisión organizacional con respecto a las especificaciones de la arquitectura basadas en múltiples vistas. Cada vista responde a las necesidades de un usuario del sistema. Las vistas comprenden el conjunto de diagramas, tablas o especificaciones que deben ser consistentes.

Antipatrón Diseñado por Comité

Conocido también como: Chapa de Oro, Enfermedad de Estandarización, Haz Feliz a Todo Mundo, Partido Político

Escala: Global

Nombre de Corrección: Facilidad de Reuniones

Tipo de Corrección: Proceso

Causas básicas: Orgullo, Avaricia

Fuerzas desbalanceadas: Administración y Funcionalidad, Complejidad, Recursos

Evidencia anecdótica: "Un camello es un caballo diseñado por un comité."

Antecedentes

La orientación a objetos frecuentemente se describe como la tecnología de dos generaciones. La primera se caracteriza por el análisis centrado en objetos-datos y la segunda por patrones de diseño. La primera generación se basa en la filosofía que "los objetos son cosas tangibles". La consecuencia de esto es que todos los diseños son verticales. Una de las creencias de la primera generación es que el grupo de desarrollo debe ser igualitario, es decir, las decisiones deben de ser tomadas democráticamente. Esto lleva a diseño por comité. Las buenas abstracciones son definidas por grupos muy pequeños, los diseños donde se decide por mayoría invariablemente llevan a perder la abstracción e introducen complejidad.

Forma general

El diseño complejo de software es producto de trabajo de un comité. Tiene tantos conceptos y variaciones que no es posible que los desarrolladores lo implementen en tiempo razonable. Tampoco es posible verificar el diseño por su complejidad. El diseño carece de claridad conceptual porque demasiada gente a metido su mano en su creación.

Síntomas y Consecuencias

· La documentación del diseño es demasiado compleja, illegible, incoherente o excesivamente defectuosa.

• La documentación es muy voluminosa.
• Se perdió la convergencia y la estabilidad entre los requerimientos y el diseño.
• Las reuniones del comité se convierten en sesiones poco productivas.
• Pocas decisiones se pueden tomar fuera del comité lo que atrasa mucho el avance del proyecto.
• No existe la priorización en las estructuras del diseño.
• Lo arquitectos y los desarrolladores pelean frecuentemente.
• …

Causas Típicas

· No existe arquitecto responsable por el proyecto.

• El proceso de software degenerado o inefectivo.
• Mal proceso de reuniones.
• Poner chapa de oro, es decir, añadir cosas que harán al cliente dependiente de nosotros.
• Hacer contentos a todos los miembros del comité incorporando sus ideas.
• …

Excepciones Conocidas

El diseño por comité puede funcionar cuando el comité es pequeño (6-10 personas) y compuesto de expertos reales.

Corrección

La esencia de la corrección de este antipatrón consiste en reorganizar el proceso de reuniones. Lo primero es tener un reloj en la reunión para tener el tiempo transcurrido muy presente. Poner los objetivos de la reunión en la agenda. Permitir intervenciones de más o menos 25 palabras, añadir comentarios solo si son requeridos.

Cada reunión debe contestar dos preguntas: ¿Para qué nos reunimos? Y ¿Con qué queremos salir de aquí?

También es útil repartir roles entre los miembros del equipo: responsable, facilitador, arquitecto, desarrollador, probador y experto en el dominio. Cada quien puede aportar a las reuniones según su especialidad.

Presenta técnicas para mejorar la eficiencia en el trabajo en grupo.

Ejemplos

SQL y CORBA