敏捷代码审查指南

   通过一次真正彻底地代码审查（code reviews），仔细阅读你的代码，找出问题，这是我知道的最好的方式去检测早期的 bug，但是他们很少去这样干过。某种意义上是因为他们花了大量的时间去写好代码，但是我认为主要是因为绝大部分    <a title="程序员的本质" href="/misc/goto?guid=4958202204547787659">程序员</a>害怕其他人审查自己的代码。作为专业的程序员我们要克服阻力，如果你不愿意别人阅读你的代码，然后只是按照自己的意愿写，如果其他人没法读懂它，又怎能让别人使用呢？”J im Waldo – 《    <a title="Java 语言精粹" href="http://www.amazon.cn/gp/product/B0055OQT5Q/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=vastwork-23&linkCode=as2&camp=536&creative=3200&creativeASIN=B0055OQT5Q" rel="nofollow" target="_blank">Java 语言精粹</a>》的作者    <p>        我强烈赞同 code review 是软件生命周期管理中重要的一部分，因为它能帮助我们交付高质量代码、合格作品。</p>    <p>        传统上 code review 仅是一个形式，通常在代码提交之前由团队负责人或高级程序员负责。在敏捷开发环境中，通过团队合作 code review 更有完善，代码的目标和期望应该能用编码指南清晰的定义出来。code review 的目标是协同合作，而不是查错。总的来说 code review 对整个团队尤其每个程序员都有好处，所以每个人应该参与进来。</p>    <p style="text-align:center;"><a title="code review" rel="lightbox[17630]"><img title="code review" alt="敏捷代码审查指南" src="https://simg.open-open.com/show/ad992f5ebd7944297486877ab648e59e.jpg" width="400" height="259" /></a></p>    <p>        <strong>code review</strong><strong>的好处：</strong></p>    <p>        俗话说三个臭皮匠赛过诸葛亮，code review 更易于发现代码 bug 等问题</p>    <p>        3、保证代码质量以及提高代码可读性</p>    <p>        2、团队之间建立信任</p>    <p>        1、指导初级程序员</p>    <p>        编码标准是独立于语言的，对于 Java 程序员来说，我想从以下几个范围来做 code review</p>    <p>        <strong>Java code review</strong><strong>的标准：</strong></p>    <p>        合适的变量声明；如：实例变量还是静态变量、常量等</p>    <p>        9、性能问题；如：当没有线程安全问题时使用 ArrayList，HashMap 替代 Vector,Hashtable</p>    <p>        8、内存问题；如：本应使用对象重用或者对象池时却被不恰当的初始化，没有在 finally 块中关闭昂贵的资源。</p>    <p>        7、数据访问问题：从数据库一次获取数据太多，请求太多的数据库调用。</p>    <p>        6、 线程安全问题；如：Java API 类像 SimpleDateFormat,Calendar,DecimalFormat 等不是线程完全的，在 JSP 中声明变量也不是安全的，存储状态信息在 Struts action 类中或者多线程 servlet 也不是线程安全的。</p>    <p>        5、 对错误的处理：异常抛出而没有保持原始模型(希望 Java7 修复它)，没有记录到日志系统中</p>    <p>        4、 System.out 常被 log4j 替换</p>    <p>        3、设计问题：没有重用代码，没有清晰的责任分离。如：业务逻辑嵌套在 servlet 中，而没有使用业务逻辑层，可视化元素(如 HTML，CSS)嵌入在后台。</p>    <p>        2、 代码文档：没有注释，没有头文件等</p>    <p>        1、 从给定的框架中遵循最佳实践：如 Spring3 中注解替代 xml 文件对于 IOC, 对于每一个简单的部署使用外部属性替代硬编码值等</p>    <p>        你应该为团队做个 code review 的文档和模板，随着项目的开始同步更新，学习更多你项目中选择的软件。</p>    <p>        <strong>工欲善其事必先利其器</strong></p>    <p>        code review 工具：</p>    <p>        3、 <a href="/misc/goto?guid=4958339266006389984" rel="nofollow" target="_blank">Crucible</a> 是 Atlassian 公司的工具用来不间断处理的审查工作，Crucible 能做代码审查而且高度集成在 JIRA 和 FishEye 中，支持 Subversion、Git 等其他类型的 VCS。一个通用的例子就是 Crucible 提供一个转换凭证的工作流，从打开》审查》解决，另一种情景是在代码改变后 check- in 了之后自动审查。</p>    <p>        2、<a href="/misc/goto?guid=4958189339569431829" rel="nofollow" target="_blank">Gerrit</a> ，Gerrit 一个基于 web 的 code review 系统。通过 Git 版本控制系统能方便在线做 code reviews。</p>    <p>        1、Checkstyle: 并不只是一个 code review 工具，更是一个开发工具确保开发者的代码遵循标准，在每一次 code review 中节省时间。</p>    <p>        最重要的是，使用 Checkstyle 能使代码检查成为一个相对简单的任务，你可以把 code review 作为日常活动中的一部分而不需要在项目结束的时候才开始，因为那时候项目的交付期限让你的生活一团糟了。</p>    <p>        原文：<a href="/misc/goto?guid=4958339267531347771" rel="author nofollow" target="_blank">edvorkin</a>  编译：<a href="/misc/goto?guid=4958185140659301754" target="_blank">伯乐</a>在线 –<a href="/misc/goto?guid=4958339269056848758" target="_blank"> 刘志军</a></p>