Antipatrones III: Antipatrones generales de diseño de software

Gracias al trabajo de recopilación de varias personas (que recuerde ahora al menos Ahmad, Miguel, Jesús, Juanma y María) puedo postear esto ;).

Los antipatrones son soluciones erróneas que presentan más problemas que los que solucionan.

Son una extensión natural a los patrones de diseño.

Los antipatrones pueden dividirse en 3 grandes categorías:

  • Desarrollo de Software: Se centran en problemas asociados al desarrollo de software a nivel de aplicación.
  • Arquitectura de Software: Se centran en la estructura de las aplicaciones y componentes a nivel de sistema y empresa.
  • Gestión de Proyectos de Software: En la ingeniería del software, más de la mitad del trabajo consiste en comunicación entre personas y resolver problemas relacionados con éstas. Los antipatrones de gestión de proyectos de software identifican algunos de los escenarios clave donde estos temas son destructivos para el proceso de software

Antipatrones generales de diseño de software

Nombre Concepto
Database as an IPC ¿Se recurre a la Base de Datos para la comunicación entre procesos? La forma adecuada de hacerlo sería comunicación directa entre procesos
Blob ¿Existen objetos grandes (más de 60 atributos y métodos) que hacen que gran parte de funcionalidad esté codificada en un objeto que hace todo y que hace el código muy difícilmente mantenible? La forma adecuada de hacerlo sería dividirlo en otros objetos que interactuasen entre sí.
BOMQ (Batch over MQ). ¿Se abusa del empleo de integración basada en mensajes para realizar transferencias esporádicas de gran tamaño en segundo plano (procesos batch)?
Magic pushbutton ¿Se tiende a introducir mucha lógica de negocio en los métodos de interacción, por ejemplo servicios web, implementando los resultados de las acciones del usuario en términos no suficientemente abstractos? La buena práctica en este caso sería delegar esta lógica a otros métodos/clases de utilidad
Race hazard ¿Queda siempre claro cómo puede reaccionar el sistema si se da una sucesión de eventos determinada? Este hecho debería estar estudiado y controlado en todos los casos
Input kludge ¿Está especificado y controlado el hecho de entradas inválidas en el sistema en todos los casos?
Gas factory ¿Existe algún caso en que el diseño es muy intrincado sin necesidad? Para solucionar esto habría que estudiar los casos bajo sospecha y teniendo en cuenta la funcionalidad rediseñarlo.
Big ball of mud ¿El diseño técnico está estructurado?
Interface bloat. ¿Existen interfaces tan potentes que resultan muy difíciles de implementar?
Abstraction inversion ¿Están, en todos los casos, expuestas las funcionalidades que necesita el usuario, evitando así que se reimplementen a más alto nivel?
Ambiguous viewpoint ¿Existen, en el diseño del sistema aspectos sin concretar que pueden causar futuras reimplementaciones y en algún caso tener que rediseñar alguna parte?
Re-coupling ¿Son, todas las dependencias entre objetos necesarias o por el contrario podría eliminarse alguna?
Stovepipe system ¿Se ensamblan, en el sistema, componentes poco relacionados, lo que lo hace difícilmente mantenible?

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 )

Google photo

Estás comentando usando tu cuenta de Google. 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 )

Conectando a %s