　　本文主要参考了如下两篇博客，链接地址如下：

　　笔者将通过问答的方式来介绍 Code Review（后面简称CR）相关内容。

CR 到底有没有用?

　　关于这个问题，网上有两种观点：

第一种认为有用。它可以帮助统一规范、知识共享、发现bug等等。
第二种认为没用。
1）业务繁忙、工期很紧的团队，写代码的时间都不够，也就没有时间Review。
2）需求老变，代码的生命周期太短，写好的代码没有意义，只要能通过测试就行，反正与绩效无关。
3）另外，楼上不从实际情况出发，光打正义的嘴炮实在太过于自慰了。

　　各有各的道理，但 CR 作为业界公认的最佳实践，如果每个团队都能运用起来，固然是最好的，但是由于这项活动跟“人”这个因素密切挂钩，所以，它是否能有效运作跟团队状态、技术信仰和领导者诉求等都有莫大关系。

　　所以 CR 到底有没有用得看团队的具体情况。

哪些团队更适合 CR ?

　　从代码质量提升的角度上看，以下类型的团队，笔者建议把 CR 活动有效运作起来：

　　1、技术驱动型团队

一般涉及系统底层逻辑较多，功能路径难以被测试覆盖，而产品质量问题很多时候是致命的，所以这样的团队更多需要开发编码的严谨性和相关代码质量的保证活动。

　　2、公共服务型团队

一般服务于多个团队，一旦出现质量问题影响范围会比较广，所以除了在测试方面加以把关外，通过CR活动来提升开发质量是非常有必要的。

　　3、测试缺失型团队

这样的团队由于缺乏测试环节，质量问题带到线上的风险会很高，强烈建议在开发环节做好自检工作。

　　4、新人密集型团队

新人的代码可读性往往是比较差的，特别需要组织能及时给予纠正，帮助新人养成良好的编码习惯。同时如果团队产出的代码可读性较高时，新人也可以更快上手工作。

　　5、任何有主观意愿的团队

这样的团队或领导者认同 CodeReview 的意义，或团队成员对代码质量提升有追求。

　　当然大家也不必须对号入座，若某个模块测试人员无法覆盖到，找队友进行简单的CR还是非常有必要的。一般来说，如团队主观意愿没有问题，就可以大胆推行开展。

进行 CR 有哪些好处?

　　1、提高代码质量

如果将代码分为以下六个级别的话：
1）可编译
2）可运行
3）可测试
4）可读
5）可维护
6）可重用
通过自动化测试的代码只能达到第3级，而通过CR的代码少会在第4级甚至更高。

　　2、传递知识

CR可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。
程序员可以通过CR用来确认自己的设计和实现是否简单合理，从而达到相互学习对方的长处和优点的目的。

　　3、发现测试无法覆盖到的BUG

最常见的就是内存泄漏、接口请求频繁、代码执行效率等的问题了。

如何有效进行 CR ？

　　要想在团队内部有效运作CR活动，必备四要素。

　　1、代码规范

　　如果一开始不定义好团队Coding标准，那在检视过程中就会存在两种情况：

1) 各种不同的意见很难快速达成一致，影响CR效率。
2) 大家不会重视代码规范的检视。比如命名不规范、可读性较差等问题。

　　如果您是 Android 开发者的话，笔者推荐《阿里巴巴Java开发手册》，里面也有相应的 AndroidStudio 插件，可以实时监测代码是否符合规范。

　　2、踩坑经历表

　　其实就是一个 CheckList 。

　　一个团队并不是所有人都是老司机，有很多同学是没有CR经验的，他们往往不知道应该重点 check哪些点。这个时候结合自身业务特点和团队之前踩过的坑，制定一个 CheckList 是非常必要的:

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

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

　　3、总结优化

我们看到很多团队的CR活动坚持不下来或逐步流于形式，其实最主要原因是过程中缺乏定期回顾和总结。
因此TeamLeader需要定期的搜集意见然后进行总结，分析问题，解决问题，持续优化。

　　4、激励机制

　　由于CR本身跟人的经验或者意识都有很大关系，很多时候我们会为调动不起开发同学的积极性而烦恼，所以为了让大家更好的参与这个活动，我们一般都需要制定相应的激励机制。

1) 和绩效轻微的挂钩
2) 在定期回顾的基础上根据CR的实际情况对表现积极的同学进行一定的礼品奖励
3) 团队每月会从CR发现问题数等纬度进行质量之星选举，同样有礼品

　　总之，这四个因素对成功运作CR活动都非常关键，但每一项里面的内容具体要如何定义，团队在参考业界做法的基础上可根据实际情况进行一定的定制。

具体 Review 的流程和内容是什么？

　　Review 的内容以及时长，是因团队而异的，推荐：

1) 每次会议时长不超过1小时。（因为据说那个一个正常人的膀胱可以容纳尿液的最长限度）
2) 尽量不要 Review 大篇幅的代码。因为要Review的代码越多，那么要重构，重写的代码就会越多。而越不被程序作者接受的建议也会越多，唾沫口水战也会越多。
3) 越接近软件发布的最终期限，代码也就不能改得太多。

　　流程上的话，推荐代码的作者按照如下顺序：

1) 介绍这段代码是干什么用的
2) 介绍骨干代码
3) 介绍最后Review完成的代码

总结

　　通常 Code Review 最终的作用将归到促进工程师日常代码交流和人员的成长上面来，与此同时作为辅助手段来对产品质量进行把关。但一般来说，很多团队在 Code Review 前期重点会是找问题（代码规范、潜在缺陷、BUG，代码设计等等），而后期随着问题的逐渐减少和习惯的逐步养成，工程师交流文化的营造将转化成重点，中期当有大批新人加入时，问题找茬将又上升为重点，如此复始。