如何进行更好的代码审查

如果你参与的代码库有多个贡献者，你很可能需要参与代码审查。代码审查也称为在代码合并到主分支之前，对其他人的代码进行审核确认。

代码审查的理念非常合理。多一双眼睛，我们都能从中受益。它能帮助团队成员了解代码库中其他部分的上下文。理想情况下，它还能保持代码模式和选择的一致性，帮助后续人员快速上手。

然而，“代码审查”这个词常常会让听到它的人感到恐惧。经历过糟糕代码审查的人通常会将这种体验描述为令人沮丧或居高临下。我们不想让大家有这种感觉，所以让我们来谈谈如何成为一名优秀的代码审查员。

不该做什么

我们先来解释一下代码审查不是什么。

1. 代码审查不是人工校对。

如果某个语法不应该出现在你的代码库中，那就添加一条自动代码检查规则。手动检查既浪费时间又没什么实际价值。如果添加规则都不值得，那么在代码审查中指出它也可能没什么意义。如果你这么做了，那就显得吹毛求疵了。

1. 代码审查不是为了证明你有多聪明

代码审查的目的完全是为了帮助编写代码的人提升技能，并使你的代码库更加健壮。这与你的自尊心或炫耀你的知识无关。

那我该怎么做才是正确的呢？

既然这个问题已经解决了，我们就可以谈谈你应该怎么做了。

这是一场双向对话

是的，代码审查中确实存在权力动态。审查者可能职级更高，或者对当前代码库有更丰富的经验。原作者在权衡建议时可能会考虑到这一点，但作为审查者，你需要明白你的意见并非绝对真理。你可能缺乏上下文信息，或者误解了原作者的意图。

鉴于此，提出建议时最好多问问题。与其说“你应该用Y方法做”，不如说“你能说说你选择X的原因吗？大多数情况下我会用Y，这里有什么理由不用Y吗？”。通常情况下，这样也能达到同样的效果，但感觉更像合作交流，也让所有参与者都有机会学习。

这不仅仅关乎错误之处。

代码审查是异步的，但审查结果不必非得如此。其目的是提供反馈，而并非所有反馈都是负面的。说“太棒了！我以前不知道你还能这么做”同样有效，而且你应该这么说。这样可以平衡审查的整体基调，让作者清楚地知道自己在哪些方面可以改进，以及在哪些方面需要加倍努力。

并非所有事物都会造成阻碍。

这似乎与我上面关于“人工代码检查”的说法相矛盾。然而，并非所有东西都能通过代码检查来发现。命名就是一个很好的例子。有时，你可能有一些建议，这些建议并不会导致代码无法继续运行，但你仍然想记录下来。

将这些内容标记为“NB”（注：非阻塞性）是一种很好的方式，可以快速提供一些建议，供作者参考，但并非必须采纳。如果您有改进的想法，但又不太确定，或者您有疑问，但不想因为反复沟通而耽误功能开发，这种方法尤其有用。

我在寻找什么？

既然我们已经讨论了如何提供反馈，接下来就来谈谈应该反馈什么内容。如果代码审查不是为了指出语法改进，那它的目的是什么呢？

1. 整合点

是否存在可能与其他系统产生冲突的地方？是否需要其他人参与审查？是否需要进行同步讨论？请指出这些问题。

1. 误差边界

是否存在未考虑到或未处理的特殊情况？请讨论一下。务必在代码合并之前解决这些问题。

1. 不必要的膨胀

这段代码是否提议引入某种新的库或系统？它是否需要这样做？这值得讨论。

1. 模式偏差

你是否改变了在代码库其他地方处理此类功能或数据的方式？为什么？我们来讨论一下。

1. 可扩展性

这段代码的编写方式是否会在将来造成问题？即使你选择采取短期解决方案，也要尽早提出这个问题。

这并非一份详尽的清单，但应该能让你了解评论可以帮助缓解的几个令人担忧的领域。

提升你的团队水平

代码审查的目标是帮助团队提升水平，并改善代码库的长期健康状况。因此，请专注于为同事和自己创造学习机会。并且要不断练习——代码审查是一项技能。