本文向大家介绍Code Review的主要内容,以及流行的检查Code Conventions的工具。同时,对于目前应用最为广泛的CheckStyle的应用给出详细的介绍,也列举了很多使用CheckStyle的最佳实践。
一、Code Review & Code Conventions
质量是衡量一个软件是否成功的关键要素。而对于商业软件系统,尤其是企业应用软件系统来说,除了软件运行质量、文档质量以外,代码的质量也是非常重要的。软件开发进行到编码阶段的时候,最大的风险就在于如何保证代码的易读性和一致性,从而使得软件的维护的代价不会很高。
在软件开发的过程中,以下几种情形随处可见:
1) 软件维护时间长,而且维护人员的积极性不高:
做过软件维护的开发人员,尤其是在接手不是自己开发产品的源码的时候,即使有良好的文档说明,仍然会对代码中冗长、没有注释的段落“叹为观止”。理解尚且如此困难,何况要修改或者增加新的功能。因此,很多开发人员不愿意进行软件维护的工作。
2)新的开发人员融入团队的时间比较长:
除了没有良好的培训、文档等有效的机制以外,每个人一套的编码风格,也容易造成新成员对于已有代码的理解不够,甚至出现偏差。
编码规范,作为解决以上问题的方案已经得到了很长时间的应用。而在产品或者项目实际开发的过程中,仅有Code Conventions是不能解决Code的问题的。它往往和Code Review配合,作为代码质量保证的手段。
1.1. Code Review的层次与内容
Code Review就是审查代码的质量。根据形式分为两种,一种是交叉代码审查,就是自己的代码由他人来检查,就象检查作业一样;另一种是代码会审,就是以会议的形式,大家共同审核代码的质量。
Code Review 的目的有:
·在项目早期就能够发现代码中的BUG;
·帮助初级开发人员学习高级开发人员的经验,达到知识共享;
·避免开发人员犯一些很常见,很普通的错误;
·保证项目组人员的良好沟通;
·项目或产品的代码更容易维护;
一般情况下,Code Review的内容与层次如下:
·编码风格与代码规范一致性:检查代码是否符合编码规范,确保所有人写的代码基本一致;
·代码满足基本的功能要求:检查代码的逻辑实现,以及单元测试的编写策略,确认实现功能性需求;
·代码满足性能等非功能性需求:非功能性需求一般不便于测试,需要借助一定的工具和Review人员的素质,针对编码中对于性能影响的瓶颈给出解决方案;
·去除冗余,提高代码可读性:适当使用 Refactorying技术,去除代码中的Bad Smell;如果有需要,可以Refactorying to Pattern。
1.2. Code Conventions的尴尬境地
从Code Review的层次分析中我们可以看到,Code Conventions是其基础。而实际的情况是,在软件开发中,两者都沦为“宣传口号”,而非切实执行的实践。
造成这种情形的原因有二:
1. Code Conventions是开发过程的“道德”而非“法律”:很多时候,由于没有有效的工具或者辅助手段的支持,是否遵守编码规范是依靠开发人员的“道德素养”-自觉遵守,而非实际考核的指标;
2. Code Review的基石不牢:在第一种原因的影响下,Code Review执行的过程中,如果花费了大量的时间在代码规范的检查上,那么对于更为重要的程序执行逻辑、性能、易读性等的评审投入的精力就有限的;而这种情况反过来也使得对于编码规范的检查,通常都是走过场。最后,还是每个人一套规范,只要最终交付的产品完成指定的功能就可以啦。
二、CheckStyle
面对以上描述的Code Conventions的尴尬境地,陆续有开发人员提出了自己的解决方案。目前,对于JAVA的代码规范的检查,已经有很多成熟的工具,例如CheckStyle、PMD以及Jalopy等[3]。其中,CheckStyle的应用非常广泛,众多开源项目都使用它作为检查代码规范的工具,尤其是 Jakarta 的很多项目,例如Maven、 Torque等。
2.1. CheckStyle是什么?
CheckStyle是SourceForge下的一个项目,提供了一个帮助JAVA开发人员遵守某些编码规范的工具。它能够自动化代码规范检查过程,从而使得开发人员从这项重要,但是枯燥的任务中解脱出来[1]。
2.2. CheckStyle检验的主要内容
CheckStyle默认提供一下主要检查内容:
·Javadoc注释
·命名约定
·标题
·Import语句
·体积大小
·空白
·修饰符
·块
·代码问题
·类设计
·混合检查(包活一些有用的比如非必须的System.out和printstackTrace)
从上面可以看出,CheckStyle提供了大部分功能都是对于代码规范的检查,而没有提供象PMD和Jalopy那么多的增强代码质量和修改代码的功能。但是,对于团队开发,尤其是强调代码规范的公司来说,它的功能已经足够强大。
2.3. CheckStyle的主要运行方式
目前,CheckStyle的版本是3.0,与以前的版本不同,它的配置文件是基于XML而非Properties文件。
它的3.0版本提供了两种运行的方式:
·命令行工具
·ANT任务
同时,CheckStyle目前有很多针对流行IDE的插件,例如Eclipse、IntelliJ IDEA、JBuilder等。但是,大部分都是基于2.4的版本,新版本的特性不支持,同时配置也较为复杂。
因为一般情况下,如果与开发过程与环境集成起来,编码规范的检查会更加有效,因此,作为ANT任务的运行方式使用的更加普遍。
文章来源于领测软件测试网 https://www.ltesting.net/