代码审查的意义如何代码审查

作者：腾讯Bugly
链接：https://www.zhihu.com/question/41089988/answer/135943884
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

分享一下鹅厂团队的Code Review经验，希望对大家有所帮助。

======

精神哥最近和团队中的开发同学聊天，看到很多开发同学对代码技能的提升都是有诉求的，只不过快速的业务节奏没有给他们太多停留的时间，在这种情况下如何给团队营造浓厚的工程师交流氛围呢？

方法有多种，目前最被认可或运用的方法莫过于CodeReview活动了。

那么 CodeReview到底能给团队带来什么？什么样的团队需要进行CodeReview活动？如何有效开展CodeReview活动？用哪种方式会比较好呢？

笔者为了接地气地研究这个实践，特选择了“手机管家高权限应用组”作为试点团队进行活动开展，这是一个对CodeReview活动非常认同并且愿意持续改进的团队，经过一年的运作，该团队CodeReview活动运作成效显著。

接下来笔者就根据试点经验，总结一下对CodeReview这个实践的看法和思考，希望能对想要或正在进行CodeReview活动的团队提供借鉴作用。

一、CodeReview到底能给团队带来什么？

通过参与实战和团队成员讨论思考，我们认为CodeReview最终的作用将归到促进工程师日常代码交流和人员的成长上面来，与此同时作为辅助手段来对产品质量进行把关。

但一般来说，很多团队在CodeReview前期重点会是找问题（代码规范、潜在缺陷、BUG，代码设计等等），而后期随着问题的逐渐减少和习惯的逐步养成，工程师交流文化的营造将转化成重点，中期当有大批新人加入时，问题找茬将又上升为重点，如此复始。

总结一下，大多数情况下，找问题会是CodeReview活动启动的初衷，但越到后期它更大的意义将演变成工程师交流土壤的培育和人员成长的促进。

二、什么样的团队需要进行CodeReview活动？

CodeReview作为业界公认的最佳实践，如果每个团队都能运用起来，固然是最好的，但是由于这项活动跟“人”这个因素密切挂钩，所以，它是否能有效运作跟团队状态、技术信仰和领导者诉求等都有莫大关系。今天，笔者想分享下个人在“到底什么样的团队需要”和“什么样的团队暂时不适合”这方面的思考。这里欢迎大家更多的交流讨论。

从代码质量提升的角度上看，以下类型的团队，笔者建议把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是非常必要的:

• 什么写法可能导致性能低下？
• 哪个接口要慎用？
• 哪些设计方式需要规避？
• 什么习惯容易引发内存泄漏？
• 等等。。。

这样可以让经验不足者在不知道要review什么时，能有的放矢，过程中逐步积累起经验。

以下是一个团队建立起检视指南前后，CodeReview发现问题数的变化，足见建立检视指南的重要性。

当然也有人说，我的团队代码检视都是让资深骨干做的，不存在不知道怎么review的情况。

但是我想说，骨干员工的时间毕竟很宝贵，他们也往往很忙碌，为什么不让更多的成员一起来参与review工作呢，毕竟CodeReview不仅仅是找茬，也是代码的交流和学习！

3、总结优化：透明问题，持续优化（非常重要）

我们看到很多团队的CodeReview活动坚持不下来或逐步流于形式，其实最主要原因是过程中缺乏定期回顾和总结，从而不知道如何有效促进和帮助团队更好运作。

为了更好地促进这项活动，手机管家高权限应用组就专门成立了CodeReview组委会，这个组织每月都会对CodeReview运作状况进行总结，分析问题，解决问题，持续优化，其最后的效果能在团队内外均获得较高的认同度，可以说总结优化这个环节起到了非常关键的作用。

4、激励机制：激发主观能动性

由于CodeReview本身跟人的经验或者意识都有很大关系，很多时候我们会为调动不起开发同学的积极性而烦恼，所以为了让大家更好的参与这个活动，我们一般都需要制定相应的激励机制。也有人说了，如果是leader强制跟考核挂钩，那就不需要这个东东了，嗯，但换个角度看，跟考核挂钩难道不是另外一种“激励”方式吗？哈哈。。。

激励机制的设立有很多种，一般来说，都是在定期回顾的基础上根据CodeReview的实际情况对表现积极的同学进行一定的礼品奖励（选择什么礼品，要看组织的经济状况，哈哈）。

笔者跟进的团队每月会从CodeReview提交次数和发现问题数等纬度进行质量之星选举，礼品包括了书籍，公仔，徽章等等，效果不错，做法供大家参考。

总之，代码规范、检视指南、总结优化和激励机制这四个因素对成功运作CodeReview活动都非常关键，但每一项里面的内容具体要如何定义，团队在参考业界做法的基础上可根据实际情况进行一定的定制。

四、CodeReview方式很多，用哪种会比较好呢？

目前业界运作CodeReview的方式有多种方式：强制&非强制、线上交流&线下会议、小片段&大模块、事前&事后、高频率&低频率，等等……据了解，目前每种形态都有各自的市场，被不同的团队运用着。

接下来笔者个人角度分析下各种形态的优缺点，供大家参考：

1. 强制&非强制： 按照经验，CodeReview启动前期建议采用强制要求，否则很难有效开展起来。坚持一段时间待习惯养成后再考虑自由度。

2. 小片段&大模块：如果想要让问题暴露更充分或降低review的难度，建议采用细粒度方式进行，即小片段提交小片段review。如果更关注全局设计和逻辑思路的学习和找茬，那么可以用模块方式统一review。但很多时候这两种方式是可以结合运作的。

3. 线上交流&线下会议： 如果想提高效率，建议采用线上方式进行交流，这里要推荐公司的Code平台，上面支持CodeReview的功能都已经比较齐全。如果更喜欢全员一起找茬的那种快感，那么可以采用线下会议方式开展，但采用开会的方式，一般成本较高，可看团队接受度。

4. 事前&事后：这里指的是发布前还是发布后。版本发布后统一进行CodeReview的方式更多是一种代码交流活动， 起不到代码质量把关的作用。反之，如果在版本发布前就对代码进行CodeReview，就可以对质量问题起到很好的把关作用。这里是时间和质量之间的权衡。

5. 高频率&低频率：笔者建议的是把代码交流放在每一天，所以频率越高越好。具体根据团队实际情况进行安排即可。

6. 此外，也有团队采用模块owner把关质量的CodeReview方式，这种更多是从质量风险规避角度上考虑，在代码提交前owner检查是否有质量问题，确认没有问题后方能发布，有这方面需要的团队也可以考虑这种方式。

最后组合一下，笔者个人推荐的CodeReview方式是强制+事前+小片段+线上交流+高频率，同时，如果能结合线下的大模块方式开展代码交流活动，效果会更好，这个经验来自手机管家高权限应用组的接地气实践。

但是，团队状态不一样，选择方式允许有差异，所以具体选用哪种方式组合，还是要由团队自己作主。

五、结语总结

为了让这篇文章能给读者带来一定帮助，笔者反复进行了review和相应的修改操作，且不论最终目的有没有达到，至少态度和行为上都已努力做到最好。

同样，笔者认为，开发编写的Code, 要想让别人更容易读得懂，一定也需要review才有可能达到目的。

所以，我们一起让CodeReview活动这股清流飞起来吧~

更多精彩内容欢迎关注腾讯Bugly的微信公众账号：

http://weixin.qq.com/r/vkxZQYjES9U0rcwi9xms (二维码自动识别)

腾讯Bugly是一款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类，每日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解应用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！