Google 的 Code Review 目标是不断提高 codebase 的质量，同时要求审阅者在代码的高质量和业务的推进之间做好权衡，两边的极端都不要走，并给出了一些 实战经验，下面我总结了下：

1. 设计

新增的几块代码是否有意义？代码的结构是否合理，应该放在 codebase 里还是抽离成组件？对系统的持续集成是否会造成印象？等等。

2. 功能

站在用户的角度和开发者的角度，从功能和代码块上去审阅功能的合理性，除此之外，还要考虑单从代码上看不到的问题，比如并发问题、UI 交互问题、死锁问题等等。

3. 复杂度

审查是否存在工程上的过度设计，鼓励解决当下的问题，不要对未来做过多的设计，因为未来（业务）充满了不确定性。

4. 测试

除非是紧急上线，一般情况下，都要求提交的代码有单元测试、集成测试和端对端测试，要确保测试用例正确、有意义、有效果。

5. 命名

开发者是否给所有的变量都准确命名？一个好的命名不应太长也不可过短，刚好让人看懂的长度最好了。

6. 注释

开发者写的注释除了他自己外其他看得懂么？所有的注释是否是有意义的？是否描述清楚了代码是干啥的？有一点需要强调：对于正则以及复杂的逻辑是必须加注释的。

7. 格式

这一块我觉得他讲的并不好，格式主要在工具层面通过 lint 来纠正，只不过格式之外会有一些团队的约定，需要人为去判断或者不好工具检测的部分，可以在 Code Review 的时候提出来。

8. 文档

相关的 README 或者文档自动生成工具是否补全，废弃的代码、文档是否删除等。

9. 每一行

确保每一行都仔细审阅，包括数据文件、自动生成的文件、大的数据结构描述等等，如果代码很难阅读，你应该提前告诉开发者注意这方面的问题，难阅读的代码，对任何人都是一样难阅读的，这种代码应该尽量避免出现。

10. 上下文

Code Review 工具一般只会展示 diff 的内容，有的时候，你需要阅读整个文件，以确保开发者的逻辑是有用的，站在系统层面去考虑，这段代码是否会带来复杂度，是否是健康的，等等。

11. 好的内容

如果你看到开发者写的内容不错，不要吝啬的赞美和鼓励。