design-patterns - method - oop design patterns
¿Cómo superar el anti-patrón “Big Ball of Mud”? (7)
¿Qué hace que un programa de computadora se convierta en una http://en.wikipedia.org/wiki/Big_ball_of_mud ? ¿Es posible recuperarse de este anti-patrón? ¿Existen métodos comprobados de refactorización que puedan aplicarse?
En mi caso, un elemento de mi software está cayendo en este patrón fue una "solución temporal", hace aproximadamente dos años, que constantemente ha agregado nuevas características (siempre con urgencia) a expensas de una reescritura.
Si no causa problemas de gestión, no tienen ningún incentivo para cambiarlo. "Sí, cuando tenga tiempo el mes que viene, puede reescribirlo, pero ahora solo necesitamos que funcione para este caso". Tan pronto como la nueva característica está en, la reescritura se olvida.
He estado explicando durante dos años que es un código pobre (lo que implica que hay errores ocultos en él).
Esto podría arrojar algo de luz sobre la pregunta original.
http://en.wikipedia.org/wiki/Big_ball_of_mud
Una gran bola de barro es un sistema de software que carece de una arquitectura perceptible. Aunque no son deseables desde el punto de vista de la ingeniería, tales sistemas son comunes en la práctica debido a las presiones empresariales y la rotación de desarrolladores. Por lo tanto, han sido declarados un diseño anti-patrón.
La única vez que tuve que lidiar con un escenario "BBOM", básicamente tuvimos que revisar los requisitos con los usuarios e inferir lo que pudimos del código horrendo. Al igual que con todos los BBOM, el problema no se manifiesta hasta que se necesita algún tipo de mantenimiento / mejora. (No hay lujo de revisión de código en esta tienda, el criterio fue, lamentablemente, "¿hace lo que quiere?") Y el "autor" ya no existe.
Refactorizar ni siquiera era posible en este caso.
La cita pertinente del artículo de wikipedia que responde al tuyo es:
Se recomienda encarecidamente a los programadores que controlan una gran bola de proyecto de barro que la estudien y entiendan lo que logra, y que la utilicen como una base suelta para un conjunto formal de requisitos para un sistema bien diseñado que podría reemplazarlo.
Los BBOM con los que me he encontrado normalmente se creaban orgánicamente, en un proceso darwiniano. Es algo parecido a esto:
Inicialmente, se crea un sistema (no está diseñado) y está mal documentado.
Los recursos originales continúan creando más estragos en otros lugares, por lo que ni siquiera hay una historia oral para este sistema "heredado".
Se trae sangre fresca. Estos desarrolladores intentan descubrir el funcionamiento de varias partes del sistema, pero es como varios hombres ciegos que intentan entender al elefante cuando uno agarra la cola, uno la pierna y el tronco. Hacen cambios pero nunca se sienten realmente seguros de ellos.
De esta manera, un sistema "evoluciona" por selección natural ciega, pero paralelamente a esto, se encuentra una evolución de los errores más intratables y no reproducibles que persisten precisamente porque permanecen bajo la pantalla del radar, hasta que, por supuesto, aparecen en la instalación de un cliente.
Siempre atribuí el término (BBOM) a una base de código en la que "todo depende de todo" y es difícil encontrar el código que desea cambiar, y cuando lo hace, tiene que cambiar todo. El lugar para que vuelva a funcionar. Necesita toda la base de código para probar una sola clase / archivo modificado. El tío Bob llama a esto el Síndrome de la mañana siguiente ( here bajo el Principio de Dependencias Acíclicas).
Es bastante inevitable que una base de código se convierta (ejem) en un BBOM en ausencia de un control de dependencia básico, ya que los desarrolladores que no ven más que el código que están editando actualmente no pueden hacerlo.
Una gran bola de barro normalmente ocurre debido a uno de los siguientes:
Cambio de requisitos s: Usted diseña una solución con un conjunto de requisitos, que con el tiempo cambia y ahora, probablemente está atendiendo a una audiencia diferente que desea utilizar el mismo producto con requisitos ligeramente diferentes. Usted hornea esos requisitos en el mismo producto y termina con un BBOM.
Cambio de desarrolladores : el producto original ha sido creado por un grupo de desarrolladores con ciertas suposiciones de diseño y arquitectura que no son del todo evidentes para un grupo completamente nuevo de desarrolladores que "toman el control" del producto para su mantenimiento o desarrollo adicional. Los nuevos desarrolladores hacen sus propias suposiciones y, a lo largo del tiempo, el producto se degrada en una pila de basura que no se puede mantener.
Incompetencia : de los desarrolladores (desconocen los anti-patrones), la administración (demasiado exigente, la falta de conocimiento del producto) o los usuarios (no saben realmente lo que necesitan). Esto es difícil de resolver.
A veces, la mejor solución es simplemente reescribir la aplicación para satisfacer los nuevos requisitos. Pero este es normalmente el peor de los casos. La solución incómoda es detener todo desarrollo nuevo, comience escribiendo un conjunto de pruebas y luego rediseñe y rearchitect toda la solución. Sin embargo, esto podría llevar años, dependiendo del tamaño del producto.