代码评审介绍（1）

代码审核分为自我审核和同行评审。

一、自我审核

代码自我审核可以借助工具来进行，工具分为两种，一种是动态审核，一种是静态审核。

静态审核

静态审核是直接对代码源文件进行审查， 重在在于检查代码编写是否符合规范。一般来说, 静态审核主要检查如下内容：

1. 潜在的Bug, 如空的try/catch/finally/switch申明；
2. 死代码： 未使用的局部变量，参数和私有方法；
3. 过于复杂的表达式；
4. 重复代码；

目前静态检查主要使用的工具是PMD （http://pmd.sourceforge.net/pmd-5.0.4/ ）， 这是一个开源的代码检查工具，有丰富的检查规则，也支持自定义检查规则。提供和Eclipse集成插件， 支持对代码进行实时动态检查。
【图】
静态审核有助于开发人员养成良好的编码习惯。一般来说，刚开始使用时，总有大量的错误发生，开发人员需使用超过50%的编码时间来修复错误，随着编码习惯养成，在修复静态编码错误上的时间也会越来越少。
开发人员需在完成一个文件编写之后，执行静态检查。 提交到版本控制服务器上的代码，必须是完成静态检查的代码。

动态检查

动态检查是对编译之后的代码进行检查，主要目的是提前发现一些运行时的错误，包括：
潜在的内存泄露
未释放的资源
动态检查可以帮助开发人员尽快发现代码运行过程中可能出现的错误。 目前使用的工具主要是FindBugs.
http://findbugs.sourceforge.net/index.html
FindBugs提供Eclipse集成插件， 安装以后，可以对代码进行检查。
【图】
FindBugs不需要实时运行，开发人员在完成一个模块编写之后，可以运行这个工具对代码做检查。

二、 同行评审

代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。
[参考 http://daquan198163.iteye.com/blog/339832 ]
评审的内容：

1. 代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合
2. 工具、框架使用不当：Spring、Hibernate、AJAX
3. 实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好
4. 测试问题：测试覆盖度不够、可测试性不好

代码评审不负责检查功能、逻辑是否正确，这些要靠单元测试和QA工作来解决
代码评审的好处：

1. 帮助新加入人员尽快熟悉项目情况，熟悉编码风格。 特别是新员工多时，这个很有必要。
2. 提高代码质量
3. 在项目的早期发现缺陷，将损失降至最低
4. 评审的过程也是重新梳理思路的过程，双方都加深了对系统的理解
5. 促进团队沟通、促进知识共享、共同提高

代码评审的形式有交叉评审和会审。

交叉评审

项目组成员互相检查代码。
参与者可以是任意两个组员，或开发组长分别与每个组员结对进行
时机可以选择在下班前半小时，对当天改动的模块进行评审。每次评审代码控制在200行以内，故要求每1-2天进行一次。
议程：

1. 必要时，由代码作者讲解如何以及为何这样实现、
2. 评审者提出问题和建议，可以当面沟通，也可以通过bugzilla进行。  当面沟通的话，需有会议记录，会议记录发送给全项目组人员参考。

 

会审

以项目为单位，召开专门的代码评审会议
参与者：包括CTO, 项目组全体成员，其它组的开发组长也应尽量参加
时机选择：

1. 如果项目组中新人多(50%及以上)，要求每周开展一次；
2. 正常情况下，在项目开发阶段，至少每两周进行一次。
3. 开发进行到某一阶段时，对共性问题进行总结，对好的做法进行提炼和推广

会前准备工作：

1. 由项目经理组织，组织者应通知各参与者本次评审的范围 。
2. 参与者阅读源代码，列出发现的问题、亮点，汇总给组织者
3. 准备工作要细致，需要给出问题详细描述以及相关代码在SVN上的URL地址等

评审代码的选择：

1. 最近一次迭代开发的代码
2. 系统关键模块
3. 业务较复杂的模块
4. 缺陷率较高的模块

会议议程：

1. 如果是第一次会议，先由该项目开发组长做整体介绍
2. 参加者依次发言，结合代码讲解发现的问题
3. 每讲完一个问题，针对其展开讨论，每个问题控制在10分钟以内
4. 如果问题不多，还可以安排该组成员对最近开发的代码进行地毯式的讲解和排查；或者针对某个方面对整个项目做评审，例如性能、安全性或测试

会后总结：

1. 把会上提出的所有问题、亮点及最终结论详细的记录下来，供其他团队借鉴
2. 未能讨论清楚的问题，会后解决

实行代码评审制度前的准备工作：

1. 架构师提供开发规范、指南，为代码评审提供依据
2. 建立起单元测试规范，否则无法达到测试覆盖度的要求、难以修正发现的问题
3. 最好有样例代码库作参照，以提高代码评审的可操作性
4. 提供评审案例：用评审前的代码与评审后优化的代码做对比
5. 问题跟踪：对评审中发现的问题代码应加以跟踪，确保问题得以解决，防止复发
6. 评审到什么程度：
7. 进行全面的代码评审成本较高，也没有必要

对发现的问题要本着集体代码所有制的观点和就事论事的原则，因此建议把代码质量与团队绩效（而不是个人绩效）挂钩。
代码评审最佳实践，参考：http://www.ibm.com/developerworks/cn/rational/11-proven-practices-for-peer-review/

1. 一次评审少于 200–400 行的代码。
2. 目标为每小时低于 300–500 LOC 的检查速率。
3. 花足够的时间进行正确缓慢的评审，但是不要超过 60–90 分钟。
4. 确定代码开发者在评审开始之前就已经注释了源代码。
5. 为代码评审和获取制度建立可定量化的目标，这样您才能改进流程。
6. 使用检查列表，因为它可以极大地改进代码开发者和评审者的作品。
7. 确认缺陷确实得到修复了。
8. 培养良好的代码评审文化氛围，在这样的氛围中搜索缺陷被看做是积极的活动。
9. 警惕“老大”效应。
10. 最少评审一部分代码，就是您不能评审全部的代码，以从 Ego Effect 中受益。
11. 采用轻量级，能用工具支持的代码评审