大家的公司的 Code Review 都是怎么做的？遇到过哪些问题？

本文整理自知乎。

Code Review，就是代码评审，简称 CR。CR 的目的除了提高代码质量，提前发现 Bug 外，还包括统一团队的代码规范，比如经常会碰到有人说你这个变量命名不对，或者这里缩进不应该用tab，甚至这里应当多加一个空白行。

类似架构或者设计模式这样的“大”问题，我个人觉得并不适合在 code review 的时候去讨论。如果这方面有问题，那说明之前的设计评审（ Design Review，简称 DR ）没有做好，或者有可能根本没有做 DR。

像微软内部，我所知道的范围内，所有代码都是需要CR 的。具体的规则可能每个部门各不相同，比如有的部门给每个组件规定几个 owner，改到那块代码必须找至少一个owner做 CR。有的部门还规定每次 CR 至少要有一个资深级别以上的码农参与，等等。

从工具上来说，现在的码农还是比较幸福的了。Gerrit 就不错，快捷键，对话式体验等。

N 年以前做 CR 就不是这样的。作者自己做个 patch 发到邮件上，其实就是一个 Diff，评审人就对着这个 Diff 看。有意见的就拿个小本本记下来：某某行号，有某某问题，然后再发个邮件沟通。

微软后来的车库计划（利用员工闲暇时间随便做点什么的一个计划），有人做了一个新的CR工具，叫 CodeFlow，极大改善了我们做 CR 的体验，病毒式地传播到了公司各个部门，可以算是车库计划最成功的项目了。 

大致界面是这样的。

CodeFlow 主要把 CR 的过程做成了一个聊天式的体验，你对哪段代码有意见，直接选取那段代码然后加个comment，对方就需要对此做出回应。比如你说这个函数名字起得不够优雅，对方可以采取你的意见修改并把这个comment设置成fixed；当然他也可以认为没必要改而设成won't fix；Reviewer 也可以继续和他撕下去。

当作者按照意见修改了一遍代码后，他可以发出一个新的CR，然后评审人在新的CR 基础上可以再次提出新的意见。

最后每个评审人可以设置此次CR的状态，比如：正在进行中，等作者反馈，signed off 就表示通过了。

现在这些功能都已经在 Visual Studio里面整合了。

另外，CR还可以用来当众撕逼啊。在微软，通常整个团队都是optional的Reviewer，大家都能看见。听说：以前有两个老板，一个没事写了点代码，另一个就要去review，然后双方进行了一场旷日持久的热烈讨论（si bi）。你问我作为普通观众的感受，那基本上就像是在看知乎大V互撕差不多。后来author方败北离职，当然，那段代码确实比较有问题。

基本的点都被翻来覆去说过了没什么新鲜的：

• 首要目的是保证代码可读性，一致性，其次是设计讨论和知识分享。肉眼找代码错儿的这事儿，人类干不来。

• 所有代码改动都要过CR, 就算你是代码owner也要CR。CR 通过了，就直接提交进统一代码树的head（就是进主干）。

• CR通过 Web工具进行，但更重要的是：有各种各样的工具先做预提交检查（presubmit checks）, 机器能找到问题（比如格式不符合style guide）的话，连CR请求是发不出去的，或者直接在CR工具上提一堆 fix suggestion，糊你一脸。这样，人类可以专注于更难搞的问题。

• Google工程师每周发CL(代码改动单位）中位数是 3， 80% 工程师每周CL数不超过 7（怎么显得谷歌好像很闲的样子……）

• 工程师每周做代码评审， CL中位数是4， 80% 工程师每周CR 的CL数不超过 10个。读略多于写, 说明 Reviewer 不会集中到少数几个 senior 队员而是相对平摊。

• CR 流程完成时间中位数 4 小时。

• 35% 的变更只涉及 1 个文件，95% 的变更涉及不超过 10 个文件。

• 变更行数的中位数是 24行，超过 10% 的变更只改了 1 行。

• 75% 以上的变更只有一个评审人。