如何做代码评审

这是谷歌的代码评审标准笔记。

代码评审标准

代码评审是为了提高整体代码进步而设定的。

首先，要确保代码以后是可以进一步改进的。代码的评审人员也应该是代码的持有者。

总体上，评审者应该允许能够提高总体代码健壮性的代码，即使它不够完美。

当然也有限制，如果代码增加的特性不是整个系统想要的，尽管它多么好也要拒绝掉。

评审者可以任意留下评论，如果不是很重要，请增加「Nit:」作为前缀。

指导

代码评审对开发人员了解一个语言、框架都有所帮助，留下评论是可以的，但是一定记住要留下「Nit:」作为不强制性改动的标记。

原则

• 技术事实，有数据否决的建议和个人配置。
• 代码风格，代码风格应该和原有代码保持一致，如果源代码没有代码风格则允许提交。
• 没有纯粹的代码风格，基本上就是个人设定。
• 评审者应该要求提交代码和现有代码保持一致，这样不会使现有代码健康更加恶化。

处理冲突

在冲突上，评审员和代码作者应该达成一致，做好要有一次面对面会议或者线上会议。如果不能达成一致，一定记得升级到更高层次人员处理。

应该看什么

设计

• 代码和原有代码配合如何？
• 这段改动是基于代码层面还是库层面？
• 和系统的其他部分结合的如何？
• 现在是增加这个功能的最好时机吗？

功能

这段代码是否符合作者用意？是否对用户有利？此处「用户」同时指端用户和开发者。

有时，如 UI 改动需要评审查看 demo。

复杂度

代码的复杂度即代码是否可以被迅速理解，其它工程师是否可以修改这一段代码。

一个特别案例：过度开发。

测试

要求单元测试，或适当的端对端测试。除非紧急任务，测试必须伴随代码一并提交。

确保测试正确，明确和有效。

命名

确保命名简单易懂。

注释

注释应该解释这段代码为什么存在，而不是它做什么。

代码风格

谷歌有对大部分语言提供风格指导。

生词
disincentive	妨碍活动的
mandatory	强制性的
overrule	否决
underlying	基本的
consensus	一致同意
interaction	配合
appropriate	适当的
sensible	明确的