viernes, 31 de mayo de 2013

Los antipatrones más comunes a los que me enfrento de forma diaria.

Como descanso a DDD y como forma de desahogo voy a poner una lista de los antipatrones de diseño que día tras día veo que se repiten una y otra vez sin que nadie que cuente con la capacidad decisoria para poder atajar el problema mueva un dedo al respecto.



De gestión en general
  • Todo lo que tienes es un martillo : Gestión gris y plana, incapaz de tratar a los subordinados de manera personalizada y acorde con sus necesidades particulares.
  • Pollo sin cabeza: Se aplica al gestor, coordinador o responsable que vive en una permanente situación de pánico y medidas desesperadas.
  • Líder pero no gestor: Un buen líder no tiene por qué ser necesariamente un buen gestor, coordinador o responsable.
  • Gestión clonada: Situación en la que los coordinadores o gestores son contratados e instruidos para actuar y trabajar todos del mismo modo, a imagen y semejanza de sus propios jefes.
  • Gestor pero no líder: Un coordinador brillante en sus deberes administrativos y de gestión, pero que carece de habilidades de liderazgo.
  • Ejecutivo sin carácter: Gestor, coordinador o responsable que no tiene el coraje de enfrentarse a las situaciones, asumir las responsabilidades de los errores, o dar la cara por sus subordinados.
De gestión de proyectos
  • Mala gestión: Gestionar un proyecto sin tener suficientes conocimientos sobre la materia.
De diseño de software
  • Base de datos como comunicador de procesos: Usar una base de datos para comunicar procesos en uno o varios ordenadores, cuando la comunicación entre procesos directa es más adecuada.
  • Objeto todopoderoso: La funcionalidad entera del programa esta codificada en un solo objeto que hace todo, el cual mantiene toda la información del programa entero y contiene todos los métodos y subrutinas para manipular los datos
  • Clase Gorda: Dotar a una clase con demasiados atributos y/o métodos, haciéndola responsable de la mayoría de la lógica de negocio.
  • Botón mágico: Tender, desarrollando interfaces, a programar la lógica de negocio en los métodos de interacción, implementando los resultados de las acciones del usuario en términos no suficientemente abstractos.
  • Carrera de obstáculos: Incapacidad de prever las consecuencias de diferentes sucesiones de eventos.
  • Entrada chapuza: No especificar e implementar el manejo de entradas inválidas.
  • Gran bola de lodo: Construir un sistema sin estructura definida.
  • Punto de vista ambiguo: Presentar un modelo sin concretar ciertos aspectos, postergando así decisiones conflictivas.
  • Re-dependencia: Introducir dependencias innecesarias entre objetos.
  • Sistema de cañerías de calefacción: Construir un sistema difícilmente mantenible, ensamblando componentes poco relacionados.
Antipatrones de diseño orientado a objetos
  • Acoplamiento secuencial: Construir una clase que necesita que sus métodos se invoquen en un orden determinado
  • Llamar al super: Obligar a las subclases a llamar a un método de la superclase que ha sido sobrescrito.
  • Modelo de dominio anémico: Usar un modelo del dominio sin ninguna lógica de negocio. Esto no es un enfoque orientado a objetos porque cada objeto debería tener tanto propiedades como comportamiento asociado.
  • Objeto todopoderoso: Concentrar demasiada funcionalidad en una única parte del diseño (clase)..
  • Singletonitis: Abuso de la utilización del patrón singleton.
Antipatrones de programación
  • Acción a distancia: Provocar la interacción no prevista de componentes muy distantes de un sistema.
  • Acumular y arrancar: Establecer una colección de variables globales para ser usadas por un conjunto de subrutinas.
  • Código duro: Hacer supuestos sobre el entorno del sistema en demasiados lugares de la implementación.
  • Código espagueti: Construir sistemas cuya estructura es difícilmente comprensible, especialmente debido a la escasa utilización de estructuras de programación.
  • Confianza ciega: Descuidar la comprobación de los resultados que produce una subrutina, o bien de la efectividad de un parche o solución a un problema..
  • Manejo de excepciones: Emplear el mecanismo de manejo de excepciones del lenguaje para implementar la lógica general del programa.
  • Manejo de excepciones inútil: Introducir condiciones para evitar que se produzcan excepciones en tiempo de ejecución, pero lanzar manualmente una excepción si dicha condición falla.
  • Números mágicos: Incluir en los algoritmos números concretos sin explicación aparente.
  • Ocultación de errores: Capturar un error antes de que se muestre al usuario, y reemplazarlo por un mensaje sin importancia o ningún mensaje en absoluto.
  • Programación por excepción: Añadir trozos de código para tratar casos especiales a medida que se identifican.
  • Cadenas mágicas: Incluir cadenas de caracteres determinadas en el código fuente para hacer comparaciones, como tipos de eventos, etc.
Antipatrones metodológicos
  • Desarrollo conducido por quien prueba: Permitir que un proyecto software avance a base de extraer sus nuevos requisitos de los informes de errores.
  • Programación de copiar y pegar: Programar copiando y modificando código existente en lugar de crear soluciones genéricas.
Algunos antipatrones organizacionales
  • Alcance incremental: Permitir que el alcance de un proyecto crezca sin el control adecuado.
  • Escalada de compromiso: No ser capaz de revocar una decisión a la vista de que no ha sido acertada.
  • Funcionalitis creciente: Añadir nuevas funcionalidades al sistema en detrimento de su calidad.
  • Gestión de champiñones: Tratar a los empleados sin miramientos, sin informarles de las decisiones que les afectan (manteniéndolos cubiertos y en la oscuridad, como los champiñones).
  • Gestión porque lo digo yo: Aplicar una gestión autoritaria con tolerancia nula ante las disensiones.
  • Peligro moral: Aislar a quien ha tomado una decisión a raíz de las consecuencias de la misma.
Otros antipatrones
  • Arrojar al otro lado del muro: Cuando un proyecto involucra a varios grupos de trabajo y va pasando secuencialmente de uno a otro, con escasa o nula comunicación entre ellos.
  • Billete lobo: Declarar compatibilidad con un estándar cuando ésta no existe, o bien cuando el estándar solo incluye recomendaciones no obligatorias que, de hecho, no se siguen.
  • Callejón sin salida: Encontrar un problema que impide continuar trabajando, pero la dirección no permite corregir el problema. El equipo queda estancado.
  • Caminar por un campo de minas: Trabajar con un componente pobremente probado (usualmente inestable), y por tanto poco confiable.
  • Codificación brutal: Presionar a los programadores a trabajar sobre una arquitectura sin diseñar y sin requisitos evidentes.
  • Diseñadores empíricos: Incapacidad del grupo de diseño para evaluar la complejidad del objeto diseñado.
  • El gestor controla el proceso.
  • El traje nuevo del emperador: Temor a señalar los defectos de un producto o proceso que un gerente o manager cree que funciona bien.
  • Embudo de excepciones: Atrapar una excepción e ignorarla, sin reportarlo.
  • Moneda en punto flotante: Utilizar una representación en punto flotante para valores que representan dinero, lo que puede provocar pérdida de precisión.
  • Otra reunión más lo resolverá.
  • Proceso a prueba de idiotas.
  • Proyecto del día de la marmota: Discutir los mismos temas en todas las reuniones, sólo para llegar a la conclusión de que "algo debe hacerse".
  • Prueba incompleta: Descuidar en la etapa de pruebas, algunas unidades en todos los casos, o todas las unidades en algunos casos.
  • Requisitos ocultos.
  • Si funciona, no lo toques.
  • Valor por defecto indefinido (zero means null): Escoger un valor arbitrario para representar la indefinición, sin garantizar que ese valor no puede realmente ocurrir.
Y todavía me quedan muchas cosas chungas que se podrían considerar antipatrones pero que todavía no tienen un nombre oficial.

Fuente: Wikipedia

Si tienes en mente alguna mala practica y le has buscado un nombre COMENTA!!

No hay comentarios:

Publicar un comentario