Anti Patrones Parte I

¿Por dónde empezar?, un anti patrón, por así decirlo, es un patrón mal aplicado que nos lleva a una mala solución. Veamos algunos.

Anti-patrones de Gestión de Proyectos

1- Productividad a toda costa: La empresa busca la productividad a costa de la calidad del software y de la calidad de vida de sus empleados, intenta normalizar los puestos de trabajo quitando en la medida de lo posible, los permisos a los programadores para que no dañen los sistemas operativos, monitoriza a los equipos de trabajo y actúa cortando la visibilidad de ciertas páginas o reuniones de programadores, al final la gente abandona la empresa cuando la situación ya es insostenible, esto suele ocurrir en ciclos de uno o dos años.

2- Mas programadores, para reducir el tiempo de entrega. Muchas veces para arreglar el retraso en la entrega de un proyecto se suman mas programadores a un equipo, lo cual suele juegar en contra llevando a un mayor retraso.

3- Jefes/as que no saben coordinar un equipo, el proyecto no se monitoree de manera correcta. Esto suele llevar a retrasos en los tiempos de entrega o entregas incompletas.

Anti-Patrones en el código

1- Vulcan Code: se caracteriza por tener clases con grandes cantidades de código, poco documentadas variables declaradas que no se usan o que no son necesarias.

Se utiliza un estilo poco claro en evolución la arquitectura.

Es un proyecto que tiene mucho código por reemplazar o mejorar por ejemplo: métodos que no se invocan, objetos o componentes que no se utilizan, interfaces abandonadas, etc.

2- Spaghetti Code: si bien tiene mucha similitud con “Vulcan Code”, este anti-patrón se caracteriza además por utilizar mas de un lenguaje en el desarrollo y por tener una arquitectura frágil con lo cual el menor cambio afecta de manera drástica toda la estructura del sistema.

3- Ghosts (Fantasmas): se caracteriza por tener varias clases en el sistema o tablas en la base de datos con pocas responsabilidades. Este anti-patrón suele darse cuando un modelo de análisis y/o diseño es inestable: el diseño no suele coincidir con la implementación y ampliar el sistema es poco probable, dado que habiendo tanto “fantasma”, encontrar los elementos relevantes es imposible.

Anti-Patrones en la Arquitectura

1- Reinventar la rueda, es uno de los anti-patrones más típicos, se caracteriza por la poca reutilización de código y el reescribir código en lugar de implementar componentes ya existentes.

2- Stovepipe (cañerías de calefacción): Se refiere a construir un sistema que difícilmente se puede mantener ya que está ensamblando por componentes poco relacionados. Un ejemplo de esto serí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 un plan o eje guía), los resultados son una pobre o nula interoperabilidad y un incremento en los costos. Este anti-patrón es mas habitual de lo que se cree.

Espero les guste este articulo. Pronto escribiré la segunda parte.

Gracias por visitar mi blog.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s