敏捷代码审查指南

标签: 程序员 Bug Code Review 代码审查 | 发表时间:2012-05-07 03:20 | 作者:刘志军
出处:http://blog.jobbole.com

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

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

传统上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 作为日常活动中的一部分而不需要在项目结束的时候才开始,因为那时候项目的交付期限让你的生活一团糟了。

 

原文:   编译: 伯乐在线 –  刘志军

【如需转载,请标注并保留原文链接、译文链接和译者等信息,谢谢合作!】

 

相关文章

相关 [代码审查] 推荐:

代码审查过程

- - 博客园_知识库
   英文链接: Code Review Processes.   对我而言,把代码产品化而没有合适的审查流程,就像是一场抽抽乐游戏. 代码当然也有可能会挺好,不过总还是有一定概率某人的哪块积木没抽好,然后一切就轰然崩塌. 无论是采用持续集成服务、结对审查、QA审查,还是所有这些方案的组合,都可以大大降低引入风险的概率.

Google 是如何做代码审查的

- litefy - python.cn(jobs, news)
在上一篇文章中提到过,我已经不在Google工作了. 我还没有想清楚应该去哪里—有两三个非常好的工作机会摆在我面前. 因为在这段做决定时间里,我不再受雇于任何人,我想可以写一些专业性的东西,一些很有趣,但也会在同事和管理工作中导致关系紧张的东西. Google是一个非常优秀的公司. 他们做出了很多令人称赞的东西—既是公司外部,人们可以看到的东西,也是公司内部.

代码审查中应该做的事

- China Moon - Solidot
威客 写道 "Mark Chu-Carroll从Google离职后,虽然已经收到了很多offer,但还没有决定去哪里. 他在其博客中分享了一些关于代码审查的趣事(中文). Google确实是一家很酷的公司. 不论是在公司内部或是外部,Google都做了很多让人赞叹的的事情. 这里我想介绍一些不涉及商业机密,但鲜为外人所知的事情.

敏捷代码审查指南

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

代码审查(Code Review)清单

- - 博客 - 伯乐在线
代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug. 下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践. Javadoc 应该在每一个类和方法中添加. 如果是修复某个 bug,应该添加 bug ID. 走捷径的方法或者复杂的逻辑要有解释.

我所钟爱的代码审查

- - 译言-电脑/网络/数码科技
This is pretty standard fare for developers in the "real world", but I have never heard of an academic research group using them, and had never done code reviews myself before joining Google..

代码审查不是用来……

- - 外刊IT评论
提示:如果您在阅读器里点击订阅本站的文章链接时发现有一个中转页,这说明你的订阅地址有误,本站的订阅地址(RSS)是:. http://www.aqee.net/feed/,请及时纠正. 事实上,今天的我们正是从这种一直坚持探索的漫长道路上走出来的. 我们尝试各种技术、方法和工具,直到我们走到今天的成就(但这并不是说我们就此停步).

我们如何进行代码审查

- - CSDN博客研发管理推荐文章
本文来源于我在InfoQ中文站原创的文章,原文地址是:. Jim Bird是一位经验丰富的软件开发经理、项目经理与CTO,专注于软件开发与维护、软件质量与安全等领域中疑难问题的解决. 在过去的15年间,Jim曾管理过团队建设并主导过高性能的财务系统的建设. 他的主要兴趣在于如何提升小团队的效率以构建真正的软件:高质量、安全、可靠、高性能及适应性强.

你们公司做代码审查吗?

- - 外刊IT评论
每当从各种公司听到他们正在尝试自动化部署/测试的事情,我都非常关注,但通常会很吃惊,他们很少会考虑去实行代码审查制度. 看到这种情况,我通常想问: 如果代码没有经过其它人的审查,你如何知道你要测试的是什么. 这答案(如果有的话)通常是捏着手指头说 有几个人在做代码审查或“正在考虑中”. 不论你采用什么形式的测试过程,什么形式的部署过程,没有代码审查——game over.

[原]代码审查审什么

- - 阿朱=行业趋势+开发管理+架构
看着很多人做代码审查重点审格式和命名,制定的代码规范也主要偏重代码格式和命名,我真想骂一句操蛋,这真是浪费时间又解决不了问题. 此篇文章就是骂完操蛋后奋笔快速敲下来的,有不妥之处请大家谅解. 一、目的:为啥要花费时间要搞人工代码审查. 1、有些问题是工具检查不出来的,需要人工审查. 2、有些问题是不希望花大代价来发现、或者上线后才知道.