最近在InfoQ上看了一篇关于Code Review的文章，该文是来自于InfoQ编辑的翻译。我后来又看了原文，感觉译者漏掉了原文的一些背景知识，以及更多的细节。所以我又重译了一遍，有什么翻译的不妥之处，请大家批评指正。
原文及InfoQ链接：
InfoQ: http://www.infoq.com/cn/news/2010/12/agile-code-review
原文：http://www.devx.com/architect/Article/45741?trk=DXRSS_LATEST
我的译文：
我写的大多数文章都是集中在敏捷项目管理方面的，其中提高团队的一个做法就是产品经理与工程团队一起进行良好的工程实践。如果在团队中没有建立良好的工程实践引入机制的话，产品经理必须参与构建。然后产品经理就需要启动并带领团队采用一些良好的工程实践，而代码评审就是一个非常好的实践。
敏捷工程实践
让我们从那些敏捷团队应该采用的基本的工程实践谈起，通常这些实践来自于极限编程，下面是极限编程中重要的工程实践：
测试驱动开发
持续集成
作战室
结对编程
小型而频繁发布
重构
代码共有
我相信大多数的开发团队都会考虑从极限编程的工程实践开始进行， 当然对于一些希望走的更快、更超前的团队来说，软件工艺宣言会更适合。软件工艺宣言旨在对软件开发精益求精，下面是这个宣言的主要原则：
1. 可以工作的软件犹不足，尚需精益求精
2. 响应变化犹不足，尚需稳步增加价值
3. 个体与交互犹不足，尚需专家社区
4. 客户协作犹不足，尚需卓有成效的伙伴关系
在追求左项的过程中，我们发现右项亦不可或缺。
另外还有一些关于软件设计的实践如松耦合、SOLID原则等等，都已经超出了本文的范畴，不再赘述。无论进行良好开发的原则是什么，团队成员都必须在进行代码评审的时候牢记于心。进行代码评审是让团队关注他们何时以及是否遵循这些原则和良好实践的最好时机。
何时开始代码评审
代码评审的时间应该由团队决定，在一个项目过程中至少进行两到三次是比较合适的，如果项目时间比较宽裕的话，也可适量增加。关于代码评审时间确实没有什么标准，只是与团队的投入保持一致就可以了。
如果你的团队两周一个迭代或者Sprint，那么两个迭代或者Sprint之后进行一次代码评审是比较合适的。这样会有足够的代码来进行评审，但是要能够快速找到本次会议话题相关的代码。代码评审次数依赖于团队的成熟度，如果你的团队正在实践结对编程或者相对比较成熟的话，代码评审的次数可以适当减少。代码评审次数的频度要基于团队成熟度而定，好的代码评审节奏会保持团队继续进行良好的工程实践，有余力引入一些新的实践。
谁应该参与代码评审
整个开发团队都应该参与代码评审，包括各个层面的开发人员。评审可以探讨代码之外的一些原则，要求团队学习并强化这些原则，评审过程中一定要有讨论和反馈。如果QA团队有开发任务的话，也应该参与进来。
组织代码评审
如果你是一个团队领导，Scrum Master或者项目经理，而且从没有组织过代码评审，也不用担心。代码评审并不是全部由手工完成，可以使用有一些现有的工具，同时主要的技术成员也会来帮你。在评审之前要做好充分的准备，因为在评审过程中经常会在代码中有意外发现。
准备
- 代码覆盖率
团队在基本的质量度量上应该有一些标准，例如大多数团队会要求单元测试的代码覆盖率。业界已经有很多的工具可以来使用，例如基于.NET的NCover，Visual Studio Test等等，而Java方面则有jCover，Hansel和CodeCover等等。
代码覆盖率会反映一些问题，如果有覆盖率有低于20%的代码，那可能要对其提出疑问..要注意...也许会有一个好的理由，但是这更多是一个谈话的开始，而不只是一个报告卡。
- 架构
在评审中探讨架构也是非常好的实际，把所有旧的架构图拿出来，与当前结构以及类库进行对比。
介绍当前工程的文件是如何被组织的，这也是一个检验工程是否被合理组织的方式。如果发生改变，要确保是不是有合适的原因。
- 代码分析
在会议之前使用工具分析一遍代码，这样你可以知道什么是需要关注的，以及如何开始。
业界也已经有很多的工具，在会议之前要先把报告准备好。.Net领域我推荐的工具是nDepend，利用这些报告我们可以知道圈复杂度以及类的继承深度等等。
代码评审
当你准备好后，就可以开始评审会议了，注意要留下足够的讨论时间。代码评审会议应该是互动的，相互指导、共同进步的，而不是架构师或者领导者讲述的地方，所有的准备工作都应该以引发讨论、探讨为指向。
根据团队的大小和特性来决定会议的时间长短。下面的数据可以作为参考：该团队有8个开发人员，1个项目经理，1个开发经理，整个团队运作良好，内部关系融洽，一次代码评审会议的时间大约会持续1个半小时。这个数据可以在第一次会议使用，之后就要基于第一次的结果来调整。
关于会议内容安排下面是一个示例：
1) 概览本次代码评审的内容(10分钟)
2) 讨论团队指标(10分钟)
3) 强调评审的特别关注点(5分钟)
4) 深入地评审代码(55分钟)
a) 代码覆盖率
b) 架构
c) 深入的分析报告
5) 总结并记录行动事项(10分钟)
会议安排的重点要突出当前团队需要关注的东西，以及在软件工程实践那些重要的东西，然后在代码中去挖掘这些东西。一些团队可能会关注一些特定的实践，例如我的团队正在采用测试驱动开发，那么我的重点可能会关注一些测试相关的东西例如代码覆盖率。
谈到代码覆盖率，我们就必须讨论单元测试。单元测试需要测试正常的路径，也需要关注极限的路径。确保所有的错误陷阱都应该在单元测试中测到，在团队内部要对如何做好单元测试达成一致，然后再代码中随即查找单元测试来验证这些原则。
另外一个点就是考量代码的复杂度，高的复杂度意味着方法很难被维护。圈复杂度意味着代码的分支路径很多，具体就是使用了if、while、for、foreach、case、default、continue、goto、&&、||、catch还有三元操作符？：等等。从维护的角度来考虑我们应当降低代码的圈复杂度。
还有就是考量对象的依赖关系。下图是我使用Dependency Matrix生成的对象依赖图，具体来说如果我发现对象之间有相互依赖，那么他们之间就是紧耦合的， 就需要开发人员说明为什么他们之间被设计成紧耦合的。
在会议上我们应该讨论这些话题，而且其他别的话题都可以引入。通过工具生成的报告需要经过团队中所有人的验证，需要达成一致，认为当前这样做是有原因的。如果需要对之采取行动，那就记下要跟进的事项，以确保问题得到解决。
在会议结束的时候，回顾探讨话题。注意观察并记录代码审查发现问题的趋势，并且提示团队实践中的积极方向。
你已经完成了代码评审！
现在你已经可以用一定的方式方法来跟你的团队进行代码评审。记住代码评审是一个可以帮助团队提高软件工程成熟度的工程实践，而且这将意味着最终交付给客户更高的价值！