“通过一次真正彻底地代码审查（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 作为日常活动中的一部分而不需要在项目结束的时候才开始，因为那时候项目的交付期限让你的生活一团糟了。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/