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!!