Code Review 程序员的寄望与哀伤

Google 以一种强硬的姿态来制定关于 Code Review 的且应用于全公司范围内的规则，对任何人都不例外。即使面对团队中超自信且强大的程序员也无例外，要么遵守规则，要么离开组织。这一点从 C 语言和 Unix 的发明者、图灵奖得主、最具传奇性的程序员 Ken Thompson 在 Google 的趣事——作为 C 语言发明者之一因为没有参加 Google 的编程语言能力测试所以无法在 Google 提交 C 代码——从中可以一窥 Google 规则的强硬性。

所以像 Google 这样的公司对于 Code Review 属于高度认可且有公司制度和规则的强硬支持，再辅助自动检测和控制工具的严格执行，方能如此。这也属于一种严格的同步 Code Review，所谓同步就是必须要等待 Code Review 有了结果并无异议后方能提交或上线代码。

但要实施如此严格的同步 Code Review 似乎对大部分国内公司又感觉过于无奈，这需要公司制度、团队文化和技术工具三方面的支持。而在大部分以业务目标、KPI和绩效导向的公司，不说在制度和文化方面得到支持，能不被反对就不错了。关于这一点陈皓（@左耳朵耗子）写过一篇文章《从 Code Review 谈如何做技术》其中写到了在阿里实施 Code Review 遇到的各种文化上的阻碍和反对。而阿里已是国内顶级互联网公司，可见实施同步 Code Review 的路径并不简单。

如果实施同步 Code Review 如此困难，那么是否可以退而求其次，设计一种异步的 Code Review 方式呢？就像我们提升系统性能一样，把一些同步的串行调用变成异步的并行调用，按这个思路 YY 了以下场景。

程序员完成编码，提交测试，测试通过后就去上线发布，另一方面也组织并行的 Code Review。毕竟测试通过只能证明测试覆盖的场景无 bug，但可能代码实现并不优化和合理，而并行的 Code Review 即使发现了潜在问题依然来不及阻止本次上线，但可以为下次上线提供优化点或方向。另外在制度上把 Code Review 作为工程师的日常 KPI，比如：要求每周对其他同事的代码变动做 1～2 次 Review。

而 Review 的方式除了阅读代码，也可以为 Review 的代码提供 Unit Test 间接达到了结对编程的目的。为了确保代码确实被 Review 过需要工具支持，对 Review 过的代码进行签名，对不同的 Review 形式（签名表示读过，Unit Test 表示不仅读过还白盒测试过）进行分类统计，发布 Code Review 统计排行榜和覆盖分析。

以类似这样的方式，逐步培养起交叉 Code Review 的文化和氛围，同时也显性将 Code Review 纳入了程序员的工作业绩之中。一开始不必像同步 Code Review 一样对所有上线进行了阻塞，带来巨大的阵痛。当然这也依然是一个理想化的 YY 场景，实施起来依然需要克服不少困难和准备前提工具。

在另外在一篇叫《谷歌是如何做代码审查的》文章中，一位 Google 的工程师对 Code Review 的认识是：

代码审查的最大的功用是纯社会性的。
还有一个非常重要的好处，代码审查能传播知识。
而防止 bug 混入，这反倒是它最不重要的一点。

第一点是这么理解的，如果你在编程，而且知道一定将会有同事检查你的代码，那么你编程的姿势和态度都会完全不同。之间的微妙差异可类比于你是在为公司的内部系统编程，还是在给开源软件贡献代码。这是一个很有趣的视角，它其实反应了公司的制度和文化。

现实

以前尝试过要在团队内部做 Code Review，听说兄弟团队搞得不错，然后就一起交流经验，最后交流的重心就落在了应该选个什么好用的 Code Review 工具来做，如今想来这完全是舍本逐末了。

这就像以为有了好的编辑器（或 IDE）就能写出好的代码一样，事实就是有很多好用的 Code Review 工具我们依然做不好 Code Review。古龙小说《陆小凤》中有一段描述，记忆尤深：

西门吹雪：此剑乃天下利器，剑锋三尺七寸，净重七斤十三两。
叶孤城：好剑。
西门吹雪：的确是好剑。
叶孤城：此剑乃海外寒剑精英，吹毛断发，剑锋三尺三，净重六斤四两。
西门吹雪：好剑。
叶孤城：本就是好剑。

剑是好剑，但最好先成为像西门吹雪或叶孤城这样的好剑客，再来居高俯视、吹毛断发的谈剑是否是好剑。

即使在最差的环境下，完全没有人关心 Code Review 这件事。一个有追求的程序员依然可以做到一件事，自己给自己 review。就像写文章，我写完一篇文章从来不会立刻发布，而是从头脑中放下（unload），过上一段时间（也许是几小时、也许是几天）再自己重新细读一遍，改掉其中必然会出现的错别字或文句不通畅之处，甚或论据不充分或不准确的地方，因为我知道不管我写了多少文字，总还会有这些 bug，这就是给自己的 review。

即使如此，有时发出去的文章还是依然存在 bug，但总会比不 review 少了些。程序员在估算开发任务时也最好加上自己给自己 review 的时间，给自己 review 是一种自省，自我的成长总是从自省开始。

...

我提交了一段代码，却没人给我 review，稍后我自己给自己 review 了，得到了一段更好的代码和一个更好的自己。

---

写点程序世间的文字，画点生活瞬间的画儿。
微信公众号「瞬息之间」，遇见了不妨就关注看看。

（编辑：广州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!