写在前面：本篇文档是关于团队实践中CodeReview的一些个人想法，非常主观。想法主要来源于日常工作的一些感想，以及参考了其他团队的一些CodeReview规范和做法，有很多的地方考虑不周到，还请大家多多包涵。本篇文档的主要目的是拉起大家对于CodeReview的一些思考，如果看到这里，已经燃起你对思考CodeReview这件事情的欲望了，那么就请在这里打住，不要再往下看了。
为什么要拉CodeReview会？
从两方参与变为三方参与。
两方：reviewer，author
三方：reviewer，author，others
-
对于author来说，
- 拉会的形式能够加速review的流程，高效迅速完成CodeReview，避免一个mr拖太久
- 能够引入更多的同学拉review自己的代码，减少低级错误，更好地提升和保障代码的质量
- 拉会的形式对于author的逻辑表达能力有更高的要求，可以锻炼自己讲解代码的能力，同时也是自己知识输出的一种途径
-
对于reviewer来说，
- 拉会的形式能够帮助reviewer更好地理解代码逻辑，避免自己花大量时间看大段逻辑复杂的代码
- 对于代码中有疑问的地方能够直接提出疑问，并及时得到解答，提高review效率
- 避免漏掉review一些比较小的点
代码评审有个重要的作用，那就是可以教会开发者关于语言、框架或者通用软件设计原理。 ——from 谷歌 code review实践
-
对于others，
- 新同学能够学习到组内大佬的思路和解决方案，加速成长
- 促进团队内部知识共享，提高团队整体水平
什么时候应该拉CodeReview会？
- 新增代码逻辑较为复杂，如新增某个接口or新增某个特性
- 代码改动较大，如对某个模块进行了整体的优化or把代码改得面目全非了
- 引入了新的技术或者新的架构
什么时候不应该拉CodeReview会？
- 代码改动较小或改动的逻辑较为简单
- mr上评论未解决，或检查未通过
CodeReview流程
-
会前
- 代码已完成自测，并且提mr，邀请相关的reviewer
- 提前一到两天与主reviewers（至少一位主reviewer）约定时间，并将会议链接发到群里，感兴趣的同学可自行选择参与
如何选择主reviewers？
- 模块的负责人或者对模块熟悉度比较高的人
- 此次开发改动了对方的代码、逻辑
- 技术评审、需求开发过程中较为活跃或者贡献出意见的人
-
会中
- author首先简单同步一下需求的背景和改动的范围
- author整体过一遍代码，重点讲述代码变动的地方和需要讨论的地方
- reviewer可随时打断，提出自己的疑问或者修改建议，author进行解答或反驳。
-
注意气氛，实施review时，要营造一个讨论问题、解决问题的氛围，不要搞成批判会或吵架会
- author控制review的时间在1小时之内，避免长线作战
-
会后
-
author根据修改建议完成代码修改，并邀请reviewer再次评审，如无问题，reviewer可以点approve，然后合入
-
