是否有正式的反模式来描述这种情况？

编写了一些代码来生成Excel电子表格（Office Interop）。

• 该代码的性能非常差。
  
  • 子系统设计为在晚上生成文件。晚上不必担心性能。
    • 创建一个函数以根据一组选定的参数从100个不同的可用文件中选择正确的文件。
    • 由于存在物理文件，因此添加了归档系统来备份这些文件（没有理由存档。这些文件应即时生成）。
    • 该系统不包含配置文件，而是具有硬编码的“服务器选择器”功能，该功能仅在运行代码的服务器上反映。
    • 要支持和运行此服务，计划任务是必需的。

这归结为一个问题。原始代码的性能太差，无法在生产环境中运行。

解决了性能问题后，就不需要子系统和随后的归档系统，“文件选择器工厂功能”，硬编码故障点以及计划任务的维护及其增加的故障点。

如果您愿意，这是“级联失败”。最初的问题导致更多错误代码，更多错误解决方案和不必要的开销。是否有正式的反模式或通用术语来描述它？

熔岩流？

在计算机编程术语中，熔岩流是一个问题，其中在次优条件下编写的计算机代码投入生产并在仍处于发展状态的情况下被添加到其中。

在Perl Design Wiki中：熔岩流是“当代码……喷涌而出并成为永久性时，它便成为考古学上的一种建筑特征。事物毫无疑问地建在结构的顶部，并且不希望改变其下面的内容。现有代码被视为一种历史的好奇心。”

通常，将系统投入生产会导致需要保持与原始，不完整设计的向后兼容性（因为现在有许多其他组件依赖于此）。

从事项目的开发团队的变更通常会加剧熔岩流。随着工作人员进入和退出项目，可能会丢失有关系统各方面目的的知识，而不是清理这些部分，而是要进行处理，从而增加了系统的复杂性和混乱性。

熔岩流被认为是反模式，这是导致设计不良的常见现象。

我不确定这是否是反模式。与所有反模式一样，我们必须相信您，无论是谁认为这是一个好主意，都是错误的，但是在这种情况下，这听起来似乎是合理的，我会相信您的话，所以这不是问题。

问题在于，要使用反模式，必须描述某种一般性陷阱以及如何避免这种陷阱。在这种情况下，我想这将是寻找一种变通方法，使代码在您本可以使其性能更好时表现不佳。

作为反模式，恕我直言，问题在于，了解它似乎不太有价值。大概谁做的人都已经知道，知道如何使它更好地工作会很好，因此他们一定不知道如何做。因此，了解作为反模式的一般情况并不会真正有帮助。

就描述它的一般术语而言，正如您所建议的，“级联失败”效果很好。术语我喜欢不合格的人关在一个使命没有意义的第一个地方是斯纳克的狩猎，但似乎对这种情况太苛刻。（但是无论如何，我都会无意中抛出该链接，因为这是我所知道的注定失败的企业的最好描述）。

不确定是否有帮助，但是办公自动化通常是一种特殊情况：

如果必须在用户桌面上自动进行办公自动化（通常是针对.net网站，因为办公自动化文档正确警告您，如果它们无头运行，则办公互操作性工具中会存在严重的泄漏），通常以这种方式进行办公自动化。被迫使用该工具包编写无头程序来生成Office文档，我们将其称为牺牲服务，因为您必须定期杀死它们以收回内存。

不幸的是，在某些情况下，除了存档所描述的内容外，这是最佳做法。

链接：http：//support.microsoft.com/kb/257757