敏捷中如何做代码审查的指南

　　“通过一次真正彻底地代码审查(code reviews)，仔细阅读你的代码，找出问题，这是我知道的最好的方式去检测早期的bug，但是他们很少去这样干过。某种意义上是因为他们花了大量的时间去写好代码，但是我认为主要是因为绝大部分程序员害怕其他人审查自己的代码。作为专业的程序员我们要克服阻力，如果你不愿意别人阅读你的代码，然后只是按照自己的意愿写，如果其他人没法读懂它，又怎能让别人使用呢?”Jim Waldo – 《Java语言精粹》的作者

　　我强烈赞同code review 是软件生命周期管理中重要的一部分，因为它能帮助我们交付高质量代码、合格作品。

　　传统上code review仅是一个形式，通常在代码提交之前由团队负责人或高级程序员负责。在敏捷开发环境中，通过团队合作code review 更系统化，代码的目标和期望应该能用编码指南清晰的定义出来，code review的目标是协同合作，而不是查错。总之code review对整个团队尤其每个程序员都有好处，所以每个人都应该参与进来。

　　code review的好处：

　　俗话说三个臭皮匠赛过诸葛亮，code review 更易于发现代码bug等问题

　　3、保证代码质量以及提高代码可读性

　　2、团队之间建立信任

　　1、指导初级程序员

　　编码标准是独立于语言的，对于Java 程序员来说，我想从以下几个范围来做code review

　　Java code review的标准：

　　合适的变量声明;如：实例变量还是静态变量、常量等

　　9、性能问题;如：当没有线程安全问题时使用ArrayList，HashMap替代Vector,Hashtable

　　8、内存问题;如：本应使用对象重用或者对象池时却被不恰当的初始化，没有在finally块中关闭昂贵的资源。

　　7、数据访问问题：从数据库一次获取数据太多，请求太多的数据库调用。

　　6、 线程安全问题;如：Java API类像SimpleDateFormat,Calendar,DecimalFormat等不是线程完全的，在JSP中声明变量也不是安全的，存储状态信息在Struts action类中或者多线程servlet也不是线程安全的。

　　5、 对错误的处理：异常抛出而没有保持原始模型(希望Java7修复它)，没有记录到日志系统中

　　4、 System.out常被log4j替换

　　3、设计问题：没有重用代码，没有清晰的责任分离。如：业务逻辑嵌套在servlet中，而没有使用业务逻辑层，可视化元素(如HTML，CSS)嵌入在后台。

　　2、 代码文档：没有注释，没有头文件等

　　1、 从给定的框架中遵循最佳实践：如Spring3中注解替代xml文件对于IOC, 对于每一个简单的部署使用外部属性替代硬编码值等

　　你应该为团队做个code review的文档和模板，随着项目的开始同步更新，学习更多你项目中选择的软件。

　　工欲善其事必先利其器

　　code review 工具：

　　3、 Crucible 是 Atlassian公司的工具用来不间断处理的审查工作，Crucible能做代码审查而且高度集成在JIRA和FishEye中，支持Subversion、Git等其他类型的VCS。一个通用的例子就是Crucible提供一个转换凭证的工作流，从打开》审查》解决，另一种情景是在代码改变后check- in了之后自动审查。

　　2、Gerrit ，Gerrit一个基于web的code review系统。通过Git版本控制系统能方便在线做code reviews。

　　1、Checkstyle: 并不只是一个code review 工具，更是一个开发工具确保开发者的代码遵循标准，在每一次code review中节省时间。

　　最重要的是，使用Checkstyle能使代码检查成为一个相对简单的任务，你可以把code review 作为日常活动中的一部分而不需要在项目结束的时候才开始，因为那时候项目的交付期限让你的生活一团糟了。

原文转自：http://www.ltesting.net