¿Existe un anti patrón designado para el software desarrollado históricamente? [cerrado]

¿Existe un antipatrón que describa un sistema de software desarrollado históricamente en el que varios desarrolladores simplemente agregaron nuevas funciones al sistema pero nadie realmente estuvo atento a la arquitectura general ni se realizaron refactorizaciones?

Creo que esto sucede cuando la gerencia / el cliente solicita nuevas funciones constantemente y nadie refactoriza nada, sino que solo agrega lo que otros desarrolladores han hecho antes.

Una razón también podría ser que el desarrollador está abrumado con el sistema de software y no comprende realmente cómo funciona actualmente y luego simplemente agrega / pega su código al final (en lugar de refactorizar el código y cambiarlo).

Entonces, con el tiempo, cada vez es más difícil mantener el sistema.

(Me pregunto si hay imágenes de este tipo de antipatrón para que esto sea más claro para la gente de programación, como un automóvil que fue construido simplemente agregando más y más funciones sin pensar en el diseño general. Como si alguien tuviera la necesidad de remolcar remolques mientras viaja hacia atrás y luego un ingeniero simplemente suelda una barra de remolque en la parte delantera del automóvil. Trabajo hecho. Pero ahora la cubierta ya no se abre).

Te refieres a la deuda técnica .

Todos acumulamos deudas técnicas en los productos que desarrollamos con el tiempo; La refactorización es una de las formas más comunes y efectivas de reducir esta deuda técnica, aunque muchas empresas nunca pagan su deuda técnica. Estas compañías tienden a encontrar su software extremadamente inestable en el futuro, y la deuda técnica se vuelve tan espantosa que no puede pagarla gradualmente, porque tomaría demasiado tiempo pagarla de esa manera.

La deuda técnica tiene el término, porque sigue los mismos comportamientos de la deuda. Obtiene la deuda, y mientras continúe gastando (creando funciones) y sin pagar esa deuda, solo crecerá. Al igual que la deuda, cuando es demasiado grande, llega a puntos en los que puede desear deshacerse por completo con tareas peligrosas como reescrituras completas. También, como la deuda real, ya que se acumula hasta cierto punto, dificulta su capacidad de gastar (crear funciones) por completo.

Solo para incluir otro término en la mezcla, la cohesión se refiere a qué tan bien encaja un sistema, micro al nivel de línea o macro al nivel del sistema. Un sistema altamente cohesivo hará que todas sus piezas encajen muy bien y parezca que un ingeniero lo escribió todo. Su referencia anterior a alguien simplemente pegando su código hasta el final estaría violando la cohesión de ese sistema.

Gestión de la deuda técnica

Hay muchas maneras de administrar la deuda técnica, aunque, como la deuda real, el mejor enfoque es pagarla con frecuencia. Desafortunadamente, como la deuda real, ocasionalmente es una mejor idea acumular más por un período corto, donde, por ejemplo, el tiempo para comercializar una característica puede duplicar o triplicar sus ingresos. La parte difícil es sopesar estas prioridades en competencia, así como identificar cuándo el ROI de las deudas no vale la pena para la función dada frente a cuándo lo es.

Entonces, a veces vale la pena acumular la deuda por un período corto, pero rara vez es así, y como con todas las deudas, cuanto más corto sea el período, mejor. Entonces, eventualmente (preferiblemente rápidamente ) después de acumular deuda técnica, debe pagarla, estos son enfoques comunes:

• Refactorización
  • Esto le permite tomar fragmentos de código que solo se dieron cuenta de que estaban fuera de lugar a la mitad o después de que se completó la implementación, y colocarlos en su lugar correcto (o uno más correcto de todos modos).
• Volver a escribir
  • Esto es como una bancarrota. Limpia la pizarra, pero comienzas con nada y tienes la oportunidad de cometer los mismos errores, o incluso los más grandes. Enfoque de alto riesgo y alta recompensa para la deuda técnica, pero a veces es su única opción. Aunque rara vez es así, muchos te lo dirán.
• Descripción de la arquitectura
  • Este es más un enfoque activo de pago de deuda técnica. Esto se logra al tener a alguien con autoridad sobre los detalles técnicos para detener una implementación, independientemente de los planes y cronogramas del proyecto para garantizar que acumule menos deuda técnica.
• Congelación de código
  • Congelar el código de cambios puede permitirle respirar donde su deuda no sube ni baja. Esto le da tiempo para planificar su enfoque para reducir la deuda técnica con la esperanza de tener el ROI más alto en su enfoque.
• Modularización
  • Esto es como un enfoque de nivel 2 que solo está disponible cuando emplea ya sea Arquitectura general para tener un sistema modular o Refactorización para avanzar hacia uno. Cuando tiene un sistema modular, puede pagar la deuda en partes enteras del sistema de forma aislada. Esto le permite realizar reescrituras parciales , refactorizaciones parciales , así como minimizar la tasa de deudas técnicas acumuladas porque el aislamiento mantiene la deuda solo en aquellas áreas donde entraron las características, en lugar de extenderse por todo el sistema.
• Pruebas automatizadas
  • Las pruebas automatizadas pueden ayudarlo a administrar su deuda técnica, ya que pueden ayudarlo a identificar puntos problemáticos en el sistema, con suerte antes de que la deuda en esas áreas haya crecido mucho, pero incluso después del hecho, aún pueden informar a los ingenieros de esas áreas peligrosas. Puede que no se haya dado cuenta. Además, una vez que tiene pruebas automatizadas, puede refactorizar más libremente las cosas sin preocuparse por romper demasiado. No porque los desarrolladores no rompan las cosas, sino porque descubrirán cuándo lo hacen , confiar en probadores manuales en sistemas altamente endeudados tiende a tener un historial pobre para encontrar problemas.

Su descripción se ajusta a Foote and Big Ball of Mud de Yoder :

En los últimos años, varios autores ... han presentado patrones que caracterizan las arquitecturas de software de alto nivel ... En un mundo ideal, cada sistema sería un ejemplo de uno o más de esos patrones de alto nivel. Sin embargo, esto no es así. La arquitectura que realmente predomina en la práctica aún no se ha discutido: la GRAN BOLA DE BARRO .

Una gran bola de barro está estructurada al azar, desparramada, descuidada, con cinta adhesiva y alambre de seguridad, selva de código de espagueti. Todos los hemos visto. Estos sistemas muestran signos inconfundibles de crecimiento no regulado y reparaciones repetidas y convenientes. La información se comparte de manera promiscua entre elementos distantes del sistema, a menudo hasta el punto en que casi toda la información importante se vuelve global o duplicada. Es posible que la estructura general del sistema nunca haya estado bien definida. Si lo fuera, puede haberse erosionado más allá del reconocimiento. Los programadores con una pizca de sensibilidad arquitectónica evitan estos atolladeros. Solo aquellos que no se preocupan por la arquitectura y, tal vez, se sienten cómodos con la inercia de la tarea cotidiana de reparar los agujeros en estos diques que fallan, se contentan con trabajar en tales sistemas ...

¿Por qué un sistema se convierte en una GRAN BOLA DE BARRO? A veces, los sistemas grandes y feos emergen del CÓDIGO DE CAMINO . THROWAWAY CODE es un código rápido y sucio que estaba destinado a ser usado solo una vez y luego descartado. Sin embargo, dicho código a menudo adquiere vida propia, a pesar de la estructura informal y la documentación deficiente o inexistente. Funciona, entonces, ¿por qué arreglarlo? Cuando surge un problema relacionado, la forma más rápida de abordarlo podría ser modificar convenientemente este código de trabajo, en lugar de diseñar un programa general adecuado desde cero. Con el tiempo, un simple programa desechable engendra una GRAN BOLA DE BARRO.

Incluso los sistemas con arquitecturas bien definidas son propensos a la erosión estructural. El ataque implacable de los requisitos cambiantes que atrae cualquier sistema exitoso puede socavar gradualmente su estructura. Los sistemas que alguna vez estuvieron ordenados se vuelven demasiado grandes a medida que el CRECIMIENTO DE PIECEMEAL permite gradualmente que los elementos del sistema se desarrollen de manera incontrolada.

Si tal expansión continúa sin cesar, la estructura del sistema puede verse tan comprometida que debe abandonarse. Al igual que con un vecindario en descomposición, se produce una espiral descendente. Dado que el sistema se vuelve cada vez más difícil de entender, el mantenimiento se vuelve más costoso y más difícil. Los buenos programadores se niegan a trabajar allí. Los inversores retiran su capital. Y, sin embargo, al igual que con los vecindarios, hay formas de evitar, e incluso revertir, este tipo de declive. Como con cualquier otra cosa en el universo, contrarrestar las fuerzas entrópicas requiere una inversión de energía. La gentrificación de software no es una excepción. La forma de detener la entropía en el software es refactorizarla. Un compromiso sostenido con la refactorización puede evitar que un sistema se hunda en una GRAN BOLA DE BARRO ...

• ... Uno de los enemigos más efectivos del lodo es la luz del sol. Someter el código complicado a una flecha de escrutinio puede preparar el escenario para su refactorización, reparación y rehabilitación. Las revisiones de código son un mecanismo que se puede usar para exponer el código a la luz del día.