累积代码”气味
“累积代码”气味
原文：https://medium.com/hackernoon/cumulative-code-smell-6d5344646c46
source: wikimedia
在这篇文章中，我们将讨论代码中的一个可能的问题，这个问题可以从源代码的历史中识别出来。我们把这种【气味】称为累积码。术语累积代码在这篇文章中被用来描述那些主要通过添加而很少通过修改现有代码来改变的代码。当重构是一个更好的选择时，每个变化本质上都是在同一个模块中添加的新代码。通过添加一段改变或扩展现有代码行为的新代码来引入新功能。
注意，与其他的代码气味不同，累积代码不是直接从代码中识别的，而是从源代码的历史中识别的。
如何检测累积的代码气味？
正如我们所说，通过查看版本控制系统中的代码历史，可以很容易地检测出累积代码。如果文件的历史遵循这种模式，那么代码可以被认为是累积的(或者至少有累积代码的味道):
Line, developer, commit date
101 dev1 2011/3/1
102 dev1 2011/3/1
...
133 dev1 2011/3/1
134 dev2 2013/6/7
135 dev2 2013/6/7
...
146 dev2 2013/6/7
147 devN 2017/12/16
148 devN 2017/12/16
...
149 devN 2017/12/16在这种情况下，新的提交只是添加，没有(或相对较少)删除/修改。通常，随着新特性的出现，代码会不断发展。进化不仅仅是在现有的代码上增加新的代码。随着我们对系统如何工作有了更好的理解，设计和架构决策也会改变，这些决策可能会改变我们代码的结构。前面的例子表明，在过去的六年中，很可能没有做出这样的决定，代码一直在增长。当一个系统增长时，代码被修改，以便它能适应新的代码。Ken Thompson 说过一句名言:“我最有效率的一天是扔掉 1000 行代码。”
请注意，提到的模式是一种指示或一种轻微的气味，表明我们的代码可能有问题。显然，有些代码遵循这样的模式，既灵活又简洁。例如，添加新方法的接口的代码可以遵循这种模式，而不是累积的。
累积代码是坏事吗？
要回答这个问题，我们必须考虑累积代码实际表示什么。累积代码表示违反了打开/关闭原则。开放/封闭原则表明软件实体(类、模块、函数等)。)应该对扩展开放，但对修改关闭",所以肯定这段代码不会对修改关闭，因为新功能已随现有功能一起添加，使我们的软件灵活性降低。这通常是一堆 if 语句，涵盖新的情况或修改旧的情况。这种添加可能是开发人员为了快速完成任务而采用的丑陋手段和捷径。累积的代码会使方法/函数和类变得很大，在大多数情况下，代码会在几个地方重复，这降低了代码的整洁度。因此，随着时间的推移，代码的可维护性越来越差，新功能的实现需要更长的时间。
如果我们退一步，我们可以看到，这些问题只是一个更普遍的问题的影响。累积代码意味着在维护代码的团队中有一个沟通问题。正如我们在上一节中看到的，每个开发人员在不同的时间点添加她的特性。这清楚地表明，团队成员没有沟通如何重构代码以适应新的变化，什么模式可能是有用的，新的变化是否修改了方法/函数/类/组件/模块的性质，并且应该是独立的(为了符合)或者更糟糕的是，新的功能是否已经存在于系统的其他地方。
由于缺乏沟通，实现新功能的开发人员没有考虑重构代码，因为她害怕破坏已经工作的东西。这也被称为对变化的恐惧！这并不是一个不寻常的情况，尤其是如果代码库相当旧，测试套件可能不那么可靠(在这篇文章中有更多关于这个主题的内容)或者根本不存在。因此，如果开发人员新引入的变更破坏了现有的功能，他们没有反馈。
累积代码也可能是一个团队不断以“救火模式”工作的结果在这种情况下，开发人员试图找到解决方案的最短路径来完成任务，他们最终使用技巧和快捷方式来添加完成任务所需的功能。当然，当这些黑客将来需要调试或扩展时，这种解决方案的成本是必须支付的。对于一个团队来说，在有限的时间内以救火模式工作是可以的(由于紧急情况),但是当这种模式成为默认模式时，这意味着代码库已经到了生命的尽头。消防员开发人员可以在短期内被视为英雄，因为他们解决了紧急问题，但是如果产生的技术债务没有得到偿还，他们的实践将代码库置于危险之中。
沟通问题的影响
交流问题会导致代码中包含大量难以理解的方法和类，大量的重复以及晦涩代码可能存在的所有问题。没有一个团队成员对系统如何工作以及如何扩展有相同的理解。因此，对于个人来说，重新实现现有的功能而不是重用已经存在的功能是很常见的，这些功能可能有轻微的差异或没有差异。正如马丁·福勒在 [中所说，“谁需要架构师？”](http://files.catwell.info/misc/mirror/2003-martin-fowler-who-needs-an-architect.pdf)
沟通对于团队的成功至关重要(不仅仅是开发团队，而是整个团队)。在之前的一篇文章中，我们讨论了团队内部沟通的重要性，以及它如何影响团队的表现，进而影响团队的成功。团队应该高度投资于沟通结构。**
如何通过代码改善沟通？
交流并不总是身体/语言的，甚至不总是同步的。代码也是开发人员相互交流解决方案的媒介，正如我们在本文的中所讨论的。当团队成员不在一起时，通过代码的交流总是更具挑战性，需要一些额外的努力。干净的代码可以改善交流！
除了干净的代码之外，理想情况下，应该有可以验证代码行为的测试，以消除(或减少)对变更的恐惧。测试是最好的交流方式(更多关于测试的信息请见这篇文章)。一个几年前编写了一段代码的开发人员可能会忘记一些极限情况，但是测试不会。文档页面可能会过时，但是测试不会。测试不会说谎！**
你的 VCS 有一个有趣的故事给你！
版本控制系统跟踪我们的代码库中曾经发生过的事情。通过查看提交，我们可以提取一些关于团队工作方式的非常有用的信息(不，LoC 是而不是开发人员生产力的度量标准！).我们还可以看到，随着新功能的出现或容量需求的变化，我们的系统是如何发展的。
遗留系统有很多这样的历史，这总是令人兴奋的！