写在前面：本篇文档是关于团队实践中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？

1. 模块的负责人或许对模块了解度比较高的人
2. 此次开发改动了对方的代码、逻辑
3. 技能评审、需求开发过程中较为活跃或许贡献出定见的人

• 会中

  • author首要简略同步一下需求的背景和改动的规模
  • author全体过一遍代码，要点叙述代码变动的当地和需求讨论的当地
  • reviewer可随时打断，提出自己的疑问或许修正主张，author进行回答或辩驳。

  • 注意气氛，施行review时，要营造一个讨论问题、解决问题的气氛，不要搞成批判会或吵架会

  • author控制review的时刻在1小时之内，防止长线作战

• 会后

  • author依据修正主张完结代码修正，并约请reviewer再次评审，如无问题，reviewer能够点approve，然后合入