¿Existe un antipatrón formal para describir el escenario?

Parte del código se escribe para generar hojas de cálculo de Excel (interoperabilidad de Office).

• El código funciona muy mal.
  
  • Un subsistema está diseñado para generar los archivos por la noche. El rendimiento no es una preocupación por la noche.
    • Se crea una función para elegir el archivo correcto de los 100 archivos diferentes disponibles dependiendo de un conjunto de parámetros elegido.
    • Debido a que existen archivos físicos, se agrega un sistema de archivo para hacer una copia de seguridad de estos archivos (No hay razón para archivar. Estos archivos deben generarse sobre la marcha).
    • Este sistema no incluye un archivo de configuración, sino que tiene una función de "selección de servidor" codificada que simplemente refleja el servidor en el que se ejecuta el código.
    • Una tarea programada es necesaria para soportar y ejecutar este servicio.

Esto se reduce a un solo problema. El código original funciona demasiado mal para ejecutarse en un entorno de producción.

Si se hubiera resuelto el problema de rendimiento, el subsistema y el sistema de archivo subsiguiente, la "función de fábrica del selector de archivos", el punto de falla codificado y el mantenimiento de la tarea programada y su punto de falla adicional no tenían necesidad de existir.

Esto es un "fallo en cascada" si se quiere. El problema original condujo a más código malo, más soluciones malas y gastos generales innecesarios. ¿Existe un antipatrón formal o un término general para describirlo?

¿Flujo de lava?

En la jerga de programación de computadoras, el flujo de lava es un problema en el que el código de computadora escrito en condiciones subóptimas se pone en producción y se agrega mientras aún está en un estado de desarrollo.

De Perl Design Wiki: Lava Flow es "cuando el código ... vomita y se vuelve permanente, se convierte en una característica arquitectónica de la variedad arqueológica. Las cosas se construyen sobre la estructura sin cuestionamientos y sin la esperanza de cambiar lo que está debajo de ellos. el código existente es visto como una curiosidad histórica ".

A menudo, poner el sistema en producción produce la necesidad de mantener la compatibilidad con versiones anteriores (ya que muchos componentes adicionales ahora dependen de él) con el diseño original incompleto.

Los flujos de lava a menudo se ven exacerbados por los cambios en el equipo de desarrollo que trabaja en un proyecto. A medida que los trabajadores entran y salen del proyecto, se puede perder el conocimiento del propósito de los aspectos del sistema y, en lugar de limpiar estas piezas, se resuelven, aumentando la complejidad y el desorden del sistema.

El flujo de lava se considera un antipatrón, un fenómeno comúnmente encontrado que conduce a un diseño deficiente.

No estoy seguro de que esto sea un antipatrón. Al igual que con todos los antipatrones, debemos creer que quien pensó que era una buena idea se equivocó, pero en este caso eso suena plausible y aceptaré su palabra, así que ese no es el problema.

El problema es que para ser útil, un antipatrón necesita describir algún tipo de trampa general y cómo se puede evitar. En este caso, supongo que sería encontrar una solución alternativa para el código que funciona mal cuando podría haberlo hecho funcionar mejor.

El problema con eso como un antipatrón, en mi humilde opinión, es que saberlo parece poco probable que tenga mucho valor. Quien haya hecho esto presumiblemente ya entendió que sería bueno saber cómo hacerlo funcionar mejor, por lo que no deben haber sabido cómo hacerlo. Entonces, haber escuchado acerca de la situación general como un antipatrón realmente no habría ayudado.

En cuanto a un término general para describirlo, "falla en cascada", como sugirió, funciona bastante bien. El término que me gusta para las personas no calificadas en una misión que no tenía sentido en primer lugar es cazar sarcástico , pero eso parece demasiado duro para esta situación. (Pero de alguna manera arrojaré el enlace de forma gratuita, ya que es la mejor representación de una empresa condenada que conozco).

No estoy seguro si esto ayuda, pero la automatización de la oficina es a menudo un caso especial:

La automatización de oficina generalmente se realiza de esta manera si debe automatizarse desde el escritorio de un usuario (especialmente para sitios web .net porque los documentos de automatización de oficina le advierten correctamente que habrá fugas en las herramientas de interoperabilidad de oficina si se ejecutan sin cabeza. Cuando estaba forzados a escribir procesos sin cabeza para generar documentos de oficina con ese conjunto de herramientas que llamamos servicios de sacrificio porque había que asesinarlos periódicamente para recuperar la memoria.

Además del archivado, lo que está describiendo es desafortunadamente una mejor práctica en algunos casos.

Enlace: http://support.microsoft.com/kb/257757