团队如何做代码审查(CodeReview)
转载一篇值得思考的文章 ，原文链接 https://zhuanlan.zhihu.com/p/24322127
从代码质量提升的角度上看，以下类型的团队，笔者建议把CodeReview活动有效运作起来：
1.技术驱动型团队：
一般涉及系统底层逻辑较多，功能路径难以被测试覆盖，而产品质量问题很多时候是致命的，所以这样的团队更多需要开发编码的严谨性和相关代码质量的保证活动。手机管家高权限应用组就属于这一类型。
2.公共服务型团队：
一般服务于多个团队，一旦出现质量问题影响范围会比较广，所以除了在测试方面加以把关外，通过CodeReview活动来提升开发质量是非常有必要的。
3.测试缺失型团队：
这样的团队由于缺乏测试环节，质量问题带到线上的风险会很高，强烈建议在开发环节做好自检工作。
4.新人密集型团队：
新人的代码可读性往往是比较差的，特别需要组织能及时给予纠正，帮助新人养成良好的编码习惯。同时如果团队产出的代码可读性较高时，新人也可以更快上手工作。
5.任何有主观意愿的团队：
这样的团队或领导者认同CodeReview的意义，或团队成员对代码质量提升有追求。
CodeReview活动跟人这个因素密切相关，从其带有的这个主观特点来说，笔者认为以下类型的团队暂时不适合开展CodeReview活动：
1.不认同型团队：
即领导和团队骨干都不认同CodeReview意义的团队，这样的团队无论从推动还是坚持上都有很大挑战。
2.疲于应付型团队：
这种团队一般没有建立必要的持续提升机制，每天淹没在各种需求沟通实现变更和优化中，自然，代码质量提升活动也很难被列入backlog。
3.创新型团队：
这种团队的重要任务是要把产品快速推向市场进行价值验证，所以在代码编写上要求足够敏捷，代码暂时的混乱完全可以接受。
综上，笔者建议大家在考虑自身团队是否要推行CodeReview时，可结合团队实际状态进行综合考虑。但一般来说，如团队主观意愿没有问题，就可以大胆推行开展。
如何有效开展CodeReview活动？
要想在团队内部有效运作CodeReview活动，必备四要素（如下图）。如果您的团队没有把CodeReview活动有效开展下去或者正深受烦恼，这部分内容希望您仔细看看。
1、代码规范：明确Coding规则
如果一开始不定义好团队Coding标准，那在检视过程中就会存在两种情况：一种是各种不同的意见很难快速达成一致，影响review效率，另外一种是团队根本就不会重视代码规范的检视， 如果是前者还好，毕竟大家都还在关注什么写法是好的或对的这个问题，只要中途愿意建立起Coding规则，问题就能很快解决。而笔者跟进过的一个团队恰恰就出现了后者的情况：该团队由于前期没有明确Coding规则， 过程中大部分开发人员对规范类问题直接无视，CodeReview运作一段时间后代码中依然存在命名不规范，可读性较差等问题，直接影响了活动效果，这是我们非常不愿意看到的。
当然也有团队负责人说了，每天纠结于空格少了，行数字符多了等细节问题没意义啊，不想浪费这个时间，因此我们不需要代码规范。我个人不认同这个观点，因为代码规范并不只包括空格和字符等约束纬度，还包括了注释的要求，命名的规范，命名是否词能达意，代码结构安排等等影响代码可读性的因素， 如若这些方面连基本规则都没有，那一定会出现之前说的那两种情况（争议太多 or 完全忽视），效果可想而知。所以你可以根据自己的看法或需求做一定的规则定制，但不能没有Coding规则。
2、检视指南：消除困惑和迷茫
检视指南又名CodeReview-checklist。一个团队并不是所有人都是老司机，有很多同学是没有代码review经验的，他们往往不知道应该重点 check哪些点。
这个时候结合自身业务特点和团队之前踩过的坑，制定一个checklist是非常必要的:
- 什么写法可能导致性能低下？
- 哪个接口要慎用？
- 哪些设计方式需要规避？
- 什么习惯容易引发内存泄漏？
- 等等。。。
以下是一个团队建立起检视指南前后，CodeReview发现问题数的变化，足见建立检视指南的重要性。
结优化：透明问题，持续优化（非常重要）
我们看到很多团队的CodeReview活动坚持不下来或逐步流于形式，其实最主要原因是过程中缺乏定期回顾和总结，从而不知道如何有效促进和帮助团队更好运作。
为了更好地促进这项活动，手机管家高权限应用组就专门成立了CodeReview组委会，这个组织每月都会对CodeReview运作状况进行总结，分析问题，解决问题，持续优化，其最后的效果能在团队内外均获得较高的认同度，可以说总结优化这个环节起到了非常关键的作用。
3、激励机制：激发主观能动性
由于CodeReview本身跟人的经验或者意识都有很大关系，很多时候我们会为调动不起开发同学的积极性而烦恼，所以为了让大家更好的参与这个活动，我们一般都需要制定相应的激励机制。也有人说了，如果是leader强制跟考核挂钩，那就不需要这个东东了，嗯，但换个角度看，跟考核挂钩难道不是另外一种“激励”方式吗？哈哈。。。
激励机制的设立有很多种，一般来说，都是在定期回顾的基础上根据CodeReview的实际情况对表现积极的同学进行一定的礼品奖励（选择什么礼品，要看组织的经济状况，哈哈）。
笔者跟进的团队每月会从CodeReview提交次数和发现问题数等纬度进行质量之星选举，礼品包括了书籍，公仔，徽章等等，效果不错，做法供大家参考。
CodeReview方式很多，用哪种会比较好呢？
接下来笔者个人角度分析下各种形态的优缺点，供大家参考：
1.强制&
非强制： 按照经验，CodeReview启动前期建议采用强制要求，否则很难有效开展起来。坚持一段时间待习惯养成后再考虑自由度。
2.小片段&大模块
：如果想要让问题暴露更充分或降低review的难度，建议采用细粒度方式进行，即小片段提交小片段review。如果更关注全局设计和逻辑思路的学习和找茬，那么可以用模块方式统一review。但很多时候这两种方式是可以结合运作的。
- 线上交流&线下会议
： 如果想提高效率，建议采用线上方式进行交流，这里要推荐公司的Code平台，上面支持CodeReview的功能都已经比较齐全。如果更喜欢全员一起找茬的那种快感，那么可以采用线下会议方式开展，但采用开会的方式，一般成本较高，可看团队接受度。
- 事前&事后
：这里指的是发布前还是发布后。版本发布后统一进行CodeReview的方式更多是一种代码交流活动， 起不到代码质量把关的作用。反之，如果在版本发布前就对代码进行CodeReview，就可以对质量问题起到很好的把关作用。这里是时间和质量之间的权衡。
- 高频率&
低频率：笔者建议的是把代码交流放在每一天，所以频率越高越好。具体根据团队实际情况进行安排即可。
重点
- 对事不对人
- 每个 Review 至少给一条正面评价
- 保证发布的代码和评审意见的可读性
- 用工具进行基础问题的自动化检查
- 全员参加 Code Review，并设定各部分负责
- 如果你有更好的方案，尽管提出来
- 不要在 review 中讨论需求，review 就是 review