如何做代码评审

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

代码评审标准

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

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

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

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

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

指导

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

原则

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

处理冲突

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

应该看什么

设计

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

功能

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

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

复杂度

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

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

测试

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

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

命名

确保命名简单易懂。

注释

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

代码风格

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