refactoring - 您如何决定接下来应该合并/重构代码的哪些部分？

Question

您是否使用任何指标来决定接下来应该合并或重构代码的哪些部分（类、模块、库）？

Answer 1

我不使用任何可以自动计算的指标。

我使用代码气味和类似的启发式方法来检测不良代码，然后我会在注意到它后立即修复它。我没有任何查找问题的清单 - 主要是一种直觉，“这段代码看起来很乱”，然后推理为什么它很乱并找出解决方案。简单的重构，例如为变量提供更具描述性的名称或提取方法只需几秒钟。更密集的重构，例如提取一个类，可能需要一两个小时（在这种情况下，我可能会留下 TODO 评论并稍后重构）。

我使用的一个重要启发式方法是单一责任原则。它使课程具有很好的凝聚力。在某些情况下，我使用代码行中类的大小作为一种启发式方法，以便更仔细地查看一个类是否具有多种职责。在我目前的项目中，我注意到在编写 Java 时，大多数类的长度会少于 100 行，并且通常当大小接近 200 行时，该类会做很多不相关的事情，并且可以将其拆分，所以以获得更集中的凝聚力课程。

Answer 2

每次我需要添加新功能时，我都会搜索执行类似操作的现有代码。一旦我找到这样的代码，我就会考虑重构它以解决原始任务和新任务。当然，我不会决定每次都重构 - 大多数情况下我会按原样重用代码。

Answer 3

我通常只“按需”重构，即，如果我看到代码有一个具体的、直接的问题。

通常当我需要实现一个新特性或者修复一个 bug 时，我会发现当前的代码结构让这变得很困难，例如：

• 由于复制和粘贴而改变的地方太多
• 不合适的数据结构
• 需要改变的硬编码的东西
• 方法/类太大而无法理解

然后我会重构。

我有时会看到看起来有问题并且我想更改的代码，但是如果该区域当前没有被处理，我会抵制这种冲动。

我认为重构是在面向未来的代码和做不会真正产生任何直接价值的事情之间取得平衡。因此，除非我看到具体的需要，否则我通常不会重构。

我想听听那些将重构视为例行公事的人的经验。您如何阻止自己过多地打磨而浪费时间来开发重要功能？

Answer 4

我们使用Cyclomatic_complexity来识别接下来需要重构的代码。

Answer 5

当复杂度指标超过 8.0 时，我会使用Source Monitor并定期重构方法。