Eric Landes 最近在一篇名为《敏捷技巧：什么时候以什么方式来进行代码评审》提到
代码评审是一个帮助团队提高他们的软件成熟度的工具，并最终意味着交付给客户更高的价值。
他从如下几个环节来介绍代码评审
敏捷工程实践
Eric 首先建议从如下通常敏捷团队需要用的工程实践来展开：
- 测试驱动开发
- 持续集成
- 作战室
- 结对编程
- 小版本发布
- 重构
- 代码共有
并强调
团队需要确保在代码评审时将好的开发原则牢记于心，进行代码评审是让团队关注他们何时以及是否遵循这些原则和良好实践。
什么时候实施代码评审
代码评审的时机应该由团队来决定，这没有什么标准，这取决于你的团队成熟度和 Sprint/ 迭代的周期，Eric 的建议是
如果你的团队 2 周一个迭代或者 sprint, 那么两个 sprint 之后进行第一次代码评审似乎是个好时机，这时候有足够的代码来评估… 而且好的代码评审能够确保团队关注良好的工程实践，并允许不断引入新的实践。
谁来做代码评审
各种开发水平的开发者应该都要来参加，能够让团队成员学习并强化基于代码的原则，并且一定要有讨论和反馈。同时
你的 QA 同事也要参与，如果他们也有开发任务的话。
开始进行代码评审
如果你是一个团队领导，Scrum Master 或者项目经理但从来没进行过代码评审，别害怕！
因为代码评审并不需要完全手工进行，有一些现成的工具而且团队的技术成员也会来帮你，但你要做好充分的事先准备。
准备
Code Coverage 代码覆盖率
Eric 告诉读者
一个团队需要有一些基本的质量标准，比如单元测试的业务逻辑的代码覆盖率，有很多这样的工具，比如.NET 环境下的 nCover,Visual Studio Test 等，Java 环境则有 jCover, hansel, CodeCover 等。
并且
代码覆盖率会反映一些问题，如果有覆盖率有低于 20% 的代码，那可能要对其提出疑问…要注意…也许会有一个好的理由，但是这更多是一个谈话的开始，而不只是一个报告卡。
Architecture 架构
对于代码评审的架构部分，Eric 提到
这也是个了解架构的好时机…要把所有的老架构图和最新的架构以及类库放到一起进行…
Code Analysis 代码分析
可以借助于工具来做一定的事先分析，
在会议之前通过分析工具过一遍代码，这样你可以知道关注什么，从哪开始。
相应的工具比如.NET 环境下的 nDepend，他们生成的报告可以告诉你循环的复杂度以及继承的深度等。
代码评审
准备好后就可以和团队进行会议了，但要预留出讨论的时间，给团队来互动并相互指导。 Eric 建议
团队的大小和特点决定会议需要多长…比如在一个 8 个开发者，一个项目经理，一个开发经理的团队，大概需要一个半小时来进行代码评审…但这只是在第一次会议有用，之后就要基于第一次的结果来适应和调整。
实际当中我们的代码评审时间可能比这个都要长，如何更有效地展开代码审核会议，作者还提供了以下一个时间安排的例子：
1) 概览本次代码评审的故事 (10 分钟)
2) 讨论团队指标 (10 分钟)
3) 强调评审的特别关注点 (5 分钟)
4) 深入地评审代码 (55 分钟)
a) 代码覆盖率
b) 架构
c) 深入的分析报告
5) 总结并记录行动事项 (10 分钟)
这样的例子可以提醒团队关注什么是最重要的，这也会因团队实践而不同。在评审中团队成员不仅要关注单元测试的覆盖率，复杂度，也要关注依赖性，耦合性等。
他总结说
在会议中，团队应当讨论上面所列的问题，而且任何问题都应该可以交流…如果需要对之采取行动…那就记下要跟进的事项，以确保问题得到解决。 在会议结束的时候…回顾行动项目并且提示团队实践中的积极方向。
代码评审实施完了！
你也许已经按照上面的步骤实施了一次代码评审，他最后再次提醒读者
记住代码评审是一个帮助团队提高他们软件工程成熟度的工具，而且这将最终意味着交付给客户更高的价值！
Eric Landes 是一个来自于大型公司 IT 部门的项目经理、特别专注于敏捷团队的教练。他拥有超过四年的经验使用敏捷 / 精益技术以实现客户价值和并让团队专注于项目。
感谢金明对本文的审校。
评论