论坛累积计时代码ubb_“累积代码”气味

论坛累积计时代码ubb

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

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

如何检测累积的代码气味&＃xff1f;

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

在这种情况下&＃xff0c;新提交只是添加&＃xff0c;没有&＃xff08;或相对很少&＃xff09;删除/修改。 通常&＃xff0c;随着新功能的出现&＃xff0c;代码会不断发展。 演进不只是在现有代码中添加新代码。 随着我们更好地了解系统的工作方式&＃xff0c;设计和体系结构决策也会发生变化&＃xff0c;并且这些决策可能会更改代码的结构。 前面的示例表明&＃xff0c;在过去的六年中&＃xff0c;可能没有做出这样的决定&＃xff0c;并且代码不断增长。 当系统扩展时&＃xff0c;将修改代码&＃xff0c;以便可以适应新代码。 肯·汤普森 &＃xff08; Ken Thompson &＃xff09;的一句名言说&＃xff1a; “我最富有成效的日子之一就是扔掉了1000行代码。”

请注意&＃xff0c;提到的模式是一种指示或轻微的气味 &＃xff0c;表明我们的代码可能有问题。 显然&＃xff0c;有一些代码遵循这样的模式&＃xff0c;既灵活又干净。 例如&＃xff0c;添加新方法的接口代码可以遵循这种模式&＃xff0c;而不是累积的。

累积代码是一件坏事吗&＃xff1f;

为了回答这个问题&＃xff0c;我们必须考虑实际的累积代码指示什么。 累积代码表示违反了开放/关闭原则 。 开放/封闭原则指出“软件实体&＃xff08;类&＃xff0c;模块&＃xff0c;功能等&＃xff09;应为扩展而开放&＃xff0c;但为修改而封闭”&＃xff0c;因此&＃xff0c;由于已将新功能与现有功能一起添加&＃xff0c;因此该代码肯定不会因修改而封闭。功能&＃xff0c;降低我们软件的灵活性。 通常&＃xff0c;这是一堆if语句&＃xff0c;它们覆盖新的情况或修改旧的情况。 这些添加可能是开发人员为快速完成任务所使用的难看的hack和快捷方式。 累积代码往往会使方法/函数和类变大&＃xff0c;并且在大多数情况下&＃xff0c;代码在多个位置重复&＃xff0c;这降低了代码的简洁性。 因此&＃xff0c;随着时间的流逝&＃xff0c;代码的可维护性往往会降低&＃xff0c;而新功能的实现则需要更长的时间。

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

由于缺乏沟通&＃xff0c;实施新功能的开发人员未考虑重构代码&＃xff0c;因为她担心会破坏已经起作用的内容。 这也称为对改变的恐惧&＃xff01; 这不是罕见的情况&＃xff0c;特别是如果代码库很旧并且测试套件可能不那么可靠&＃xff08;本文中有关此主题的更多信息 &＃xff09;甚至根本不存在。 因此&＃xff0c;如果开发人员的新引入的更改破坏了现有功能&＃xff0c;则他们将没有反馈。

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

沟通问题的影响

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

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

如何通过代码改善沟通&＃xff1f;

交流并不总是物理/语言甚至是同步的。 正如我们在本文中所讨论的&＃xff0c;代码也是开发人员彼此交流解决方案的媒介。 当团队成员不在同一地点时&＃xff0c;通过代码进行交流总是更具挑战性&＃xff0c;需要付出额外的努力。 干净的代码可以改善沟通&＃xff01;

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

您的VCS为您提供了一个有趣的故事&＃xff01;

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

遗留系统有很多这样的历史&＃xff0c;这总是令人兴奋的&＃xff01;

进一步阅读

1. 谁需要建筑师&＃xff1f; 马丁·福勒 &＃xff08; Martin Fowler&＃xff09;
2. 代码闻起来
3. 开闭原则
4. 单一责任原则
5. 让代码说话&＃xff01;
6. 团队文化的重要性
7. 片状测试-一场永无止境的战争
8. 首先测试

翻译自: https://hackernoon.com/cumulative-code-smell-6d5344646c46

论坛累积计时代码ubb