案例分析 | Google和Facebook如何做Code Review

只要代码所有权是一种责任，而不是权利，那么它对大型软件项目就是一种好实践。——乔梁

---

1. 必须做Code Review 

Google和facebook两个公司，上生产环境的代码至少有一个团队成员review。

假如晚上或周末修复生产环境的紧急问题，可以先上线，但代码需要注释为TBR（To Be Reviewed），并自动生成Review提醒，每天发邮件提醒作者有一个TBR没有解决。

2. Google的流程更严格 

与facebook相比，google的流程更多，也更正式一些。

Google有可读性资质审核过程，你需要在给定的编程语言上获得一个可读性特权，该特权在于：只有那些具备该特权的人评审通过的代码，才能进入代码库。

可读性是开发人员资质中的一个标记，代码审查系统检查你是否可以自己提交代码，或是需要额外的检查，以满足全公司范围的语言风格指南。

Facebook没有这个要求，尽管它也有代码规范。

3. 要求都明确 

正式代码评审流程都要求：在提交代码库之前，所有负面的评审建议必须解决掉。

在实际工作中，代码审查可能是反复进行的，直到获得批准前每个变更需要几个审阅者进行多次反复并不罕见。

在Google，通常使用PTAL（Please Take Another Look）缩写来请求下一轮评论，或使用LGTM（对我来说看起来不错）做为最终通过review的信号。

但在Facebook，虽然差不多，但还是宽松一些。

4. 都有自己的工具 

从工具上看， Google使用自己开发的工具。google 的一个工具开发者后来创建 了（www.reviewable.io），所以你也能看看这个工具。Facebook使用 Phabricator ，他们自己开发的，现在开源了。其作者也开了一个公司，来提供这个工具的定制化服务。Phabricator有一个很好的meme功能，在Facebook上至少在一些团队使用，这使得代码评论更加轻松。

总体而言，两家公司的代码审查流程都是帮助学习的，旨在提供高质量的代码。

加快code review流程，在google也挺困难的，因为很多产品是多地开发，评审者可能在另外的时区。