为什么 Code Review 总是让人不爽

没人看的 Review

最让人不爽的是，你辛辛苦苦写了个 PR，提交了 Review，结果没人看。

你等了半天，还是没人看。你催了一下，还是没人看。你又在群里催了一下，终于有人看了，但只是点了个 Approve，连代码都没看。

这种感觉就像你做了顿饭，结果没人吃。你问他们为什么不吃，他们说："看起来不错，但我现在不饿。"

更让人不爽的是，如果代码出问题了，他们会说："这个代码不是 Review 过了吗？" 你只能说："是的，但没人真的看过。"

太较真的 Review

另一种让人不爽的情况是，Review 的人太较真。

你写了个函数，他要求你改命名。你改了命名，他要求你加注释。你加了注释，他要求你改格式。你改了格式，他要求你改逻辑。

你问他："这个改动有必要吗？" 他说："代码质量很重要。" 你问他："这个改动会影响功能吗？" 他说："代码质量很重要。"

你只能改。改完之后，他又提了新的意见。你继续改，他又提了新的意见。你继续改，他又提了新的意见。

最后，你改了一堆无关紧要的东西，但核心功能还是那样。你问他："现在可以合并了吗？" 他说："再改一下这个。"

这种感觉就像你写了篇文章，结果编辑要求你改标点符号。你改了标点符号，他又要求你改段落。你改了段落，他又要求你改句子。你改了句子，他又要求你改标点符号。

太敷衍的 Review

还有一种情况是，Review 的人太敷衍。

你写了个 PR，他看了一眼，说："看起来不错，合并吧。" 你问他："这个逻辑有问题吗？" 他说："应该没问题。"

你问他："这个性能有问题吗？" 他说："应该没问题。" 你问他："这个安全有问题吗？" 他说："应该没问题。"

你只能合并。合并之后，代码出问题了。你问他："你不是 Review 过了吗？" 他说："我只是看了一眼，没仔细看。"

这种感觉就像你做了道菜，结果客人尝了一口，说："看起来不错，应该好吃。" 然后就不吃了。

为什么 Code Review 总是让人不爽

我觉得 Code Review 总是让人不爽，主要有这几个原因：

1. 时间成本

Code Review 需要时间。看代码需要时间，提意见需要时间，改代码需要时间，再 Review 需要时间。

如果 Review 的人很忙，他可能没时间仔细看。如果 Review 的人不忙，他可能会太较真。

而且，Review 的时间成本是隐性的。你花了一个小时 Review，但别人看不到。你花了一个小时改代码，但别人也看不到。

2. 责任不清

Code Review 的责任不清。如果代码出问题了，是谁的责任？是写代码的人，还是 Review 的人？

如果写代码的人说："这个代码是 Review 过的。" Review 的人说："我只是看了一眼，没仔细看。" 那责任是谁的？

如果 Review 的人说："这个代码有问题。" 写代码的人说："这个代码是 Review 过的。" 那责任又是谁的？

3. 标准不一

Code Review 的标准不一。有的人要求严格，有的人要求宽松。有的人关注性能，有的人关注可读性。

你写了个 PR，A 看了说："这个命名不好。" 你改了命名，B 看了说："这个逻辑有问题。" 你改了逻辑，C 看了说："这个格式不对。"

你改了一堆东西，但每个人关注的点都不一样。你问他们："这个代码现在可以合并了吗？" 他们说："再改一下这个。"

4. 沟通成本

Code Review 的沟通成本很高。你提了个意见，他可能不理解。他解释了一下，你可能还是不理解。

你问他："为什么要这样改？" 他说："代码质量很重要。" 你问他："这个改动会影响功能吗？" 他说："代码质量很重要。"

你只能改。改完之后，他又提了新的意见。你继续改，他又提了新的意见。

怎么让 Code Review 不那么让人不爽

虽然 Code Review 总是让人不爽，但我觉得还是可以改进的：

1. 明确责任

Code Review 的责任要明确。如果代码出问题了，是谁的责任？是写代码的人，还是 Review 的人？

我觉得应该是写代码的人。Review 的人只是帮忙检查，不是保证代码没问题。如果代码出问题了，责任应该是写代码的人。

2. 统一标准

Code Review 的标准要统一。团队要有统一的代码规范，Review 的时候按照规范来。

如果规范里没有的，就不要要求改。如果规范里有的，就必须改。

3. 控制时间

Code Review 的时间要控制。不要花太多时间在无关紧要的改动上，也不要花太少时间在重要的代码上。

如果 Review 的时间超过 30 分钟，可能就有问题了。要么是代码太复杂，要么是 Review 的人太较真。

4. 及时沟通

Code Review 的沟通要及时。如果提了意见，要及时解释。如果改了代码，要及时反馈。

不要拖。拖得越久，沟通成本越高。

最后

Code Review 理论上是个好东西，但实际上总是让人不爽。但我觉得，只要改进一下，还是可以让它不那么让人不爽的。

关键是，要明确责任，统一标准，控制时间，及时沟通。如果这些做到了，Code Review 就不会那么让人不爽了。

当然，如果这些都做不到，那 Code Review 还是会让人不爽。但至少，我们知道问题在哪里了。