来，一起品品 Google 的 Code Review 规范

不要期待完美的代码，只有更好的代码。只要改动的地方 确实能够改善 现有系统 ，就允许通过。快速响应 PR ，最迟不要超过  1  天。

2. 遵循代码规范

变量的命名，注释的格式，制表符和空格的使用等，要满足特定的语言规范。比如 Java ， 可以参考 Google 的 “ Java 编码最佳实践简要”。国内的可以参考 Alibaba 的 “ Java  开发手册”。

3. 合理解决评审中的冲突

因为技术背景和认知的差异，代码提交者和评审者难免会对一些改动点产生分歧。这时候就更需要来一次面对面的讨论或视频会议，而不是仅仅通过代码评审注释来解决冲突。

如果还不能解决问题，最常见的解决方法就是升级。在一个更大的范围中讨论，让技术主管或更资深的人士参与进来，以寻求决策。

原则是：不要因为 代码提交者和评审者 不能达成一致，而让一个  PR  闲坐着。

4.  涉及  UI  的改动，要有演示

如果提交的改动涉及前端 UI ,  除了进行代码评审之外，还必须进行演示， 以确保所有的视觉效果都符合预期。

5. 确保每次改动都伴有单元测试

每次 PR 都应该伴随单元测试，测试用例要设计合理，覆盖周全。

没有单元测试的代码，无疑是很危险的。如下图所示，一个简单的判断写成了赋值语句，如果没有测试出来，那就出人命了。

Test saves lives, From:  Ethan Vincent

6.  当你专注做其他事情的时候，不要打断自己去做代码评审

如果你正在专注于做某一项任务，不要打断自己。因为被打断后可能需要很长时间才能想起被打断前的细节，有时甚至需要重新开始思考。

所以对于评审者而言，专注于在做的事情，可以在某一个 “番茄钟” 后去做代码评审。

7.  R eview 每一行代码，不做假设

检查改动的每一行代码。不要对人工编写的类和方法做任何假设，确保理解每一行代码的作用。

Don’t make assumptions. From： MANU

如果你没有完全理解，那就需要向提交者问清楚。

如果你理解代码，但你觉得不够格做某些部分的评审，确保有合格的评审人员进行评审，特别是对于复杂的问题，如安全性、并发性、可访问性、国际化等。

8.  考虑对整体架构的影响

通常，代码审查工具只会显示被更改部分的几行代码。有时，评审者必须查看整个文件，以确保更改确实有意义。比如，你可能只看到添加了 4 个新行，但当你查看整个文件时，你会看到这 4 行位于一个 50  行的方法中，现在确实需要将其分解为更小的方法。

同时还需要考虑提交的改动对整体架构的影响。这个改动是改善了系统的代码健康状况，还是使其更加复杂？不要接受会降低系统代码运行状况的改动。

每一次好的改动， 一点点累积起来，就会产生一个具有最少 bug 数量的优秀产品。同样，随着时间的推移，每次轻微的代码退化，终将导致难以 维 护 和难以扩展的代码。

9.  遇到好的代码，请不吝赞美

通常，代码评审只关注错误。但是， 代 码评审 的目的不仅仅是发现错误，还应该鼓励和指导开发人员所做的出色工作。

就指导而言，有时候告诉开发人员他们做对了什么，比告诉他们做错了什么更有价值。

10. 保持谦逊，客观

在代码评审过程中，要清晰、礼貌、尊重他人，同时也要对提交者有帮助。

在审查代码时，确保是对代码而不是开发人员进行审查，不要用一些攻击性的词。

永远不要说“你”。注释总是可以用 “我们” 作为主题，或者以一种中立的方式用代码作为主题。例如：

• “你需要对此进行单元测试”    ->   “我们应该对此进行单元测试“

• “你为什么这样做？”               ->   “这个方法的优点是什么？”