介绍：

在敏捷软件开发中，从代码的产生速度上来看，要比 传统Waterfall产生速度高很多。因为我们把时间安排的更加紧凑了。那么这么多的代码，如何能保证这些代码质量呢？很多人可能直接想到静态代码检测 工具。没错，那些是可以定义一个代码检查规则来确保代码的质量，但是那个仅仅是从语言角度，那么逻辑是否已经最优化了？可重用性是否已经优化到极致了？这 些是静态代码工具不能完成的，所以我们需要Code Review

实现方式：

对于已经在项目组很久的人来说：

虽然传统的code review就是把代码从仓库checkout出来，然后看下，但是对于大项目来说，那样的代码审查没有任何的效果，因为你除了看到代码还是代码，就像你在大海中看到的除了水就是天，很快就会迷失方向的。我们团队的经验，一般是采用crucible工具来进行代码审查，这个工具我以前博客已经有过介绍了：http://supercharles888.blog.51cto.com/609344/1229660

因为我们代码提交每次都有产生一个uuid,而我们提交更多是以子功能为单位，所以我们在crucible中也以提交为单位创建事件，可以很明确的知道对于具体某个功能，其实现的效果如何。

具体流程如下：

代码我们也采用了传统的peer review,因为自己看自己代码很难看出问题，但是用批判的眼光看别人的代码就很容易看出问题，所以我们结对的进行code review, 前端的人相互review,后端的人相互review.

对于刚来项目组的人：

刚来项目组的人，因为对业务逻辑不熟悉，直接让他去以提交为单位进行审查代码是没有任何意义的，他们最重要的是熟悉代码从而可以很快的上手项目，这时候，我就不主张他们用code review工具了，而是直接把代码全部签下来整体看，我 的经验是：用调试模式启动服务器，然后在关键的行打上断点（后端代码断点），然后在前端你用Firefox 打开，开启FireBug，在关键js文件相应行也打上断点（前端代码断点），然后完全用单步走的方式，一步步走过来，同时watch关键的变量的值的变 化，这样走一遍虽然很慢，但是你会对代码逻辑流程非常熟悉而且印象深刻。而且一个项目来说，虽然代码很多，但是关键流程并不多（判断依据就是这些流程是否 最后要做Regression,如果要做Regression,那么就算关键流程），如果把握了关键流程，就是等于抓住了主要矛盾。这是最好的上手项目的习惯。按照我们团队的经验，一般一个senior engineer水平，2-3天就能上手项目并且开始接任务做了。

总结：

(1)对于项目组的老人来说，用代码审查工具来code review,从而可以从功能模块角度审查代码的实现

(2)对于新来项目组的成员来说，用调试模式单步走的策略，只抓住核心流程，从而以最快的速度把握项目核心流程。

本文出自 “平行线的凝聚” 博客，http://supercharles888.blog.51cto.com/609344/1262016