关于重构的文章很多。 我在这里试图做的是展示一个真实的例子，说明我们的团队如何解决该问题以及我们计划如何解决该问题。
几周前，我加入了某个博客项目。 在这种情况下，技术无关紧要。 在这里至关重要的是我们发现自己正在使用的代码质量以及我们面临的挑战。
代码质量
代码质量是可以衡量的。 这不应该只是特定开发人员的意见。 但是我们必须记住：
没有这样的代码，它不会随着时间的推移而更好地重写。
这只是说没有完美的代码而已。 这就是为什么我们需要标准来确定一段代码何时适合重构的原因。 我们还需要了解为什么即使我们知道我们的代码是不好的，我们也不只是不加考虑地重构事物。
作为软件工程师，我们经常陷入某种精神上，技术上的封闭。 我们非常关注代码的质量，要交付的功能以及要修复的错误，以至于我们忘记了一件非常重要的事情：我们还应该意识到我们正在从事的项目的业务层。 软件工程师是除了他们的技术和人际交往能力之外，还照顾他所工作的用户的人。 我们正在开发的功能，正在解决的错误-最终，这些事情对于我们的最终用户而言。 那么这种重构会为他们带来价值吗？
这将我们引向标准。 我们将问自己一些问题，给他们一个权重并进行评估。 格式如下：（ (weight) Question 。
给定您正在使用的部分代码的当前状态：
- （5）此代码容易出错吗？
- （3）我几乎没有要修复的错误-我将花费多少时间将自己的头放在代码本身上，以解决一个问题？
- （3）此代码可伸缩吗？ （考虑每个添加和可读性的复杂性）。
- （2）我将花费多少时间重构该块？
- （2）这种重构会给我带来风险吗？ 如果是这样，我如何防止它们？ （方案：复杂，不清楚的逻辑以及缺少测试和文档）
如您所见，这些问题很容易与我们的最终用户有关。 要么使他们面临风险，要么延迟错误修复或新功能。
仅添加具有肯定答案的问题的权重。
对于我来说，等于5的总和是开始将代码视为重构的候选代码的最小值，尤其是在第一个问题的答案是肯定的情况下。 如果结果为7+，那么肯定可以与您的团队交流并计划重构。
您可能认为这种方法是不必要的。 毕竟，您是一位经验丰富的工程师，并且您知道何时需要重写某些代码。 没错，结构化评估很容易向您的团队提出。 使用它，您可以透明地了解自己的工作以及如何解决重构问题。 不再有“因为我感觉如此”或“我只是看到这段代码很糟糕”的阴暗区域。 您还将发现自己首先在考虑是针对谁（除了您自己）。
试试看！
