刚才专注看了下zwchen的博客，读到Code Reivew这一篇，觉得自己也了说话的冲动。

我们Team实施Code Reivew近5年，到今天，我们的结论是: Code Review是我们项目成功的最有力的武器。下面我先谈下我理解并实施的Code Review.

1.Code review的层次。

最基础的，也是所有人都会想到到的，就是编码规范，类，方法命名什么的，还有代码格式...这些是程序员的基本功底，默认选项；多年前领导要我搞个编码规范，我说大家都熟知的规范就已经很好了啊；当然公司内部也需要这方面的规范，比如项目如何命名，包如何命名等这些。

更高一层次的，也是说的比较少的，是代码的质量。前面能保证代码写的好看，大家看了都还顺眼，但并不能保证代码的可工作性，合理性，健壮性，可维护性。我们需要可以解决问题的代码；我们需要最合理（最是相对的）的代码；我们不希望破坏现有的架构搞特殊处理，如果架构本身不适应，那就可控制的重构；我们不希望有个工作很好的功能被破坏。

2.Code Review的好处

第一，最少有两个人对同一段代码深刻理解，并且认同。如果不能做到敏捷要求的“结对编程”的味道，我们就打个折执行吧。这一点从公司正常运营上，也是有好处的。

第二，开发人员可以放心的把自己的创造性发挥出来，因为他知道他有个坚强的后盾，绝不会等到QA发现不可饶恕的错误，然后经理过来骂你一顿。

第三，开发人员都会尽全力写最好的代码；软件开发人员都是要"face"的，不想当时就被别人找到缺陷，尤其是你身边的同事。再也不会只顾今天，不管明天会怎样；对软件的可维护性更加尽心。

第四，极大的提高软件质量，以及可维护性。当然这要求Review人员的责任心，以及专业精神。如果是维护性项目，经验也是相当重要的。

3.Code Review的重要性

至此，其重要性以已经不言而喻了。个人认为某种程度上其重要性以及你改超过Unit Test.

4.Code Review不好实施的原因

Code Review如此重要，但是据我接触的人跟公司来看，真正认真执行的并不多。其原因无非：

• 项目时间紧，时间跟人员都不充足；如果是这种情况，建议招点人，项目计划制定的更合理些。

• 重视程度不够；开发人员都觉得自己很牛，代码不需要给别人Review。其实问题往往就是由于过分的自信造成的，需要公司高层多做宣导，并形成制度，强力执行。等过一段时间，大家都会体验到其中的好处的。

• 执行起来比较麻烦。这是大问题。如果你让开发人员觉得做Code Review是件很容易的事，并且收益大于付出，大家就愿意做了。我们Team大致经历过三个阶段。

第一阶段，按制定的流程，开发人员把修改的代码用邮件发给Review者，并说明改了什么，对系统那些功能有影响。然后负责Review的人Copy到Eclipse，对比CVS, 看代码的改动是否合理。然后再邮件通知合格，或不合格，并说明原因(口头或书面)。

第二阶段，开发人员都觉得这样太繁琐，费事费力；于是我们开发了个Eclipse插件，帮助开发人员对自动生成代码改动细节的邮件，并把改动的代码自动放到指定的公用文件夹中。如此一来开发人员生成一个Code Review的请求，就是分分钟的事情了(右键，写点什么，完成)就好了。

第三阶段，开发人员现在很Happy了，但是Review的人觉得还是有点麻烦，要Copy,要写邮件。于是我们把插件又改进了下，Review的人也可以在Eclipse上一键把代码copy进来；然后提供了一个Web Console供头头看我们Code Review的情况。