Existe um anti-padrão formal para descrever o cenário?

Algum código é escrito para gerar planilhas do Excel (Office Interop).

• O código tem um desempenho muito ruim.
  
  • Um subsistema é projetado para gerar os arquivos à noite. O desempenho não é uma preocupação à noite.
    • Uma função é criada para selecionar o arquivo correto entre os 100 arquivos disponíveis, dependendo do conjunto de parâmetros escolhido.
    • Como existem arquivos físicos, um sistema de arquivamento é adicionado para fazer backup desses arquivos (não há motivo para arquivar. Esses arquivos devem ser gerados rapidamente).
    • Este sistema não inclui um arquivo de configuração, mas possui uma função de "selecionador de servidor" codificada que simplesmente reflete no servidor em que o código está sendo executado.
    • Uma tarefa agendada é necessária para dar suporte e executar este serviço.

Isso se resume a um único problema. O código original tem um desempenho muito ruim para ser executado em um ambiente de produção.

Se o problema de desempenho tivesse sido resolvido, o subsistema e o sistema de arquivamento subsequente, "função de fábrica do seletor de arquivos", ponto de falha codificado e a manutenção da tarefa agendada e seu ponto de falha adicional não precisam existir.

Esta é uma "falha em cascata", se você desejar. O problema original levou a mais códigos ruins, mais soluções ruins e sobrecarga desnecessária. Existe um anti-padrão formal ou termo geral para descrevê-lo?

Fluxo de lava?

No jargão da programação de computadores, o fluxo de lava é um problema no qual o código de computador escrito em condições sub-ótimas é colocado em produção e adicionado enquanto ainda está em um estado de desenvolvimento.

No Perl Design Wiki: Lava Flow é "quando o código se espalha e se torna permanente, ele se torna um recurso arquitetônico da variedade arqueológica. As coisas são construídas sobre a estrutura sem questionar e sem esperança de mudar o que está por baixo delas. o código existente é visto como uma curiosidade histórica ".

Freqüentemente, colocar o sistema em produção resulta na necessidade de manter a compatibilidade com versões anteriores (já que muitos componentes adicionais agora dependem dele) com o design original e incompleto.

Os fluxos de lava geralmente são exacerbados por mudanças na equipe de desenvolvimento que trabalha em um projeto. À medida que os trabalhadores entram e saem do projeto, o conhecimento da finalidade dos aspectos do sistema pode ser perdido e, em vez de limpar essas peças, eles são contornados, aumentando a complexidade e a bagunça do sistema.

O fluxo de lava é considerado um antipadrão, um fenômeno comumente encontrado que leva a um design inadequado.

Não tenho certeza se isso é um anti-padrão. Como em todos os antipadrões, temos que aceitar sua palavra de que quem pensou que era uma boa ideia estava enganado, mas nesse caso isso parece plausível e eu aceitarei sua palavra, portanto esse não é o problema.

O problema é que, para ser útil, um antipadrão precisa descrever algum tipo de armadilha geral e como pode ser evitado. Nesse caso, acho que seria encontrar uma solução alternativa para o código que apresenta um desempenho ruim quando você poderia apenas ter feito um desempenho melhor.

O problema com isso como anti-padrão, IMHO, é que o conhecimento sobre isso parece improvável de ter muito valor. Quem quer que tenha feito isso provavelmente já entendeu que seria bom saber como fazê-lo funcionar melhor; portanto, eles não devem saber como fazê-lo. Portanto, ter ouvido falar da situação geral como antipadrão realmente não teria ajudado.

Quanto a um termo geral para descrevê-lo, "falha em cascata", como você sugeriu, funciona muito bem. O termo que eu gosto para pessoas não qualificadas em uma missão que não fazia sentido em primeiro lugar é caçar snark , mas isso parece muito duro para essa situação. (Mas, de alguma maneira, jogarei o link gratuitamente, pois é a melhor representação de uma empresa condenada que conheço).

Não sei se isso ajuda, mas a automação de escritório geralmente é um caso especial:

A automação de escritório geralmente é feita dessa maneira se for automatizada a partir de uma área de trabalho do usuário (especialmente para sites .net, porque os documentos de automação de escritório alertam corretamente que haverá vazamentos ruins nas ferramentas de interoperabilidade do escritório se elas forem executadas sem cabeça. forçados a escrever processos decapitados para gerar documentos de escritório com esse kit de ferramentas que chamamos de serviços de sacrifício porque você tinha que matá-los periodicamente para recuperar a memória.

Além do arquivamento que você está descrevendo, infelizmente, é uma prática recomendada em alguns casos.

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