写在前面：本篇文档是关于团队实践中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. 此次开发改动了对方的代码、逻辑
   
4. 技术评审、需求开发过程中较为活跃或者贡献出意见的人
   

• 
  
• 
  

  会中

  
  
  • 
    
  • author首先简单同步一下需求的背景和改动的范围
    
  • author整体过一遍代码，重点讲述代码变动的地方和需要讨论的地方
    
  • reviewer可随时打断，提出自己的疑问或者修改建议，author进行解答或反驳。
    
  • 
    

    
    

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

    
    

    
    
    
  • author控制review的时间在1小时之内，避免长线作战
    
  
  
  
• 
  

  会后

  
  
  • 
    
  • 
    

    author根据修改建议完成代码修改，并邀请reviewer再次评审，如无问题，reviewer可以点approve，然后合入