Eric Landes 最近在一篇名为《敏捷技巧：什么时候以什么方式来进行代码评审》提到代码评审是一个帮助团队提高他们的软件成熟度的工具，并最终意味着交付给客户更高的价值。

　　他从如下几个环节来介绍代码评审：

　　敏捷工程实践

　　Eric 首先建议从如下通常敏捷团队需要用的工程实践来展开：

　　● 测试驱动开发

　　● 持续集成

　　● 作战室

　　● 结对编程

　　● 小版本发布

　　● 重构

　　● 代码共有

　　并强调团队需要确保在代码评审时将好的开发原则牢记于心，进行代码评审是让团队关注他们何时以及是否遵循这些原则和良好实践。

　　什么时候实施代码评审

　　代码评审的时机应该由团队来决定，这没有什么标准，这取决于你的团队成熟度和Sprint/迭代的周期，Eric的建议是：

　　如果你的团队2周一个迭代或者sprint，那么两个sprint之后进行第一次代码评审似乎是个好时机，这时候有足够的代码来评估... 而且好的代码评审能够确保团队关注良好的工程实践，并允许不断引入新的实践。

　　谁来做代码评审

　　各种开发水平的开发者应该都要来参加，能够让团队成员学习并强化基于代码的原则，并且一定要有讨论和反馈。同时你的QA同事也要参与，如果他们也有开发任务的话。

　　开始进行代码评审

　　如果你是一个团队领导，Scrum Master或者项目经理但从来没进行过代码评审，别害怕！

　　因为代码评审并不需要完全手工进行，有一些现成的工具而且团队的技术成员也会来帮你，但你要做好充分的事先准备。

　　准备

　　Code Coverage 代码覆盖率

　　Eric告诉读者一个团队需要有一些基本的质量标准，比如单元测试的业务逻辑的代码覆盖率，有很多这样的工具，比如.NET环境下的nCover，Visual Studio Test 等，Java环境则有jCover， hansel， CodeCover 等。并且代码覆盖率会反映一些问题，如果有覆盖率有低于20%的代码，那可能要对其提出疑问..要注意...也许会有一个好的理由，但是这更多是一个谈话的开始，而不只是一个报告卡。