Code Review Best Practices: How to Review (and Be Reviewed) — cod-ai.com

我仍然记得那次几乎让我放弃软件工程的代码审查。那是2012年，我刚在一家金融科技初创公司工作了六个月，刚刚提交了我认为是我们支付处理模块出色重构的代码。高级工程师的审查回馈了47条评论——大多数是“这不对”的变体，没有任何解释。我花了三天的时间重写代码，却发现下一次审查又回来了39条与之前相矛盾的评论。那次经历教会了我一个重要的教训：糟糕的代码审查不仅浪费时间——它们摧毁团队，扼杀创新，并驱赶有才华的工程师。

快进十二年，我现在是一个C轮SaaS公司的首席工程师，在这里我审查了超过8000个拉取请求，并指导了50多位工程师关于有效的代码审查实践。我亲眼看到如何改变代码审查文化可以将缺陷率降低60%，将入职时间缩短一半，并将代码审查从一个令人畏惧的瓶颈转变为团队最强大的学习工具。蓬勃发展的团队和勉强生存的团队之间的差异，往往取决于他们如何看待这一单一实践。

为什么代码审查比你认为的重要得多

让我们从一些可能令您惊讶的数字开始。SmartBear在2023年的一项研究发现，代码审查可以在缺陷进入生产之前发现60-90%的缺陷——远比任何单独的自动化测试套件更有效。但这里是大多数人忽略的地方：代码审查的真正价值不仅仅在于防止缺陷。根据我对我们团队五年间的指标分析，我发现有效的代码审查带来了四个随时间累积的关键好处。

首先，知识分配。当我加入我现在的公司时，我们面临经典的“英雄开发者”问题——三名工程师理解80%的代码库，而其他人则害怕触及任何超出他们狭窄领域的内容。在实施结构化代码审查实践后，我们测量到了在18个月内跨团队代码贡献增加了340%。工程师们不仅在审查代码；他们还在学习模式，理解架构，并建立跨整个系统工作的信心。

第二，质量一致性。在建立明确的审查标准之前，我们的代码库是一幅不同风格、模式和质量水平的拼贴画。你可以通过查看代码就知道哪个团队写了哪个模块。审查文化转型后，我们的静态分析分数提高了73%，更重要的是，新工程师在入职的第一个月报告对代码质量期望的信心提高了4倍。

第三，规模化的指导。我无法对我团队中的每一位工程师进行个人指导，但通过深思熟虑的代码审查，我可以同时与数十人分享见解。一条关于我们选择特定并发模式的解释良好的审查评论，在我们的内部文档中被引用了89次，节省了无数小时的重复解释。

第四，或许是最被低估的：代码审查是您团队健康的早期预警系统。当审查周转时间激增，当评论线程变得激烈，当某些工程师停止参与——这些都是煤矿中的金丝雀。我通过关注代码审查的模式，提前几周发现了职业倦怠、人际冲突和架构分歧。

审查者的心态：这不是为了证明自己是对的

在我作为高级工程师的第一年后，我学到的一个令人不安的事实是：技术上的正确并不意味着你是一个好的代码审查员。我在捕捉缺陷、识别性能问题和执行最佳实践方面表现良好——但我团队的士气却在下降。我的审查批准率仅为12%，这意味着88%的PR需要更改。我认为我在保持高标准。我的经理认为我在制造瓶颈，并让人们害怕提交代码。

“糟糕的代码审查不仅浪费时间——它们摧毁团队，扼杀创新，并驱赶有才华的工程师。”

转变发生在我开始将代码审查视为对话而不是判断的时候。我开始写“我对这里的可测试性有担忧——您考虑过使用依赖注入吗？如果这对您来说不熟悉，很乐意一起解决这个问题。”技术内容是相同的，但框架改变了一切。两个月内，我的批准率上升到了67%，但更重要的是，初始提交的质量提高了40%，因为工程师们在提交之前敢于提问。

我现在教授的心态转变是这样的：作为审查员，您的工作并不是要证明您比作者聪明。您的工作是帮助发布高质量代码，同时让作者成为更好的工程师。这意味着在批评之前要理解上下文，在提要求之前要提问，并认识到往往有多个有效的解决方案可供任何问题选择。

我使用一种我称之为“三个审查反馈层级”的思维框架。第一级问题是客观问题：缺陷、安全漏洞、违反既定团队标准。这些问题需要更改。第二级问题是强烈建议：性能问题、可维护性改进、更好的模式。这些问题需要讨论。三级问题是个人偏好：变量命名、代码组织、风格选择。这些问题应当少见并清楚标记为非阻塞。

问题在于，大多数审查员将所有问题都视为一级问题。我见过20条评论的审查线程，其中18条关于缩进偏好和变量命名，只有2条涉及实际的竞争条件。当一切都是关键时，没有什么是关键的。我现在力求在我的审查中达到大约70%的一级问题、25%的二级问题和5%的三级问题。如果我发现自己写了超过两个三级评论，我会停下来问自己，我是否真的在改善代码，还是仅仅是在强加我的偏好。

撰写有效审查评论的艺术

我分析了数千条代码审查评论，以了解哪些反馈是有效的，哪些会造成混淆和冲突。这种区别通常取决于结构和具体性。像“这无法扩展”这样的评论是技术反馈，但毫无用处。它没有解释问题，没有建议解决方案，也没有帮助作者学习。与此相比：“这个O(n²)循环在我们预计在Q3达到10k+记录时将变得有问题。请考虑在此处使用哈希映射进行O(n)查找。这是我们在支付处理器中使用的类似模式：[链接]。”