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

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

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

我使用的一个重要启发是 Single Responsibility Principle . 它使类具有很好的内聚性。在某些情况下,我使用类在代码行中的大小作为启发式,以便更仔细地查看一个类是否有多个职责。在我的 current project 我注意到,在编写Java时,大多数类的长度都不到100行,通常当大小接近200行时,类会做许多不相关的事情,可以将其拆分,以获得更集中的内聚类。

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

我通常只会“按需”重构,也就是说,如果我看到代码中存在具体的、直接的问题。

• 由于复制和复制,更改的位置太多;粘贴
• 需要更改的硬编码内容
• 方法/类太大,无法理解

我有时会看到代码似乎有问题,我想修改,但如果这个领域目前还没有开发出来,我会抵制这种冲动。

我想听听那些把重构作为日常事务的人的经历。你如何阻止自己在重要功能上浪费太多时间?

Cyclomatic_complexity 确定下一步需要重构的代码。

我用 Source Monitor 当复杂性指标超过8.0时,通常会重构方法。