1.CodeReview最终的作用

• 促进工程师日常代码交流
• 人员成长
• 作为辅助手段对产品质量进行把关。

另一种作用：

• 检查有没有比较严重的错误
• 统一团队内的代码风格
• 该模块的原作者可以提出改进意见
• 找个出了问题的时候可以一起背锅的人

2.适合的团队

• 技术驱动型团队：一般涉及系统底层逻辑较多，功能路径难以被测试覆盖，而产品质量问题很多时候是致命的，所以这样的团队更多需要开发编码的严谨性和相关代码质量的保证活动。手机管家高权限应用组就属于这一类型。
• 公共服务型团队：一般服务于多个团队，一旦出现质量问题影响范围会比较广，所以除了在测试方面加以把关外，通过CodeReview活动来提升开发质量是非常有必要的。
• 测试缺失型团队：这样的团队由于缺乏测试环节，质量问题带到线上的风险会很高，强烈建议在开发环节做好自检工作。
• 新人密集型团队：新人的代码可读性往往是比较差的，特别需要组织能及时给予纠正，帮助新人养成良好的编码习惯。同时如果团队产出的代码可读性较高时，新人也可以更快上手工作。
• 任何有主观意愿的团队：这样的团队或领导者认同CodeReview的意义，或团队成员对代码质量提升有追求。

3.不适合的团队

• 不认同型团队：即领导和团队骨干都不认同CodeReview意义的团队，这样的团队无论从推动还是坚持上都有很大挑战。
• 疲于应付型团队：这种团队一般没有建立必要的持续提升机制，每天淹没在各种需求沟通实现变更和优化中，自然，代码质量提升活动也很难被列入backlog。
• 创新型团队：这种团队的重要任务是要把产品快速推向市场进行价值验证，所以在代码编写上要求足够敏捷，代码暂时的混乱完全可以接受。

4.开展必备四要素

• 代码规范：明确Coding规则
• 检视指南：消除困惑和迷茫
• 总结优化：透明问题，持续优化（非常重要）
• 激励机制：激发主观能动性

5.CodeReview方式

• 强制&非强制： 按照经验，CodeReview启动前期建议采用强制要求，否则很难有效开展起来。坚持一段时间待习惯养成后再考虑自由度。
• 小片段&大模块：如果想要让问题暴露更充分或降低review的难度，建议采用细粒度方式进行，即小片段提交小片段review。如果更关注全局设计和逻辑思路的学习和找茬，那么可以用模块方式统一review。但很多时候这两种方式是可以结合运作的。
• 线上交流&线下会议： 如果想提高效率，建议采用线上方式进行交流，这里要推荐公司的Code平台，上面支持CodeReview的功能都已经比较齐全。如果更喜欢全员一起找茬的那种快感，那么可以采用线下会议方式开展，但采用开会的方式，一般成本较高，可看团队接受度。
• 事前&事后：这里指的是发布前还是发布后。版本发布后统一进行CodeReview的方式更多是一种代码交流活动， 起不到代码质量把关的作用。反之，如果在版本发布前就对代码进行CodeReview，就可以对质量问题起到很好的把关作用。这里是时间和质量之间的权衡。
• 高频率&低频率：笔者建议的是把代码交流放在每一天，所以频率越高越好。具体根据团队实际情况进行安排即可。
• 此外，也有团队采用模块owner把关质量的CodeReview方式，这种更多是从质量风险规避角度上考虑，在代码提交前owner检查是否有质量问题，确认没有问题后方能发布，有这方面需要的团队也可以考虑这种方式。最后组合一下，笔者个人推荐的CodeReview方式是强制+事前+小片段+线上交流+高频率，同时，如果能结合线下的大模块方式开展代码交流活动，效果会更好，这个经验来自手机管家高权限应用组的接地气实践。

引用：大家的公司的 Code Review 都是怎么做的？遇到过哪些问题？
参考：程序员必备的代码审查（Code Review）清单