敏捷代码审查指南

jopen 12年前
   通过一次真正彻底地代码审查(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>