Google CR 指引, 如何推进代码评审

5 年前的一篇文章，提炼了 17 条省流版：

1. 对于提升系统可维护性、可读性、可理解性的代码 CL（ChangeList），reviewers 应该尽快给出答复，不能因为一味追求完美主义将其搁置几天或者几周。

2. 如果在代码 review 中出现了冲突的意见、观点，首先，开发者、reviewer 应尽可能基于之前的代码、现在 CL 的代码达成一个共识，如果仍然达不成共识，或者很困难，最好能进行面对面沟通，或者将当前 CL 升级一下，供更多的人员进行讨论。不要因为代码 reviewer 和 CL 作者之间达不成一致，就长时间将CL搁置。

3. Code review 过程中最重要的事情就是看 CL 的整体设计是否合理，如 CL 中涉及到的各个部分的代码之间的接口、交互、衔接是否合理。

4. CL 是否过于复杂，这个需要对 CL 中的不同层次的内容进行逐一检查，如每行代码是否过于复杂，函数实现是否过于复杂，类实现是否过于复杂等。

5. CL 提供的注释是否是必要的，注释不是笔记，注释应该用来解释某段代码为什么存在，不需要解释这段代码要干什么，这样的注释才有意义。

6. CL 里面不要既做代码逻辑修改，又做大范围格式化的操作，这可能让 review、merge、rollback 等变得复杂，如果确实有必要做这样的调整，请提供两个 CL。

7. 一个 CL 改变了用户 build、test、interact with、release code 的方式，请同步检查下文档是否也要更新。

8. 开发者自己写的代码，也有重要的、不重要的之分，某些代码片段需要更仔细地 review，比如某些分支判断逻辑，reviewer 需要培养这方面的识别重要代码路径的能力。

9. 在 review CL 主要部分的时候，发现设计上明显存在不合理的地方，reviewer 应该立即发送 review comments 给开发者，其他的代码可以不用 review了，继续 review 纯粹是浪费时间。

10. reviewer 的目标，就是激励开发者持续地对代码质量进行提升。

11. 不要为了“快”而降低 Code review 标准或者破坏整体代码的质量。

12. 写 review 意见的时候，只对 code 本身进行评论，不要对开发者本人进行评论，对于某些人称代词是否有必要出现，也需要斟酌下。

13. 当开发者不同意 reviewer 的建议时，reviewer 应该停下来先想想他们的想法是不是对的。

14. 一开始就坚持写小的 CL，多次 CLs。CL 包含最少内容，一次只做一件事情，比如新增 feature，CL 只包含 feature 的一个部分，而不是所有的部分。

15. 如果多个 CLs 互相依赖，需要找一个办法来确保这几个 CL 每提交一个，系统整体仍然能够正常工作，不能因为提交了一个 CL 就导致系统构建失败或者工作不正常。

16. Code review 的初衷是为了维护代码的质量、产品的质量，当一个 reviewer 对开发者代码写了些意见时，开发者应该将其看作是来自 reviewer 的帮助，不要将其看做是对开发者个人、个人能力的人身攻击。

17. 对于别人的 review 意见，永远不要用愤怒去回应！

#Google #CodeReview #技巧 #指南

https://www.hitzhangjie.pro/blog/2019-09-10-%E5%A6%82%E4%BD%95%E6%9B%B4%E5%A5%BD%E5%9C%B0%E8%BF%9B%E8%A1%8C%E4%BB%A3%E7%A0%81review/