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