通过CodeReview检查代码质量，已经不是什么新鲜事。但我发现很多项目的CodeReview流于形式，只是证明我们做过 CodeReview。次数，深度固然不够，往往在项目进度紧张的时候，被第一个砍掉。这样的CodeReview形同虚设，有不如无。其实开发人员真正 的产出物，就是Code, CodeReview是最直接的检查产品质量的方法，同时也可以快速了解开发人员的功底。
个人认为，CodeReview要么就不做，要做就要认真做，真的起点作用。
- 统计Code中的问题
直接看Code，往往能直接的发现问题所在。如try .. Catch 时对异常的错误处理，Dispose方法对资源的释放。这些问题测试人员，不容易从表面现象查到，有经验的开发人员却很容易发现。
对于发现的问题应该汇总到统一格式的报表中,下面是个例子：
| Issue List |
||||
| Review By |
Dev1 |
Reporter |
Dev1 |
|
| Code Owner |
Dev2 |
Report Date |
2004.03.30 |
|
| Category |
Item No |
Location |
Description |
Priority |
| System Setting |
1 |
Public Class:SysSetting Public function: Save |
Should not reload data again. |
High |
CodeReview的报告格式可以自定义，根据报告中的问题修改代码，并追踪修改结果。
- 对问题的思考
发现问题并不是坏事，发现不了问题才是真正的问题。有时候项目经理安排工作计划，缺乏对组员的了解。问题可以让你更清楚地认识组员（能力，性格，态 度）和最初计划的缺陷，防范项目风险。
我在2006年上半年领导的一个小组，其中有个有多年经验，持有研究生文凭的组员，在平时聊天时思维敏捷，口齿伶 俐，给我的印象是个能力很强的开发者。在Code Review时，发现他写的代码一塌糊涂，经常Copy&Paste别 人的代码，不加修改，往往牛头不对马嘴还不如他旁边的一个新手写的好。于是赶紧把原先分给他的一些至关重要的任务，转给更放心的人。而另外有个小伙，在项 目初期，经常打瞌睡，开会的时候也睡，谁说都不顶用，照睡不误，给我的印象极差。可是看过他的代码后，给人耳目一新的感觉，写的代码，精简漂亮，恰到好 处，解决问题的方法十分巧妙。我当时对他的代码的评价是：一行不多，一行不少。
- 谁来做CodeReview
有的人可能认为，CodeReview一定要找项目组中的高手做。其实不然，项目组的高手主要负责技术难度大，核心关键的模块，其工作质量的高低， 对整体项目的影响也最大。因此应保证他们有足够的时间，完成这些核心模块。大量的CodeReview，会花掉他们很多时间，而且读别人的代码（尤其是不 如自己的人写的代码），并非这些高手兴趣所在，也不是他们的强项。个人认为CodeReview应该根据项目进度，分为：全组参与，专家小组会审和新手学 习。
在开发初期，如第一个MileStone，适宜全组参与，Review所有已完成的代码。及时发现已存在的问题，同时也加深了解，互相学习。
项目中期，可以根据进度和已发现的问题，选择少数人Review，或是停止下阶段开发，全体Review及修改已存在的问题。
项目后期，可以抽少数人Review所有人的工作，也可以安排提前完成任务的人员，参与Review。
一般情况，新手不易作太多的任务，或担当核心的模块，适合多参与CodeReview。这时候要鼓励他们要打破砂锅问到底，脸皮要厚，不怕被人笑，就是要问个所以然来。如果新手脸皮太薄，不敢问，不敢争辩，就不要做CodeReview了。
个人认为高手的代码完全可以安排新手来Review，一方面促进新手快速成长，另一方面新手对于看高手写的代码，往往充满兴趣，Review起来也比较认真。而程序员一般对自己做出的东西中发现的问题大都会报以谦虚，谨慎的态度，认真对待。
- 规范性检查
一般正规的软件公司都有自己的Code规范，包括变量命名，Comment的写法以及修改Bug的注释等。这些要求一般只强调格式统一，便于阅读，主要针对新人，易学易用。