您如何决定下一步合并/重构代码的哪些部分？

Question

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

Answer 1

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

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

我使用的一个重要启发式方法是Single Responsibility Principle。它使课程具有良好的凝聚力。在某些情况下，我在代码行中使用类的大小作为启发式，以便更仔细地查看，类是否具有多个职责。在我的current project中，我注意到在编写Java时，大多数类的长度都不到100行，而且当大小接近200行时，类会做很多不相关的事情，并且可以将它分开为了获得更有针对性的凝聚力课程。

Answer 2

每次我需要添加新功能时，我都会搜索已经存在的类似代码。一旦我找到这样的代码，我想重构它来解决原始任务和新任务。当然，我不是每次都决定重构 - 通常我会重复使用代码。

Answer 3

我通常只重构“按需”，即如果我看到代码的具体即时问题。

通常，当我需要实现新功能或修复错误时，我发现代码的当前结构使这很困难，例如：

• 因复制和粘贴而无法更改的地方
• 不合适的数据结构
• 需要更改的硬编码
• 方法/类太大而无法理解

然后我会重构。

我有时会看到代码似乎有问题而且我想改变，但如果该区域目前尚未开展工作，我会抵制这种冲动。

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

我想听听重构人员的经历。你如何阻止自己抛光太多，以至于你失去了重要功能的时间？

Answer 4

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

Answer 5

我使用Source Monitor并在复杂度指标大约为8.0时常规重构方法。