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

Question

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

Answer 1

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

我使用代码味道和类似启发式技术来检测错误的代码，然后我会只要我注意到它解决它。我并没有任何检查表寻找问题 - 大多是一个感觉：“这个代码看起来杂乱无章”，然后推理就是为什么它是凌乱的，并找出一个解决方案。就像给一个更具描述性的名称变量或提取方法简单的重构只需要几秒钟。更密集的重构，诸如提取的一类，最多可能需要一个小时或两个（在这种情况下我可以离开一个TODO注释和后重构它）。

，我使用是单一职责原则一个重要的试探法。它使阶级很好的凝聚力。在某些情况下，我使用的代码作为一种启发式的行类的大小更仔细寻找，一类是否具有多重责任。在我的当前项目我注意到，编写Java时，大多数类将小于100行长，而且往往在尺寸接近200行，类做许多事情无关，并且可以将其分割，以便获得更集中的内聚类。

Answer 2

每个时间我需要添加新的功能，我搜索已有的代码，做类似的事情。一旦我发现这样的代码，我认为它重构解决这两个原始任务和新的。当然，我不决定每次重构 - 最常我重用的代码，因为它是

Answer 3

我通常只“按需”重构，即如果我发现代码存在具体的、直接的问题。

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

• 由于复制和粘贴，需要更改的地方太多
• 不合适的数据结构
• 需要更改的硬编码内容
• 方法/类太大而难以理解

那我就重构一下。

有时我会看到看起来有问题的代码，我想更改它们，但如果当前尚未处理该区域，我会抵制这种冲动。

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

我想听听那些经常进行重构的人的经验。如何阻止自己过度打磨而浪费时间来处理重要功能？

Answer 4

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

Answer 5

我使用源监视器和当所述复杂度量变为aboove 8.0左右常规重构方法