历史增长的软件是否有命名的反模式？[关闭]

是否有一种反模式来描述一个历史悠久的软件系统，其中多个开发人员只是向系统添加了新功能，但没有人真正关注整个体系结构，也从未进行过重构？

我认为，当管理人员/客户不断要求新功能并且没有人重构任何东西而只是增加其他开发人员以前所做的事情时，就会发生这种情况。

原因还可能是开发人员对软件系统不知所措，并不真正了解它当前的工作方式，然后只是在最后添加/粘上了他的代码（而不是重构和更改代码）。

因此，随着时间的推移，维护系统变得越来越困难。

（我想知道是否有针对这种反模式的图片，以使所有编程人员都无法清楚了解它-就像一辆通过添加越来越多的功能而无需考虑整体设计而制造的汽车。就像有人需要拖曳拖车时向后骑，然后工程师只是将牵引杆焊接到汽车的前部。工作已经完成。但是现在，前围不再打开了。）

您指的是技术债务。

随着时间的推移，我们开发的产品都会产生技术债务；重构是减少技术债务的一种非常常见且有效的方法，尽管许多公司从未偿还其技术债务。这些公司往往会在未来几年内发现其软件极度不稳定，并且技术债务变得如此可怕，以至于您无法增量支付，因为以这种方式支付的时间太长了。

技术债务具有术语，因为它遵循相同的债务行为。您将承担债务，并且只要您继续花费（创建功能）并且不还清债务，债务就只会增加。就像债务一样，当债务过大时，您可能会希望通过完全重写等危险任务完全摆脱债务。就像真实债务一样，由于累积到一定程度，它也完全阻碍了您的花费（创建功能）的能力。

只是在混合中添加了另一个术语，内聚力是指系统（微观到线路级别，或者宏观到系统级别）的融合程度。一个高度凝聚力的系统将其所有部分很好地装配在一起，看起来就像一位工程师将其全部编写出来一样。您上面提到的只是将他们的代码粘贴到最后的人将违反该系统的凝聚力。

管理技术债务

管理技术债务的方法有很多，尽管像真实债务一样，最好的方法是经常偿还债务。不幸的是，像真实债务一样，在短时间内产生更多的收入有时是一个更好的主意，例如，某功能的上市时间可能会使您的收入翻倍或翻三番。棘手的部分是权衡这些相互竞争的优先级，并确定何时债务不值得给定功能的ROI和何时获得。

因此，有时短期内累积债务是值得的，但情况并非如此，就所有债务而言，期限越短越好。因此，在累积技术债务后，最终（最好是迅速）您必须偿还这些债务，这是常见的方法：

• 重构
  • 这使您可以将仅在实现过程中或实现完成后才被误放置的代码片段放入正确的位置（或放置在更正确的位置）。
• 改写
  • 这就像破产。它可以使一切顺利，但是您一无所有，也有机会犯同样的错误，甚至更大的错误。高风险，高回报的技术债务解决方案，但有时这是您唯一的选择。尽管这种情况很少见，但很多人会告诉你。
• 架构概述
  • 这更多是一种积极的技术债务偿还方法。这是通过让具有技术细节权限的人员暂停实施而不必考虑项目计划和时间表的，以确保它减少了技术债务。
• 代码冻结
  • 冻结更改代码可以让您喘口气，以免债务增加或减少。这使您有时间计划减少技术债务的方法，并希望获得最高的投资回报率。
• 模块化
  • 这就像第2层方法，仅当您使用“架构概述” 已具有模块化系统或“重构”向其中一个迁移时可用。如果拥有模块化系统，则可以以孤立的方式偿还整个系统的债务。这使您可以进行部分重写，部分重构，并最大程度地降低技术债务产生的比率，因为隔离仅使债务保留在功能进入的那些区域，而不是分散在系统中。
• 自动化测试
  • 自动化测试可以帮助您管理技术债务，因为它们可以帮助您识别系统中的问题点，希望在这些领域的债务变得非常大之前就可以了，但是即使在这样的情况下，他们仍然可以使工程师意识到这些危险区域，可能还没有意识到。此外，一旦获得了自动化测试，就可以更自由地重构事物，而不必担心破坏太多。不是因为开发人员不会破坏事情，而是因为他们会发现他们何时会破坏事情，所以在负债累累的系统中依靠手动测试人员往往很难发现问题。

您的描述符合Foote和Yoder的《泥巴大球》：

在过去的几年中，许多作者...提出了表征高级软件体系结构的模式...在理想的世界中，每个系统都是一个或多个此类高级模式的示例。然而，事实并非如此。在实践中实际上占主导地位的体系结构尚待讨论：BIG BALL OF MUD。

一大堆泥浆是杂乱无章的结构，蔓延的，马虎的，风管带和吊索，意大利面条代码丛林。我们都看过他们。这些系统显示出无节制的增长和反复的，方便的修复的明显迹象。信息在系统的各个远方元件之间混杂地共享，常常到几乎所有重要信息都变得全局或重复的地步。系统的总体结构可能从未明确定义过。如果是这样的话，它可能已经侵蚀得面目全非。带着建筑敏感性的程序员回避了这些泥潭。只有那些对架构不关心的人，也许对那些在故障堤坝上打孔的日常琐事感到厌倦的人感到满意，才愿意在这样的系统上工作...

为什么系统变成泥泞的大球？有时，THROWAWAY CODE会出现大型，丑陋的系统。THROWAWAY CODE是一种快捷方式代码，只能使用一次，然后丢弃。但是，尽管结构随意，文档不完善或不存在，但这样的代码通常都可以独立生存。它有效，那么为什么要解决它？当出现相关问题时，解决该问题的最快方法可能是方便地修改此工作代码，而不是从头开始设计适当的通用程序。随着时间的流逝，一个简单的一次性程序会产生一个大泥球。

甚至具有定义明确的体系结构的系统也容易受到结构侵蚀。任何成功的系统所吸引的不断变化的要求的不断猛烈攻击会逐渐破坏其结构。过去整洁的系统随着PIECEMEAL GROWTH的增长而变得过长，逐渐允许系统的元素以不受控制的方式蔓延。

如果这种蔓延持续不减，那么系统的结构将受到严重损害，必须将其丢弃。就像一个腐烂的社区，随之而来的是螺旋式下降。由于系统变得越来越难理解，因此维护变得更加昂贵且更加困难。好的程序员拒绝在那里工作。投资者撤资。但是，与邻里一样，有很多方法可以避免甚至减少这种下降。与宇宙中的任何其他事物一样，抵抗熵力需要投入能量。软件高级化也不例外。在软件中阻止熵的方法是对其进行重构。对重构的持续承诺可以防止系统陷入巨大的泥潭之中。

• ...阳光是泥土最有效的敌人之一。对复杂的代码进行仔细检查，可以为其重构，修复和恢复奠定基础。代码审查是一种可以使代码暴露在日光下的机制。