Antipatrón de diseño

De Wikipedia, la enciclopedia libre
(Redirigido desde «Antipatrón de Diseño»)
Saltar a: navegación, búsqueda

Un antipatrón de diseño es un patrón de diseño que invariablemente conduce a una mala solución para un problema.

Al documentarse los antipatrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.

El término se origina inspirado en el libro Design Patterns, escrito por un grupo de autores conocido como Gang of Four, y que aglutina un conjunto de buenas soluciones de programación. Los autores bautizaron dichas soluciones con el nombre de "patrones de diseño" por analogía con el mismo término, usado en arquitectura. El libro Anti-Patterns (de William Brown, Raphael Malveau, Skip McCormick y Tom Mowbray, junto con la más reciente incorporación de Scott Thomas) describe los antipatrones como la contrapartida natural al estudio de los patrones de diseño. El estudio formal de errores que se repiten permite reconocer y reconducir los elementos involucrados hacia una mejor solución. Los antipatrones no se mencionan en el libro original de Design Patterns, puesto que éste es anterior.

Los antipatrones se consideran una parte importante de una buena práctica de programación. Es decir, un buen programador procurará evitar los antipatrones siempre que sea posible, lo que requiere su reconocimiento e identificación tan pronto como sea posible, dentro del ciclo de vida del software.

El concepto de antipatrón se puede aplicar a la ingeniería en general, e incluso a cualquier tarea realizada por el hombre. Aunque no se escucha con frecuencia fuera del campo ingenieril, la noción está ampliamente extendida.

Algunos antipatrones de desarrollo de software[editar]

Antipatrones de gestión[editar]

  • 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 homogeneizar 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 las reuniones de programadores, al final se consigue que se vaya la gente de la empresa cuando la situación es insostenible, esto suele ocurrir en ciclos de uno o dos años.
  • Responsable ausente (absentee manager): Situación en la que el principal responsable o coordinador se ausenta o permanece en paradero desconocido o no localizable durante importantes períodos de tiempo.
  • Todo lo que tienes es un martillo (all you have is a hammer): Gestión gris y plana, incapaz de tratar a los subordinados de manera personalizada y acorde con sus necesidades particulares.
  • Negociador de jaula de acero (cage match negotiator): Se aplica cuando un coordinador, gestor o responsable aplica una filosofía de "éxito a cualquier precio".
  • Dos caras (doppelganger): Coordinador o compañero que en un determinado momento puede ser agradable y de trato fácil, pero igualmente puede volverse irracional y despiadado de modo inesperado.
  • Rodeos improductivos (fruitless hoops): Gestor o coordinador que solicita grandes cantidades de datos (en ocasiones sin relevancia alguna) antes de tomar una decisión.
  • Niñito de oro (golden child): Situación en la que ciertas responsabilidades, oportunidades, reconocimientos o recompensas van a parar a un determinado miembro del equipo como consecuencia de una relación personal o en clara contradicción con su rendimiento real.
  • Pollo sin cabeza (headless chicken): 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 (leader not manager): Un buen líder no tiene por qué ser necesariamente un buen gestor, coordinador o responsable.
  • Gestión clonada (managerial cloning): 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 (manager not leader): Un coordinador brillante en sus deberes administrativos y de gestión, pero que carece de habilidades de liderazgo.
  • Abuso de la métrica (metric abuse): Utilización manipuladora o incompetente de las medidas y las métricas.
  • Sr. Amigo de todos (Mr. Nice Guy): Se aplica al gestor que pretende convertirse en amigo de todos.
  • Héroe del proletariado (proletariat hero): El "empleado para todo" que siempre es puesto como ejemplo ante sus compañeros, pero que realmente es la excusa perfecta para demandas crecientes y constantes incrementos de expectativas.
  • Estrellas nacientes (rising upstart): Se aplica a quienes, teniendo potencial, no son capaces de respetar la progresión profesional establecida, y pretenden sortear los plazos y requisitos de aprendizaje y madurez.
  • Ejecutivo sin carácter (spineless executive): 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.
  • Caballero de tres cabezas (three-headed knight): Gestor indeciso, poco firme, dubitativo.
  • Arma definitiva (ultimate weapon): Individuos altamente competentes en los que la organización o sus compañeros confían tanto que se convierten en el canal por el que todo pasa.
  • Recién llegado (warm body): Trabajador que apenas cubre las expectativas mínimas y por tanto circula de proyecto en proyecto o de equipo en equipo.
  • Arquitecto a obrero (super builder): Creencia por la que se asigna a un buen diseñador de software al desarrollo de código pensando en que tardara mucho menos en teclearlo.

Antipatrones de gestión de proyectos[editar]

  • Humo y espejos (smoke and mirrors): Mostrar cómo será una funcionalidad antes de que esté implementada.
  • Mala gestión (bad management): Gestionar un proyecto sin tener suficientes conocimientos sobre la materia.
  • Software inflado (software bloat): Permitir que las sucesivas versiones de un sistema exijan cada vez más recursos.

Antipatrones generales de diseño de software[editar]

Antipatrones de diseño orientado a objetos[editar]

  • Acoplamiento secuencial (sequential coupling): Construir una clase que necesita que sus métodos se invoquen en un orden determinado.
  • BaseBean: Heredar funcionalidad de una clase utilidad en lugar de delegar en ella.
  • Fallo de clase vacía (empty subclass failure): Crear una clase que no supera el test de la subclase vacía, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que no añade modificación alguna.
  • Llamar a super (callsuper): Obligar a las subclases a llamar a un método de la superclase que ha sido sobrescrito.
  • Modelo de dominio anémico (anemic domain model): 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 sumidero (object cesspool): Reutilizar objetos no adecuados realmente para el fin que se persigue.
  • Objeto todopoderoso (god object): Concentrar demasiada funcionalidad en una única parte del diseño (clase).
  • Poltergeist (informática): Emplear objetos cuyo único propósito es pasar la información a terceros objetos.
  • Problema del círculo-elipse (circle-ellipse problem): Crear variables de tipo pensando en los valores de posibles subtipos.
  • Problema del yoyó (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación.
  • Singletonitis: Abuso de la utilización del patrón singleton.
  • YAFL (yet another layer, y otra capa más): Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.

Antipatrones de programación[editar]

  • Nomenclatura heroica (heroic naming): Identificar los miembros de un programa (interfaces, clases, propiedades, métodos...) con nombres que provocan que el conjunto aparente estandarización con la ingeniería del software pero que en realidad oculta una implementación anárquica.
  • Acción a distancia (action at a distance): Provocar la interacción no prevista de componentes muy distantes de un sistema.
  • Acumular y arrancar (accumulate and fire): Establecer una colección de variables globales para ser usadas por un conjunto de subrutinas.
  • Ancla del barco (boat anchor): Retener partes del sistema que ya no tienen utilidad.
  • Bucle activo (busy spin): Utilizar espera activa cuando existen alternativas.
  • Código duro (hard code): Hacer supuestos sobre el entorno del sistema en demasiados lugares de la implementación.
  • Complejidad no indispensable (accidental complexity): Dotar de complejidad innecesaria a una solución.
  • Código espagueti (spaghetti code): Construir sistemas cuya estructura es difícilmente comprensible, especialmente debido a la escasa utilización de estructuras de programación.
  • Código ravioli (ravioli code): Construir sistemas con multitud de objetos muy débilmente conectados.
  • Comprobación de tipos en lugar de interfaz (checking type instead of interface): Comprobar que un objeto es de un tipo concreto cuando lo único que se necesita es verificar si cumple un contrato determinado.
  • Confianza ciega (blind faith): 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.
  • Doble comprobación de bloqueo (double-checked locking): Comprobar, antes de modificar un objeto, si es necesario hacer esa modificación, pero sin bloquear para comprobarlo, de manera que dicha comprobación puede fallar.
  • Fallo de caché (caching failure): Olvidar restablecer una marca de error cuando éste ya ha sido tratado.
  • Lava seca (lava flow): Código muerto e información de diseño olvidada permanecen congelados en un diseño cambiante. Esto es análogo a un flujo de lava en el que se van endureciendo pedazos de roca. La solución incluye un proceso de gestión de la configuración que elimina el código muerto y permite evolucionar o rehacer el diseño para acrecentar la calidad.
  • Lógica super-booleana (superboolean logic): Emplear comparaciones o abstracciones de la lógica booleana innecesarias.
  • Manejo de excepciones (exception handling): Emplear el mecanismo de manejo de excepciones del lenguaje para implementar la lógica general del programa.
  • Manejo de excepciones inútil (useless exception handling): Introducir condiciones para evitar que se produzcan excepciones en tiempo de ejecución, pero lanzar manualmente una excepción si dicha condición falla.
  • Momento del código (code momentum) : Establecer demasiadas restricciones sobre una parte del sistema debido a la asunción de muchas de sus propiedades desde otros lugares del propio sistema.
  • Números mágicos (magic numbers): Incluir en los algoritmos números concretos sin explicación aparente.
  • Ocultación de errores (error hiding): Capturar un error antes de que se muestre al usuario, y reemplazarlo por un mensaje sin importancia o ningún mensaje en absoluto.
  • Packratting: Consumir memoria en exceso debido a no liberar objetos reservados dinámicamente una vez ya han dejado de ser necesarios.
  • Programación por excepción (coding by exception): Añadir trozos de código para tratar casos especiales a medida que se identifican.
  • Secuencia de bucle por casos (Loop-switch sequence): Programar un conjunto de pasos secuenciales usando un bucle en combinación con una estructura de control por casos.
  • Cadenas mágicas (magic strings): Incluir cadenas de caracteres determinadas en el código fuente para hacer comparaciones, como tipos de eventos, etc.

Antipatrones metodológicos[editar]

  • Bala de plata (silver bullet): Asumir que nuestra solución técnica favorita puede resolver un problema mucho mayor.
  • Desarrollo conducido por quien prueba (tester driven development): Permitir que un proyecto software avance a base de extraer sus nuevos requisitos de los informes de errores.
  • Desfactorización (de-factoring): Eliminar funcionalidad y reemplazarla con documentación.
  • Factor de improbabilidad (improbability factor): Asumir que es improbable que un error conocido cause verdaderos problemas.
  • Martillo de oro (golden hammer): Asumir que nuestra solución favorita es universalmente aplicable, haciendo bueno el refrán a un martillo, todo son clavos.
  • Optimización prematura (premature optimization): Realizar optimizaciones sin disponer de la información suficiente para hacerlo con garantías, sacrificando decisiones de diseño.
  • Programación de copiar y pegar (copy and paste programming): Programar copiando y modificando código existente en lugar de crear soluciones genéricas.
  • Programación por permutación (programming by permutation): Tratar de aproximarse a una solución modificando el código una y otra vez para ver si acaba por funcionar.
  • Reinventar la rueda (reinventing the wheel): Enfrentarse a las situaciones buscando soluciones desde cero, sin tener en cuenta otras que puedan existir ya para afrontar los mismos problemas.
  • Reinventar la rueda cuadrada (reinventing the square wheel): Crear una solución pobre cuando ya existe una buena.

Antipatrones de gestión de la configuración[editar]

  • Conflicto de extensiones (extension conflict): Problemas con diferentes extensiones que tratan de gestionar las mismas partes del sistema (específico de Mac OS).
  • Infierno de dependencias (dependency hell): Escenario de problemas producidos por las versiones de otros productos que se necesitan para hacer funcionar un tercero.
    • Infierno DLL (DLL hell): Problemas con las versiones, disponibilidad o proliferación de DLLs (específico de Microsoft Windows)
    • Infierno JAR (JAR hell): Problemas con diferentes versiones o ubicaciones de ficheros JAR (Java), típicamente causados por la falta de comprensión del modelo de carga de clases.

Algunos antipatrones organizacionales[editar]

  • Alcance incremental (scope creep): Permitir que el alcance de un proyecto crezca sin el control adecuado.
  • Dependencia de proveedor (vendor lock-in): Construir un sistema que dependa en exceso de un componente proporcionado por un tercero.
  • Diseño en comité (design by committee): Contar con muchas opiniones sobre un diseño, pero adolecer de falta de una visión unificada.
  • Escalada de compromiso (escalation of commitment): No ser capaz de revocar una decisión a la vista de que no ha sido acertada.
  • Funcionalitis creciente (creeping featuritis): Añadir nuevas funcionalidades al sistema en detrimento de su calidad.
  • Gestión basada en números (management by numbers): Prestar demasiada atención a criterios de gestión cuantitativos, cuando no son esenciales o difíciles de cumplir.
  • Gestión de champiñones (mushroom management): 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 (management by perkele): Aplicar una gestión autoritaria con tolerancia nula ante las disensiones.
  • Migración de costes (cost migration): Trasladar los gastos de un proyecto a un departamento o socio de negocio vulnerable.
  • Obsolescencia continua (continuous obsolescence): Destinar desproporcionados esfuerzos a adaptar un sistema a nuevos entornos.
  • Organización de cuerda de violín (violin string organization): Mantener una organización afinada y en buen estado, pero sin ninguna flexibilidad.
  • Parálisis del análisis (analysis paralysis): Dedicar esfuerzos desproporcionados a la fase de análisis de un proyecto, eternizando el proceso de diseño iterando sobre la búsqueda de mejores soluciones o variantes.
  • Peligro moral (moral hazard): Aislar a quien ha tomado una decisión a raíz de las consecuencias de la misma.
  • Sistema de cañerías (stovepipe): Tener una organización estructurada de manera que favorece el flujo de información vertical, pero inhibe la comunicación horizontal.
  • Te lo dije (I told you so): Permitir que la atención se centre en que la desoída advertencia de un experto se ha demostrado justificada.
  • Gallina de los huevos de oro (cash cow): Pecar de autocomplacencia frente a nuevos productos por disponer de un producto legacy muy lucrativo.

Relación alfabética de otros antipatrones[editar]

Véase también[editar]

Enlaces externos[editar]

  • C2.com (antipatrones) Portland Pattern Repository's Wiki