“累积代码”气味

在这篇文章中，我们将讨论可以从源代码的历史中识别出的代码中可能存在的问题。我们称这种“气味” 累积代码 。这篇文章中使用术语“ 累积代码”来描述主要通过添加而很少更改而对现有代码进行修改的代码。本质上，每项更改都是将新代码添加到同一模块中，而重构本来是更好的选择。通过添加新的代码段来引入新功能，这些代码段将更改或扩展现有代码的行为。

请注意，与其他代码气味不同，累积代码不是直接从代码中识别的，而是从源代码的历史中识别的。

如何检测累积的代码气味？

就像我们说的那样，只需查看版本控制系统中的代码历史记录就可以轻松检测到累积代码。如果文件的历史记录遵循此模式，则可以将代码视为累积代码（或至少有累积代码的味道）：

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语句，它们覆盖新的情况或修改旧的情况。这些添加可能是开发人员为了快速完成任务而使用的难看的hack和快捷方式。累积代码往往会使方法/函数和类变大，并且在大多数情况下，代码在多个位置重复，这降低了代码的简洁性。因此，随着时间的流逝，代码的可维护性往往会降低，而新功能的实现则需要更长的时间。

如果我们退后一步，我们可以看到这些问题只是更普遍问题的影响。累积代码意味着维护代码的团队内部存在沟通问题 。正如我们在上一节中看到的，每个开发人员都在不同的时间点添加了她的功能。这清楚地表明，团队成员没有交流如何重组代码以采用新的变更，可能有用的模式，新的变更是否修改了方法/功能/类/组件/模块的性质，并且应该分开（以符合“ 单一职责原则” ），或者更糟糕的是，新功能是否已经存在于系统中的其他位置。

由于缺乏沟通，实施新功能的开发人员未考虑重构代码，因为她担心会破坏已有的功能。这也称为对改变的恐惧！ 这不是一个不寻常的情况下，特别是如果代码库是相当老的测试套件可能不是那么可靠（更多关于这个话题在这个职位）或甚至没有存在的。因此，如果开发人员的新引入的更改破坏了现有功能，则他们将没有反馈。

累积代码也可能是团队始终以“消防模式”工作的结果。在这种情况下，开发人员会尝试找到解决方案的最短路径以完成任务，然后他们最终会使用hack和快捷方式来添加完成任务所需的功能。当然，当将来需要对这些黑客进行调试或扩展时，必须支付此解决方案的成本。团队可以在有限的时间内（由于紧急情况）在消防模式下工作，但是当该模式成为默认模式时，这意味着代码库即将到期。消防员开发人员可以在短期内解决紧急问题，将他们视为英雄，但是如果不支付所产生的技术债务，他们的做法将使代码库处于危险之中。

沟通问题的影响

通信问题可能导致代码具有难以理解的巨大方法和类，大量重复以及晦涩的代码可能存在的所有问题。 没有团队成员对系统如何工作以及应如何扩展有相同的理解 。因此，个人重新实现可能具有微小差异或没有差异的现有功能，而不是重新使用已经存在的功能，这并不罕见。正如Martin Fowler在“谁需要架构师？”中所述，对系统的普遍理解与系统的体系结构高度相关。

沟通对于团队（不仅是开发人员团队，还是整个团队）的成功至关重要。在上一篇文章中，我们讨论了团队内部沟通的重要性以及它如何影响团队的绩效，从而影响团队的成功。 团队应该在沟通结构上投入大量资金。

如何通过代码改善沟通？

交流并不总是物理/语言甚至是同步的。该代码也是开发者沟通他们的解决方案相互介质，正如我们在讨论这个职位。当团队成员不在一起时，通过代码进行交流总是更具挑战性，并且需要付出额外的努力。干净的代码可以改善沟通！

除了干净的代码外，理想情况下，应该有一些测试可以验证代码的行为，从而消除（或减少）对更改的恐惧。测试是最好的沟通方式（更多有关测试的信息）。一年前写过一段代码的开发人员可能忘记了一些极端情况，但是测试却没有。文档页面可能已过时，但测试不能。 测试不要说谎！

您的VCS为您提供了一个有趣的故事！

版本控制系统跟踪我们代码库中发生的一切。通过看的提交，我们可以提取的信息，有关如何团队的工作方式了一些非常有用的片段（不，控制线不是开发者的工作效率的度量！）。我们还可以看到随着新功能的引入或容量需求的变化，我们的系统一直在发展。

遗留系统有很多这样的历史，这总是令人兴奋的！

进一步阅读

From: https://hackernoon.com/cumulative-code-smell-6d5344646c46