研发中心团队越来越庞大了，开发人员越来越多了。和他们聊天过程中，发现开发人员对代码技能的提升很迷茫，诉求越来越浓厚。只不过一个接一个的项目交付没有给他们太多停留的时间，在这种情况下如何给团队营造浓厚的工程师交流氛围呢？
方法有多种，最近进行了《代码分支管理》和《代码的好味道和坏味道之22种坏味道》培训，大家兴趣很高。但是最被认可的还是Code Review活动。
那么 Code Review到底能给团队带来什么？什么样的团队需要进行Code Review活动？如何有效开展Code Review活动？用哪种方式会比较好呢？
一、Code Review到底能给团队带来什么？
通过参与实战和团队成员讨论思考，我认为Code Review最大的作用促进工程师日常代码交流和技术成长，与此同时对产品质量进行把关。
很多团队在Code Review前期重点会是找问题（代码规范、潜在缺陷、BUG，代码设计等等），越到后期它更大的意义将演变成工程师交流土壤的培育和人员成长的促进。
二、什么样的团队需要进行Code Review活动？
Code Review作为业界公认的最佳实践，如果每个团队都能运用起来，固然是最好的，但是由于这项活动跟“人”这个因素密切挂钩，所以，它是否能有效运作跟团队状态、技术信仰和领导者诉求等都有莫大关系。
从代码质量提升的角度上看，以下类型的团队可以把CodeReview活动有效运作起来：
- 技术驱动型团队：一般涉及系统底层逻辑较多，功能路径难以被测试覆盖，而质量问题很多时候是致命的，所以这样的团队更多需要开发编码的严谨性和相关代码质量的保证活动。
- 公共服务型团队：一般服务于多个团队，一旦出现质量问题影响范围会比较广，所以除了在测试方面加以把关外，通过CodeReview活动来提升开发质量是非常有必要的。
- 测试缺失型团队：这样的团队由于缺乏测试环节，质量问题带到线上的风险会很高，强烈建议在开发环节做好自检工作。
- 新人密集型团队：新人的代码可读性往往是比较差的，特别需要组织能及时给予纠正，帮助新人养成良好的编码习惯。同时如果团队产出的代码可读性较高时，新人也可以更快上手工作。
- 任何有主观意愿的团队：这样的团队或领导者认同Code Review的意义，或团队成员对代码质量提升有追求。
Code Review活动跟人这个因素密切相关，以下类型的团队暂时不适合开展CodeReview活动：
- 不认同型团队：即领导和团队骨干都不认同CodeReview意义的团队，这样的团队无论从推动还是坚持上都有很大挑战。
- 疲于应付型团队：这种团队一般没有建立必要的持续提升机制，每天淹没在各种需求沟通实现变更和优化中，代码质量提升活动也很难被列入backlog。
- 创新型团队：这种团队的重要任务是要把产品快速推向市场进行价值验证，所以在代码编写上要求足够敏捷，代码暂时的混乱完全可以接受。
大家在考虑自身团队是否要推行Code Review时，可结合团队实际状态进行综合考虑。但一般来说，如团队主观意愿没有问题，就可以大胆推行开展。
三、如何有效开展CodeReview活动？
要想在团队内部有效运作CodeReview活动，必备四要素。
1、代码规范：明确Coding规则
如果不定义好Coding标准，那在检视过程中就会存在两种情况：一种是各种不同的意见很难快速达成一致，影响review效率，另外一种是团队根本就不会重视代码规范的检视。
2、检视指南：消除困惑和迷茫
一个团队并不是所有人都是老司机，有很多同学是没有代码review经验的，他们往往不知道应该重点 check哪些点。这个时候结合自身业务特点和团队之前踩过的坑，制定一个checklist是非常必要的:
- 什么写法可能导致性能低下？
- 哪个接口要慎用？
- 哪些设计方式需要规避？
- 什么习惯容易引发内存泄漏？
这样可以让经验不足者在不知道要review什么时，能有的放矢，过程中逐步积累起经验。
3、总结优化：透明问题，持续优化（非常重要）
很多团队的CodeReview活动坚持不下来或逐步流于形式，其实最主要原因是过程中缺乏定期回顾和总结，从而不知道如何有效促进和帮助团队更好运作。
4、激励机制：激发主观能动性
激励机制的设立有很多种，都是在定期回顾的基础上根据CodeReview的实际情况对表现积极的同学进行一定的礼品奖励（选择什么礼品，要看组织的经济状况，哈哈）。
四、Code Review方式很多，用哪种会比较好呢？
目前业界运作Code Review的方式有多种方式，目前每种形态都有各自的市场，被不同的团队运用着。
接下来笔者个人角度分析下各种形态的优缺点，供大家参考：
- 强制&非强制： 按照经验，Code Review启动前期建议采用强制要求，否则很难有效开展起来。
- 小片段&大模块：如果想要让问题暴露更充分或降低review的难度，建议采用细粒度方式进行，即小片段review。如果更关注全局设计和逻辑思路的学习和找茬，那么可以用模块方式统一review。但很多时候这两种方式是可以结合运作的。
- 线上交流&线下会议： 如果想提高效率，建议采用线上方式进行交流，这里需要公司提供Code Review工具。如果更喜欢全员一起找茬的那种快感，那么可以采用线下会议方式开展，但采用开会的方式，一般成本较高，可看团队接受度。
- 事前&事后：这里指的是发布前还是发布后。版本发布后统一进行Code Review的方式更多是一种代码交流活动， 起不到代码质量把关的作用。反之，如果在版本发布前就对代码进行Code Review，就可以对质量问题起到很好的把关作用。这里是时间和质量之间的权衡。
- 高频率&低频率：建议把代码交流放在每一天，所以频率越高越好。具体根据团队实际情况进行安排即可。
- 此外，也有团队采用模块Owner把关质量的Code Review方式，这种更多是从质量风险规避角度上考虑，在代码提交前Owner检查是否有质量问题，确认没有问题后方能发布，有这方面需要的团队也可以考虑这种方式。
个人推荐的Code Review方式是强制+事前+小片段+线上交流+高频率，但是，团队状态不一样，选择方式允许有差异，所以具体选用哪种方式组合，还是要由团队自己作主。
五、总结四类Code Review方法
1、 正式的代码审查
正式的代码审查是基于正式的开发流程。其中最流行的实践是范根检查法(Fagan inspection)。它为试图寻找代码的缺陷提供了一种非常结构化的流程，并且，它还可以用于发现规范(specifications)中的或者设计中的缺陷。范根检查法由6个步骤组成：计划(Planning)，概述(Overview)，准备(Preparation)，召开检查会议(Inspection Meeting)，重做(Rework)，和追查(Follow-up)。基本的思想是：预先制定好每一个步骤所需要达到的输出要求。接下来，当进行到某个过程时，你检查其现在的输出，并与之前制定的理想输出要求做比较。然后，你由此来决定，是否进入下一个步骤，或者仍需在当前步骤继续工作。
这种结构化的流程用的并不多。其原因是，这种流程带来很大的开销，并没有多少团队用到它。
2、轻量级的代码审查
- 瞬时的代码审查，也称为结对编程(pair programming)。
发生在结对编程的情景中。当一个开发者在敲键盘写代码的同时，另一个开发者盯着代码，注意着代码中潜在的问题，并在此过程中给出提升代码质量的建议。结对编程适用于两个有相似经验水平的开发者处理复杂的业务问题的情况。
- 同步的代码审查，也称为即时(over-the-shoulder)代码审查
一个开发者独自编写代码，当她写完代码后，立即找代码审查者进行审查。审查者来到开发者的桌前，看着同一块屏幕，一起审查、讨论和改进代码。当审查者不清楚这个任务的目标时，这种代码审查类型会很有效果。
- 异步的代码审查，也称为有工具支持的(tool-assisted)代码审查
开发者在写完代码后，让这些代码对审查者可见，然后开始她的下一个任务。当审查者有时间了，他会在自己的桌子上按自己的时间表进行代码审查。他而不需要当面和开发者沟通，而是用工具写一些评论。在完成审查后，那些工具会把评论和需要的改动通知给开发者。开发者就会根据评论改进代码。异步的代码审查应该作为每一个专业开发团队的默认选项。
- 基于会议的(meeting-based)的代码审查
目前我们的大部分团队采用的方式就是每个迭代会和整个团队开一次代码审查会议。我们坐在会议室，每一个开发者展示并解释着他最近写的一段困难的代码。其他开发者尝试寻找着潜在的缺陷，发表评论，给出如何改进代码的建议。我感觉这种做法适用于的一种情况：当整个团队都没有代码审查的经验时，让把每个人聚起来，一起做代码审查，这样弄几次之后，可能会帮助每个人理解代码审查的目标和意义。然而，从长远来看，这类型并不是一个合适的技术，因为让全组成员审查一段代码是很低效率的做法。
