Code Review应该怎么尬聊？

1 概述

国内各大公司实施 Code Review 有哪些经验呢，我猜你肯定好奇：

• Code Review 首要目的是磨子？
• Code Review 在开发流程中处于哈位置？比如有的是挑选一些代码 Review，有的是不 Review 不能上传，有的由团队成员自由发起……
• Code Review 采用的工具、过程是什么？
• Code Review 的过程中遇到过哪些问题？

2 Google Code Review 之道

Google新鲜热辣论文《Modern Code Review: A Case Study at Google》https://sback.it/publications/icse2018seip.pdf。

基本法都被翻来覆去，说了也没啥新鲜的：

• 首要目的是保证代码可读性，一致性，其次是设计讨论和知识分享。找错这事人类干不来；
• 所有代码改动都要过Code Review, 就算你是代码Owner. 过了Review直接提交进统一代码树的head；
• Review通过Web-based工具进行，但更重要的是有各种各样的工具作presubmit checks, 机器能找到问题（如格式不符合style guide）连review请求都发不出去，或直接在review上fix suggestion糊你一脸。人类可以专注于更难搞的问题。

有趣的是文章给了一些通过log分析拿到的

3 量化指标

• Google工程师每周发CL(代码改动单位）中位数是 3, 80% 工程师每周CL数不超过 7.（怎么好像显得国企企业生活挺混的样子😁）；
• 工程师每周review CL中位数是4, 80% 工程师每周CL数不超过 10。读略多于写, 说明 reviewer 不会集中到少数几个 senior 队员而是相对平摊；
• review流程完成时间中位数 4 小时；
• 35% 改动只涉及 1 个文件，95% 改动涉及不超过 10 个文件；
• 修改行数中位数是 24, 超过 10% 的改动只改了 1 行；
• 75% 以上的改动只有一个 reviewer。

论文认为跟其他公司相比，这都明显更加 light weight。这TMD和我亲身职业经历事实严重不符（国际企业真这么混日子吗？？？）

8d8fbf9382bbe819e14c3665e29d6a15.jpeg

可仔细一想！还是有道理，占据工程师大部分精力的都是：

• 少数几个难写的
• 或大的设计会起争议

这些的确需要多人review的CL, 但似乎也确实发国很多短、平、快的简单CL。总结来说，这数据其实是合理的！

4 结论

其实 Code Review 还可用来当众撕逼啊！因为通常整个团队都是optional reviewer，大家都能看见。以前有两个老板：

• 一个没事写了点代码
• 另一个就要去review

然后双方进行一场旷日持久的热烈讨论（si bi）。你问我作为普通观众的感受，那基本上就像是在看知乎大V互撕差不多。后来author方败北->离职，code确实比较有问题。