如何调用系统的模式或体系结构，当你在一个地方修复某些东西时，你后来发现某些东西在其他地方被破坏了？
我没有想出一个简洁的名字。当您对自己或其他人正确行事失去信心时，系统就会出现这种情况。你觉得你已经失去了对复杂性的控制。在最坏的情况下，如果没有全面的测试覆盖或严格的测试，您就不敢进行任何更改。你开始讨厌你的工作的模式，因为每次轻微的代码更改都需要花费大量的时间和精力，你开始用静态类型学习语言，或者只是开始做更多“愚蠢的编码”，希望“聪明的思考” coverage will warn you about mistakes。
在解决软件开发中的这个问题之前，需要以简洁的方式进行定义。也许你知道一个关于行话文件的条目或已经在你的团队中创造了这个定义？
需要这个词来描述糟糕的建筑动作。通常它被称为spaghetti code或smelly code，但它不是仅支持此hole patching开发过程的系统的确切描述。这里的主要特征是every fix is likely the cause of new issue。有时这个过程是无止境的，因为新人无法看到真正的原因，并在路上一遍又一遍地重复错误重新发明轮子等等。
答案 0 :(得分：2)
Michael Feathers在他的“有效地使用遗留代码”中对此有一些好处。
他提到了反模式“霰弹枪手术”，这显然与您所描述的系统相匹配：如果您想引入更改，您必须触摸系统中的许多不同位置，因为概念是没有明确设计，也没有隔离。通常复制粘贴orgies导致当前系统。
他还说“基本上有两种方法可以使用代码”：
他总结了编辑和祈祷的方法：
这是行业标准，包括以下步骤：
- 认真规划变更
- 了解您要修改的代码
- 开始进行更改
- 四处看看是否一切正常（这一步非常重要）
- 重复3和4直到完成
WEWLC归结为将所有没有测试覆盖率的代码归咎于 遗留代码 。与“封面和修改”相比，你有（单位）测试。
最后他关于 遗留代码困境 ：“的观点，在进行更改之前我们应该进行测试，但为了进行测试，我们必须更改代码”。
答案 1 :(得分：1)
虽然它在实践中经常发生，但没有通用名称，因为这些错误主要是由于这些错误而发明的：单元和集成测试。
我称之为'脆弱'或'脆弱的系统架构'，没有自动化测试。
HTH Thomas