什么是Code Review？

　　Code Review代码评审是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找各种缺陷，包括代码缺陷、功能实现问题、编码合理性、性能优化等；保证软件总体质量和提高开发者自身水平。 Code Review是轻量级代码评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低得多，如果流程正确，它可以起到更加积极的效果。正因如此，轻量级代码评审经常性地被引入到软件开发过程中。

　　为什么Code Review？

　　1、提高代码质量。

　　2、及早发现潜在缺陷，降低修改/弥补缺陷的成本。

　　3、促进团队内部知识共享，提高团队整体水平。

　　4、评审过程对于评审人员来说，也是一种思路重构的过程。帮助更多的人理解系统。

　　5、是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。

　　6、鼓励程序员们相互学习对方的长处和优点。

　　7、可以被用来确认自己的设计和实现是一个清楚和简单的。

　　如何做Code Review？

　　Code Review检查什么？

　　1、结构问题

　　代码大的问题，不是一两个地方有技术缺陷，也不是业务逻辑错误，而是整个软件设计的不好。前两者更容易通过测试或使用来发现和更正，但后者不同了。如果回想一下自己见过的各种烂摊子，是不是有同感？具体哪里有问题怎么改说不上来，是整个软件看上去混乱无章，无从下手。

　　具体结构问题包括：重复拷贝代码（不封装函数，不用Template/泛型……），函数过长（超过一屏幕叫过长），错误封装（不恰当的public/不用Interface/不内聚/强耦合/在类中封装了无关方法……），内容错误（多个无关类置于一个文件/不恰当的命名……）等等。

　　改正结构问题，是从编写可靠软件向编写精美软件迈进的重要方法。

　　2、业务逻辑问题

　　是软件是否与需求的要求符合的问题。审核者和被审核者经常对业务需求的理解有差异，借此机会同步一下，必要时引入PO（产品经理/产品负责人）。

　　有人会说业务逻辑问题不是一测试知道了吗？可是测试一般发生在很久以后，有些逻辑测试还需要一定的触发条件，而且测试只会发现失效（failure， 与预期不符）而不能发现缺陷（defect，具体哪里出了错），等积累长了，谁也找不到原因了。

　　3、编程素养问题

　　很多问题属于那种“这样也行那样也行”的状态，比如命名/初始值/缩进/断行……但是高手的做法总是比新手好一些。

　　比如bool result= true； 这句话有问题，刚初始化先宣布成功，必有隐患。这是一个真实案例，而下面也的确有一个分支错误地返回了这个true（实际案例是个HRESULT）。而发现这个问题，不是测试而是代码检查。实际上测试几乎发现不了这些问题，比如上面那段代码会在某文件打不开的时候错误地返回这个true，而在测试中几乎不会故事破坏那个文件来测试其结果。

　　经常进行Code Review

　　常见的Code Review是高手审核新手，或者师傅走查徒弟。一般而言，大致高手每天能编写100多行有效代码（按分号计数），新手会多一些但也不超过200（他们编写代码比较费），也是10个屏幕以内。有经验的人一定知道：高手看新手的代码，5秒钟能发现问题。所以不用花上很长时间去做Code Review，而应该“少吃多餐”，每次可以5分钟，10分钟，每天2-3次甚至更多。看到一个问题要彻底解决，不需要一次检查很多，问题一次比一次少即可。

　　但是切记不可积累，隔很长时间才去做Code Review，你会面临那近万行的代码，以前N多掺和在一起的功能，你会发现，整个Code Review变得非常地艰难，用不了一会儿，你会发现你会疲惫地打着哈欠，但还是要坚持，有时候，这样的Review会持续N个小时以上，相当的夸张。而且会出现相当多的问题和争论，因为，这好像，人家都把整个房子盖好了，大家Review时这挑一点那挑一点，有时候触动地基或是承重墙体，需要大动手术，让人返工，这当然会让盖房的人一下跳起来极力地维护自己的代码，后还伤了他人的感情。

　　我们怎么做 Code Review

　　我带过的项目中，做CodeReview这方面大多感觉比较凌乱，也没有什么统一的做法。不过从形式上来看大体可以分为两大类：一类是TM技术经理对项目中成员Team一个一个的做Code Review，或者是团队人员来做（姑且叫个人式吧）。一类是做Code Review Meeting，以会议形式来做Code Review（姑且叫会议式）。