刚才在ibm上面看了一个关于敏捷开发中代码的高质量的文档,感觉总结的很好,在文档中也用到了很多工具来保证代码的质量,在这里mark下
首先上总体图:
- 一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。
- 命名规则。例如包名、类名、变量、方法、接口、参数等命名规范
- 文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。
- 编程规范。例如异常、并发、多线程等方面的处理方式。
- 其他规范。例如日志格式、属性文件格式,返回值和消息格式。
一旦编码规范确定,就可以利用 Eclipse 自身提供的功能来控制代码样式和格式。具体做法是,点击 Eclipse 的 Windows -> Preference 菜单项,在打开的 Preferences 对话框的左侧栏中找到 Java 节点下的子项 Code Style(如图 2),该项和它的子项允许您对 Java 代码的样式进行控制。
现在的静态分析工具很多,有 FindBugs、PMD、IBM Rational Tool,等等
例如findbugs,检查完毕后,会出现 FindBugs 视图,把所有检查的结果根据错误分组展示。点击结果里面的每一个错误,会自动打开对应的代码。当根据规则改正了所有的错误,或者说潜在错误,这些代码也就 通过了静态代码检查。FindBugs 的检查结果可以是 XML 文件,也可以是文本文件,便于项目的集成管理和检查保存。
单元测试是软件开发过程中重要的质量保证环节,在此环节中,设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要 具体考虑要对哪些代码单元进行测试,被测单元之间的关系,测试策略,以及单元测试用例设计等,并最终输出《单元测试用例设计》文档,用来指导具体的单元测 试执行。在用例设计中,通过对代码单元输入和期待输出的定义来保证该单元的功能正确性,边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹 配方法来衡量用例设计的完整性。
在用例设计完成之后,下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的,用例评审可以借集体之力,对用例设计进入查漏补 缺,进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴,它主要通过对代码的逻辑结构进行分析来设计测试用例,因此,评审员的选择最好以理解代码 逻辑结构为前提,如果评审员来自相关模块,还能够有效的发现模块相关性和依赖性所带来的问题。
在实际项目中,开发人员自己的代码往往需要和其他的代码模块或系统进行交互,但在测试的过程中,这些需要被调用的真实对象常常很难被实例化, 或者这些对象在某些情况下无法被用来测试,例如,真实对象的行为无法预测,真实对象的行为难以触发,或者真实对象的运行速度很慢。这时候,就需要使用模拟 对象技术(Mock),利用一个模拟对象来模拟我们的代码所依赖的真实对象,来帮助完成测试,提高测试覆盖率,从而提高代码质量。模拟对象技术利用了在面 向接口的编程中,由于代码直接对接口进行调用,所以代码并不知道引用的是真实对象还是模拟对象,这样就可以顺利的完成对代码的测试。
模拟技术有很多种,如 jMock,EasyMock,Mockito,PowerMock 等等。其中 Mockito 消除了对期望行为的需求,避免了这些代码的大量初始化。
EMMA 是一款比较流行的开源 Java 测试覆盖率分析工具,支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析,支持将覆盖率分析结果导出为多种格式的报告,并采用多种颜色来高亮显 示不同的覆盖率状态。EclEmma 是一款基于 EMMA 的 Eclipse 插件,方便在 Eclipse IDE 中进行测试覆盖率分析。如图 9,在测试用例写好后,可以在右键点击测试类,选择 Coverage As -> JUnit Test.
持续集成(Continuous Integration)是利用一系列的工具,方法和规则,做到快速的构建开发代码,自动的测试化,来提高开发代码的效率和质量。利用自动构建工具,随时 都能把提交的代码构建出来,提供一个可以测试使用的版本,让用户和开发人员同时看到相同的功能,尽早的发现问题和错误,也可以尽快的得到测试人员和用户的 反馈。
要做到持续集成,就要利用一系列工具,把开发过程中的重复工作自动化。搭建自动的构建服务器,自动的进行单元测试和发布新版本,一个集成的服 务器可以提供构建过程的结果报告,自动通知开发人员构建结果,并且保存历史数据。IBM Rational Team Concert (RTC) 可以提供工作任务的管理,项目计划的安排,代码版本管理控制,自动构建可用版本,生成构建结果报告。这些过程构成了项目的持续集成过程,其中,版本的自动 构建和代码的自动单元测试是持续集成的关键过程,RTC 在这些过程上提供了有力的支持。
代码评审(Code Review)是 Java 项目开发过程中的一个重要步骤,代码评审可以帮助发现静态代码分析过程中无法发现的一些问题,例如代码的编写是否符合编码规范,代码在逻辑上或者功能上是 否存在错误,代码在执行效率和性能上是否有需要改进的地方,代码的注释是否完整正确,代码是否存在冗余和重复。代码评审还可以帮助新进入项目组的成员快速 学习和了解项目,促进经验分享,同时也能保证项目成员的良好沟通。代码评审主要包括两种形式,同级评审(Peer Review)和小组评审(Group Review)。同级评审主要指项目成员间的互相评审,小组评审是指通过召开评审会议,项目成员一起对项目代码进行评审。
为了提高代码评审的有效性和效率,可以借助一些外部工具,比较常用的代码评审工具有 Jupiter 和 Code Striker。Jupiter 是一款开源的 Eclipse 插件,允许成员将评审意见定位到真实代码的具体行,由于代码评审的结果以 XML 文件的形式保存,所以可以把结果提交到版本管理服务器进行共享。