Code Review是一种通过复查代码提高代码质量的过程，在XP方法中占有极为重要的地位，并且已经成为软件工程中一个不可缺少的环节。通过在项目中实施Code Review将为我们带来多方面的好处，表现在提高代码质量，保证项目或产品的稳定性，开发经验的积累等。
目前大部分开发团队，在软件开发完毕并测试后，甚至项目上线后，才临时确定Code Review的人员，然后再安排时间进行Code Review。结果尽管发现一些结构或设计方面问题，但由于修改成本大或项目已经上线，无法进行改进。因此在软件的开发过程中， 应该尽早的、阶段性、渐进地进行Code Review，而不是等到所有代码都开发完毕后再做一次性的Code Review。
在一个项目或产品开发过程中可以利用以下三种方法在各阶段来进行Code Review：
1）工具或插件自动检查法，如果使用工具或插件，就可以在通过构建或持续集成前发现一些代码的问题，具体Review的频率、次数则可以由开发人员抱着主动、积极的态度，利用工具或插件进行Code Review 。
2）持续自动化检查法，将检验工具集成到构建过程（例如，使用 Ant 或 Maven）中，能够建立起一种寻找潜在缺陷的方法。尽管这种方法使一致性成为可能并超越了 IDE，但它也有一点反作用。必须在本地构建软件或等待持续集成构建的运行。
3）在项目开发完成之前定期或不定期团队或小组开会进行人工Review法，查补工具执行的“漏网之鱼”，并可以将知识分享给团队每个人，大家得到了共同提高。
在刚才提到的三种Code Review方法中有两种提到了工具，其中的工具是指静态代码分析工具，下面我为大家推荐几款目前比较流行的行业内部静态分析工具:
1) 适合.NET静态分析工具
|
工具名称 |
工具用途 |
备注 |
|
FxCop |
FxCop 分析编译的 .NET 程序集的中间代码，并提供相关的建议来改进设计、安全性和性能。设计原则规则可划分为九个类别，其中包括设计、全球化、性能和安全性等内容。 |
支持追寻源代码，全方位检查 |
|
StyleCop |
StyleCop 评估的对象是 C# 源代码的样式。样式原则是指定应该如何对源代码进行格式化的规则，规定是否应该在 for 循环、if 语句和其他结构的缩进和格式中使用空格和制表符。 |
支持追寻源代码，书写规范检查 |
|
CAT.NET
|
微软的内部工具（Microsoft Code Analysis Tool .NET ），他可以直接分析二位元的 .NET 組件，并可以协助找出在組件中潜在的安全性漏洞，例如：Cross-Site Scripting (XSS), SQL Injection, XPath Injection, File Canonicalization, … 等知名且常見的漏洞，目前仅支持8条规则。 |
不支持追寻源代码，安全检查 |
2) 适合Java静态分析工具
|
工具名称 |
工具用途 |
备注 |
|
Findbugs
|
是一个在java程序中查找可能出错的代码实例，注意findbugs是检查java字节码，也就是*.class文件。 |
Java代码检查 |
|
Checkstyle
|
Checkstyle是一款检查Java程序源代码样式的工具，它可以有效的帮助我们检视代码以便更好的遵循代码编写标准，特别适用于小组开发时彼此间的样式规范和统一。 |
Java代码规范 |
|
PMD
|
PMD是一种分析Java代码错误的工具。PMD附带了许多可以直接使用的规则，利用这些规则可以找出Java源程序的许多问题，例如没有用到的变量、多余的变量创建操作、空的catch块，等等。 |
Java代码分析 |
静态分析工具很好的解决Code Review的效率问题，但静态代码分析工具也不是“银弹”，在使用过程中我们要注意以下几点：
1）静态分析工具承诺无需开发人员费劲就能找出代码中已有的缺陷。当然，如果你有多年的编程经验，就会知道这些承诺并不一定能兑现。尽管如此，好的静态分析工具仍然是工具箱中的无价之宝。
2）静态分析工具的另一个问题是它们容易为开发人员提供大量但并非真正问题的问题——即伪问题（false positives）。出现伪问题时，开发人员要学会忽略工具的输出或者放弃它。
3）需要重申，任何工具都代替不了一个好的工程师，有效地利用工具可以减轻我们的工作并且使工作的质量得以快速的提高。
