2013-12-26 12:59:17 dongjian764 阅读数 1905
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

        敏捷软件开发方法目的是适应需求的快速响应,能够快速的发布和快速的交付使用。 在敏捷中的如何实现配置管理,如何通过配置管理来管理敏捷开发过程中的需求、代码、版本等,这是应该是一个专向的课题。

       敏捷中的配置管理有如下几个方面需要考虑: 

       1、适应敏捷需求的变化,快速的纳入需求版本管理

       2、适应频繁的代码构造和频繁的发布;

       3、能够提供准确的发布版本的内容;

       4、如何和持续集成结合,做好持续集成的最后的结果输出,提高持续的交付能力


      配置管理与持续集成

     在传统的软件开发方法中配置管理系统或是工具是独立存在,可以独立运行。 没有持续集成概念,缺乏需求-〉设计-〉开发-〉测试-〉构造-〉发布整个流程的连续性。

     在敏捷方法中的一个重要的最佳实践是持续集成,它实现了代码-〉单元测试-〉构造-〉部署-〉集成测试-系统测试 过程,这个过程是软件研发过程中中间那段核心过程点,但是也缺乏连续性。它缺少的正式产品管理-需求管理 和 发布管理两部分,这部分内容正是配置管理中管理的两个重要的功能点。

     综上,考虑整合现有的配置管理和持续集成,做成一个统一管理平台如何?

    



产品规划:在平台中进行产品结构设计,完成产品定义,业务模块定义, 发布定义(可以是安装盘形式,也可以其他某种形式如war包)

开发设计:完成开发模块定义、开发模块与业务模块关系定义

初始配置:代码配置库的建立,可以按开发模块建库。

持续集成:集成构造、集成打包、集成测试、集成做盘(生成安装宝过程)、安装部署、系统测试

版本发布:根据测试结果和发布评估后,可以直接在集成版本库中提取,最后的安装盘进行发布

补丁发布:根据每次集成过程的代码提交信息获取获取需求或缺陷列表, 通过集成状态结果可以清晰的指到那个需求已经被集成,在那个版本的安装盘中,是否被测试通过等等信息。  根据这些信息选择要打入补丁的需求,根据需求id查找代码提交事件id,根据事件id找到文件变更信息。 依次就可以打出一个比较完成的补丁包,并可以附加上所有集成和验证的信息。


综上讨论:在敏捷中基于持续集成系统或平台,实现配置管理工作,使得流程更加顺畅,版本控制更加严谨和变更追溯性强等。 整合配置管理和持续集成是敏捷方法中的一个比较好的配置管理实践方法。

欢迎大家讨论。


2011-08-06 00:32:36 iteye_4568 阅读数 25
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的代码质量。

Java项目开发过程中,由于开发人员的经验、Java代码编写习惯,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。

如图1所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构 (Review&Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。

敏捷开发中的Java代码质量保证步骤

图1.敏捷开发中的Java代码质量保证步骤

步骤一:统一编码规范、代码样式

规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面:

◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。

◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范

◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。

◆编程规范。例如异常、并发、多线程等方面的处理方式。

◆其他规范。例如日志格式、属性文件格式,返回值和消息格式。

项目的编码规范可以参考已有的一些Java编程规范书籍和其他相关资料并结合项目的本身来制定,可供参考的书籍有《Java编程风格》(英文书名为:TheElementsofJavaStyle)。编码规范要形成文档,而且要简洁明了,并组织项目成员一起学习,确保所有成员正确理解所有条目。

一旦编码规范确定,就可以利用Eclipse自身提供的功能来控制代码样式和格式。具体做法是,点击Eclipse的 Windows->Preference菜单项,在打开的Preferences对话框的左侧栏中找到Java节点下的子项CodeStyle(如图2),该项和它的子项允许您对Java代码的样式进行控制。

Eclipse代码样式设置窗口

图2.Eclipse代码样式设置窗口

例如,为了使用自动格式化工具,可以在Eclipse提供的默认代码格式配置的基础上建立自定义的格式。在Formatter面板中,点击 New,输入新的名字并选择一个默认的配置作为初始化格式,如图3所示。

创建新的代码格式配置

图3.创建新的代码格式配置

单击OK后就可以在新打开的窗口中进行修改定制自己需要的格式。如图4所示。

创建新的代码格式配置

图4.创建新的代码格式配置

修改完成后点击Apply保存所作修改。同时可以点击Export将当前的格式定义导出成一个XML文件,这样项目组的其他成员就可以很方便通过点击图3中的Import按钮来导入该XML文件来使用同一个代码格式定义。

这样每次在提交代码到版本控制服务器前就可以通过Eclipse界面里的Source->Format菜单来对代码进行格式化,从而使整个项目的代码具有相同的格式。同样可以通过对CodeStyle下的其他项目进行设置来帮助对Java代码的样式进行控制。将所有这些样式文件导出成 XML文件后,同编码规范一起归档,供所有项目成员使用。

步骤二:静态代码分析

在完成源代码的开发以后,下面要进行的工作就是审视和测试代码。除了通过运行测试代码来检查功能之外,还能利用一些静态分析工具来快速、直接地提高代码质量。静态代码分析工具并不需要运行代码,可以直接对Java文件和Class文件进行分析,通过一些检查条件的设置,快速找到代码中的错误和潜在缺陷。现在的静态分析工具很多,有FindBugs、PMD、IBMRationalTool,等等。在这里,选择FindBugs作为静态代码分析工具。FindBugs可以和日常开发工具Eclipse进行集成,在开发过程中,就可以方便的开始静态代码的检查。通过检查Class文件或者JAR文件,将字节码和一组缺陷模式进行对比,来发现可能存在的代码问题。在Eclipse的开发环境中,用插件安装的方式安装了Findbugs后,在 Eclipse的配置选项中就会多出来FindBugs的配置选项。可以对自己的项目进行配置,选择需要的Detector检查代码。

FindBugs的配置选项

图5.FindBugs的配置选项

设置好自己的规则后,在需要检查的代码文件夹上点击右键,就可以启动FindBugs检查。代码可以是一个项目,也可以只是几个文件。

运行FindBugs

图6.运行FindBugs

检查完毕后,会出现FindBugs视图,把所有检查的结果根据错误分组展示。点击结果里面的每一个错误,会自动打开对应的代码。当根据规则改正了所有的错误,或者说潜在错误,这些代码也就通过了静态代码检查。FindBugs的检查结果可以是XML文件,也可以是文本文件,便于项目的集成管理和检查保存。

FindBugs检查结果

图7.FindBugs检查结果

步骤三:单元测试

单元测试用例设计和评审

单元测试是软件开发过程中重要的质量保证环节,在此环节中,设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要具体考虑要对哪些代码单元进行测试,被测单元之间的关系,测试策略,以及单元测试用例设计等,并最终输出《单元测试用例设计》文档,用来指导具体的单元测试执行。在用例设计中,通过对代码单元输入和期待输出的定义来保证该单元的功能正确性,边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹配方法来衡量用例设计的完整性。

在用例设计完成之后,下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的,用例评审可以借集体之力,对用例设计进入查漏补缺,进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴,它主要通过对代码的逻辑结构进行分析来设计测试用例,因此,评审员的选择最好以理解代码逻辑结构为前提,如果评审员来自相关模块,还能够有效的发现模块相关性和依赖性所带来的问题。

模拟对象技术

在实际项目中,开发人员自己的代码往往需要和其他的代码模块或系统进行交互,但在测试的过程中,这些需要被调用的真实对象常常很难被实例化,或者这些对象在某些情况下无法被用来测试,例如,真实对象的行为无法预测,真实对象的行为难以触发,或者真实对象的运行速度很慢。这时候,就需要使用模拟对象技术(Mock),利用一个模拟对象来模拟我们的代码所依赖的真实对象,来帮助完成测试,提高测试覆盖率,从而提高代码质量。模拟对象技术利用了在面向接口的编程中,由于代码直接对接口进行调用,所以代码并不知道引用的是真实对象还是模拟对象,这样就可以顺利的完成对代码的测试,模拟技术有很多种,如 jMock,EasyMock,Mockito,PowerMock等等。其中Mockito消除了对期望行为的需求,避免了这些代码的大量初始化。

Mockito示例

图8.Mockito示例

在模拟对象过程中,先模拟一个需要调用的List对象LinkedList,再设定这个对象的行为,当调用get(0)的时候,返回”first”。这样,测试代码就可以利用这个对象来测试我们的功能代码,需要调用和返回值的时候,可以顺利的得到模拟对象的返回值。也需要对模拟对象进行错误情况的模拟,保证代码对错误的处理的正确性。

测试覆盖率分析

为了衡量单元测试的质量和覆盖的范围,需要对单元测试的代码进行测试覆盖分析。常用的衡量测试覆盖率的指标主要有语句覆盖率、分支覆盖率、路径覆盖率、条件覆盖率和方法覆盖率等。具体采用哪些指标可以根据项目的实际情况来定,以避免因过高的指标增加了代码开发人员的工作量而影响了项目整体的进度。

EMMA是一款比较流行的开源Java测试覆盖率分析工具,支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析,支持将覆盖率分析结果导出为多种格式的报告,并采用多种颜色来高亮显示不同的覆盖率状态。EclEmma是一款基于EMMA的Eclipse插件,方便在 EclipseIDE中进行测试覆盖率分析。如图9,在测试用例写好后,可以在右键点击测试类,选择CoverageAs->JUnitTest。

运行测试覆盖分析

图9.运行测试覆盖分析

单元测试跑完后,Coverage视图中会显示所选择的测试的覆盖率。双击打开某一具体的类后,可以看到高亮显示的覆盖分析结果,如图10所示。红色代表测试没有覆盖到该行,黄色表示部分覆盖,绿色的行表示该行在本次测试中被覆盖到。

查看测试覆盖分析结果

图10.查看测试覆盖分析结果

在Coverage视图中可以通过点击鼠标右键将测试覆盖分析的结果导出成需要的格式,例如HTML。

导出测试覆盖分析结果

图11.导出测试覆盖分析结果

图12显示了导出的report。

测试覆盖分析报告

图12.测试覆盖分析报告

为了保证单元测试的有效性和质量,可以规定一个测试覆盖率的下限,例如所有的包和类的覆盖率必须达到80%以上。不过值得注意的是,不要单纯追求高覆盖率,要同时注意测试用例的质量,如果测试用例本身就写的有错误,那么即使测试覆盖率很高也没有意义。

步骤四:持续集成

持续集成(ContinuousIntegration)是利用一系列的工具,方法和规则,做到快速的构建开发代码,自动的测试化,来提高开发代码的效率和质量。利用自动构建工具,随时都能把提交的代码构建出来,提供一个可以测试使用的版本,让用户和开发人员同时看到相同的功能,尽早的发现问题和错误,也可以尽快的得到测试人员和用户的反馈。

要做到持续集成,就要利用一系列工具,把开发过程中的重复工作自动化。搭建自动的构建服务器,自动的进行单元测试和发布新版本,一个集成的服务器可以提供构建过程的结果报告,自动通知开发人员构建结果,并且保存历史数据。 IBMRationalTeamConcert(RTC)可以提供工作任务的管理,项目计划的安排,代码版本管理控制,自动构建可用版本,生成构建结果报告。这些过程构成了项目的持续集成过程,其中,版本的自动构建和代码的自动单元测试是持续集成的关键过程,RTC在这些过程上提供了有力的支持。

自动构建

RTC提供了buildengine来负责构建build,首选,启动buildengine,并和RTC服务器建立了连接。再创建项目的 build定义。在这个定义中,需要设定编译哪些模块的代码,需要跳动哪个ANT文件来启动编译,和一些编译过程中的参数的设定。当这些都准备好了,编译对于项目而言,就变成一个简单的事情。

可以看到,通过在build定义上,点击请求构建,就可以触发一次构建过程。选择需要的构建参数,这个过程就会在后台运行。每一个开发人员,做了稍许的代码改变和提交,都可以触发新的构建过程,来保证我们代码的有效性。申请一个新的构建的过程如图13、图14所示。

申请一个新的构建

图13.申请一个新的构建

构建申请界面

图14.构建申请界面

当构建结束后。RTC服务器会提供构建结果报告。开发人员可以查询到这次构建的详细信息。

构建结果

图15.构建结果

整个开发过程中,构建版本的过程应该是无数次的,通过每次构建,都可以得到当时代码的编译情况,并且可以得到一个可运行的软件版本。在构建定义上,RTC支持设置构建计划。定时自动的触发一次构建。

构建定义

图16.构建定义

自动单元测试

构建可以自动了,重点提高代码质量的单元测试呢?如果每一天的代码,每一个版本的代码,都已经通过了我们的单元测试,这样我们就能对代码的质量有了基本的保证。在构建脚本的自动调用过程中,通过ANT的脚本,可以加上JUnit,EMMA,FindBugs的ANT脚本调用,每一次的构建,都可以把这些检查工作自动的进行一遍测试。这些测试都要生成测试结果报告,RTC不能提供这些报告的展示,就可以利用Hudson这个开源工具,集成测试报告来方便查阅。

自动测试报告

图17.自动测试报告

步骤五:代码评审和重构

代码评审(CodeReview)是Java项目开发过程中的一个重要步骤,代码评审可以帮助发现静态代码分析过程中无法发现的一些问题,例如代码的编写是否符合编码规范,代码在逻辑上或者功能上是否存在错误,代码在执行效率和性能上是否有需要改进的地方,代码的注释是否完整正确,代码是否存在冗余和重复。代码评审还可以帮助新进入项目组的成员快速学习和了解项目,促进经验分享,同时也能保证项目成员的良好沟通。代码评审主要包括两种形式,同级评审(PeerReview)和小组评审(GroupReview)。同级评审主要指项目成员间的互相评审,小组评审是指通过召开评审会议,项目成员一起对项目代码进行评审。

为了提高代码评审的有效性和效率,可以借助一些外部工具,比较常用的代码评审工具有Jupiter和CodeStriker。Jupiter是一款开源的Eclipse插件,允许成员将评审意见定位到真实代码的具体行,由于代码评审的结果以XML文件的形式保存,所以可以把结果提交到版本管理服务器进行共享。图18显示了使用Jupiter进行代码评审的界面。

Jupiter代码评审界面

图18.Jupiter代码评审界面

在代码评审任务创建后,Jupiter将代码评审分成三个阶段,个人评审阶段(IndividualPhase)、团队评审阶段 (TeamPhase)和问题修复阶段(ReworkPhase)。在个人评审阶段,评审成员将发现的代码问题或者缺陷记录下来,每个问题都会作为一个记录保存在评审表格中。在团队评审阶段,团队的全部或者部分成员会一起对个人评审阶段发现的问题进行定性,如果问题确实存在,就将该问题分配给某个成员去解决,并在Jupiter中将该问题设置成相应的状态。在问题修复阶段,团队成员会修复属于自己的问题,并将相应的记录设置成已解决等正确的状态。

Codestriker是一款基于Web的常用代码评审工具,对代码的评审可以针对某一具体行,也可以针对整个代码文件,评审意见会被保存在数据库中。评审人员可以同时看到其他人的评论,代码作者也可以针对某一具体的评论回复。Codestriker支持邮件通知,还可以同版本控制服务器进行集成,以跟踪和显示文件内容的改变。图19显示了Codestriker的界面。

Codestriker报告界面

图19.Codestriker报告界面

在实践中对所有代码进行小组评审会比较费时,所以可以根据实际情况来挑选一些核心代码进行小组评审,或者在项目的前期安排较多的小组评审,等项目组的成员对代码评审的标准和要求有较好的理解,进行代码评审的经验提高后,就可以逐渐减少小组评审的次数,从而达到大部分代码即使只进行同级评审也能保证很好的质量。

通过代码评审发现的问题要通过代码重构及时解决掉,较小的不涉及多人代码的重构可以由项目成员自己借助Eclipse的重构功能完成,不同项目成员写的实现相同功能的不同代码要通过讨论整合成公共的类或者方法。比较复杂的或者比较高层次的重构工作,例如整个项目层面的代码组织形式的改变需要由整个项目组共同讨论完成。

结论

软件开发没有一成不变、万能通用的流程和方法,希望大家能从本文得到启发和收益,结合您的实际项目特点,实践以上步骤和方法,并加以完善和改进,共同打造高效高质量的Java代码,为您的项目成功奠定坚实的基础。

<!-- 正文结束 -->
2015-11-03 16:30:22 uxyheaven 阅读数 17960
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

敏捷开发知识体系整体框架

敏捷开发工程实践

项目管理

  • 迭代开发
  • 风险价值生命周期
  • 多级项目规划
  • 完整团队
  • 每日站立会议
  • 任务板
  • 燃尽图

需求管理

  • 需求订单
  • 业务流程草图
  • 用例驱动开发
  • 用户故事

架构

  • 演进的架构
  • 演进的设计
  • 基于组件的架构设计

开发

  • 结对编程
  • 测试驱动开发
  • 重构
  • 代码规范

测试

  • 单元测试
  • 并行测试
  • 测试管理

变更管理

  • 持续集成
  • 自动构建
  • 团队变更管理

敏捷开发管理实践描述

  • 定义和特征说明
  • 主要角色
  • 主要活动和最佳实践
  • 主要输入输出
  • 工作流程

敏捷开发工程实践描述

  • 定义和特征说明
  • 应用说明
  • 案例说明

敏捷开发核心价值观和原则

敏捷软件开发宣言

个体和互动 高于 流程和文档
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说, 尽管右项有其价值, 我们更重视左项的价值.

敏捷软件开发的核心价值观

敏捷开发的核心理念就是以最简单有效的方式快速打成目标, 并在这个过程中及时地响应外界的变化, 做出迅速的调整.

核心价值观

  • 以人为本
  • 目标导向
  • 客户为先
  • 拥抱变化

敏捷开发的原则

  • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
  • 可工作的软件是进度的首要度量标准。
  • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  • 以简洁为本,它是极力减少不必要工作量的艺术。
  • 最好的架构、需求和设计出自自组织团队。
  • 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷开发管理实践

Scrum

Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。

Scrum中的角色

“猪”角色

  • 产品负责人(Product Owner)
    • 通常由市场部门的人担任
  • 敏捷教练 (Scrum Master)
    • 通常由开发组组长担任
  • 开发团队 (Scrum Team)
    • 包括开发,需求,测试

“鸡”角色

  • 用户
    • 软件是为了某些人而创建!就像“假如森林里有一棵树倒下了,但没有人听到,那么它算发出了声音吗”,“假如软件没有被使用,那么它算是被开发出来了么?”
  • 利益所有者 (客户,提供商)
    • 影响项目成功的人, 但只直接参与冲刺评审过程。
  • 管理者
    • 为产品开发团体架起环境的那个人

主要活动和最佳实践

  • 迭代式软件开发
  • 两层项目规划 (Two-Level Project Planning)
  • 整体团队协作 (Whole Team)
  • 持续集成
  • 冲刺规划会议 (Sprint Plan Meeting)
  • 每日站立会议 (Sprint Daily Meeting)
  • 冲刺复审会议 (Sprint Review Meeting)
  • 冲刺回顾会议 (Retrospective Meeting)

scrum方法中得主要活动和交付件

主要输入输出

  • 产品订单(Product Backlog)
  • 冲刺订单(Spring Backlog)
  • 燃尽图(Burndown Chart)
  • 新的功能增量

工作流程

scrum方法全景图

项目管理过程

  • 在Scrum项目管理过程中产品负责人获取项目投资, 并对整个产品的成功负责.
  • 产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级, 完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作.

项目开发过程

在Scrum软件开发过程中, 每个冲刺就是较短的迭代, 通常为2~4周.

  • 在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践, 制定冲刺订单(类似迭代计划)
  • 产品负责人明确在本次冲刺中实现的需求清单, 响应的工作任务和负责人.
  • 在每个冲刺迭代中, 团队强调应用”整体团队协作”的最佳实践, 通过保持可持续发展的工作节奏和每日站立会议, 实现团队的自组织, 自适应和自管理, 高效完成冲刺工作.
  • 在每个冲刺结束时, 团队都会召开冲刺复审会议, 团队成员会在会上分别展示他们开发出的软件(或其他有价值的产品), 并从产品负责人和其他利益关系人那里, 得到反馈信息.
  • 在冲刺复审会议之后, 团队会自觉招开冲刺回顾会议, 回顾整个项目过程, 讨论哪些方法做的好, 哪些方面可以改进, 实现软件交付过程的持续, 自发的改进.

XP

OpenUp

Lean

敏捷开发工程实践

迭代式开发

敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分, 或前期开发并不详尽的软件, 每次开发结束获得可以运行的软件, 以供各方干系人观测, 获得反馈, 根据反馈适应性的进行后续开发, 经过发福多次开发, 逐步增加软件部分, 逐步补充完善软件, 最终开发得到最后的软件. 每次反复开开发叫一次迭代, 在Scrum中成为Sprint, 中文常译为”冲刺”.

持续集成

持续集成(Continuous integration)是指当代码提交后, 马上启动自动编译, 自动部署金额自动化测试来快速验证软件, 从而尽快的发现集成错误.

多级项目规划

多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步细化的项目或产品计划. 这些层层相关的项目/产品规划包括:

  • 项目/产品愿景
  • 项目/产品路线图
  • 版本发布计划
  • 迭代计划
  • 每日实现

项目/产品愿景

在计划阶段, 首先, 项目stakeholder, 项目/产品负责人将参与并组成工作组, 他们负责阐述项目的重要性, 给出项目成功失败的关键标准以及项目整体层面”完成”的定义; 在过程中, 可以利用形成项目愿景的一些个工具, 包括愿景盒子(Vison Box), 业务收益矩阵(Business Benefits Matrix), 项目范围矩阵(Scope Matrix), 滑动器(Slider), 成本收益矩阵(Cost/Benefit Matrix)等; 最后, 项目愿景需要使用尽量简要的文档固定下来, 并保证项目团队成员都能了解.该文档需要包括:

  • 当前的问题
  • 机会描述和理由(描述项目的重要性)
  • 项目的价值
  • 项目如何和组织的战略目标达成一致
  • 解决方案综述
  • 项目包含的关键功能
  • 项目必须服从的技术和约束条件
  • 项目范围
  • 项目的关键时间线
  • 项目收益分析
  • 项目和其他项目的依赖性
  • 项目的相关风险以及如何消除

项目/产品路线图

主要描述为了达到产品愿景而需要交付的关键功能和特性, 这些特性基本处于Epic和特性层面, 不包裹用户故事(User Story). 它从时间的维度来表述对愿景的支持和实现. 它从时间维度来表达对愿景的支持和实现. 当项目/产品需要发布多个版本时, 项目线路图就非常重要, 否则, 它和发布计划相同, 项目/产品线路图由项目负责人和项目经理维护, 并保持更新. 通常, 会形成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功能和发布日期等, 让所有项目/产品相关人员都清楚产品各个组件的可能发布日程.

版本发布计划

版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论通过. 它包括了当前版本需要交付的, 达成一致的关键功能, 并经过优先级排序, 可以包含EPIC和User Story. 版本发布计划中常使用的概念包括:故事点, 迭代团队速率和优先级排序. 通常, 项目/产品负责人提出本次发布的目标, 团队成员根据目标和功能特性的重要性对故事进行排序, 并依据团队速率觉得本次发布需要包含的故事点. 前几次版本发布使用估算值, 其准确性随着项目/产品的时间持续而逐步精确. 版本发布计划是剧本适应性可调整的计划, 会随着项目演进而改变.

迭代计划

迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定, 并听过迭代计划会议讨论通过. 迭代会议负责两件事情:

  • 根据当前状态确定是否需要对版本计划做出更新
  • 为当前的迭代计划制定迭代计划

迭代计划中常使用的概念包括: 拆分Epic和User Story, 任务, 任务估算. 在迭代会议上, 成员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事, 并对这些故事进行详细的任务拆分. 成员在认领完任务后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度.

每日实现

没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情况更新该值. 在敏捷方法中, 使用每日站会议来报告进度. 通过15分钟的站立形式, 团队成员报告故事或者任务的完成,未完成状态, 而解决层面的问题则在会议之后处理.

完整团队

Scrum团队必须具备的三个完整性:

团队职责完整性

产品负责人(Product Owner)

  • 确定产品的功能。
  • 决定发布的日期和发布内容。
  • 为产品的收益(profitability of the product)负责。
  • 根据市场价值确定功能优先级。
  • 在30天内调整功能和调整功能优先级。
  • 接受或拒绝接受开发团队的工作成果

敏捷教练 (Scrum Master)

  • 负责监督整个Scrum项目进程, 调整开发计划
  • 保证团队资源完全可被利用并且全部是高产出的。
  • 保证各个角色及职责的良好协作。
  • 解决团队开发中的障碍。
  • 做为团队和外部的接口,屏蔽外界对团队成员的干扰。
  • 保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
  • 需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化. 根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图
  • 需要找出阻碍Scrum的障碍和依赖, 根据优先级指定计划解决这些障碍
  • 个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清,或通过内部的沟通解决,或向管理层和HR寻求帮助解决
  • Scrum Master需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化。Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数,进展中的工作需要得到最小化,以实现精益生产率的收益。
  • Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决,有些则要团队之间的协调,还有的要管理层的介入来解决.

开发团队 (Scrum Team)

  • 具有不同特长的团队成员,人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
  • 弱化分工, 每个人都参与设计, 开发与测试
  • 确定Sprint目标和具体说明的工作成果。
  • 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
  • 向Product Owner演示产品功能。

团队素质完整性

  • 要具备很强的集体协作精神.
  • 要具备良好的沟通能力
  • 必须能积极主动的接受新的事物, 要具备创新能力
  • 要具备极强的自我管理能力和积极主动的精神

沟通的完整性

  • Sprint启动会
  • 每日站立会议
  • Sprint回顾会

案例

验收测试驱动开发ATDD

TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

  • 挑选用户故事
  • 为故事写测试
  • 实现测试
  • 实现故事

结对编程

结对编程可以看做是一种敏捷化的Code Review

新结对编程

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

确定冲刺计划

定义和说明

  • 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
  • 主要角色: ST, PO, SM
  • 主要输入: Product backlog, 团队的能力
  • 主要输出: Sprint Backlog

冲刺会议分两个部分
1. 解决本次冲刺要完成哪些需求
2. 解决这些选择的需求要如何被完成

案例

故事点估算

故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

计划扑克

  • 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
  • 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
  • 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
  • 最高分和最低分的组员像团队做出解释
  • 全组成员自由讨论几分钟
  • 重新打分, 直到全组统一.

敏捷估算2.0(Agile Estmating 2.0)

  • PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
  • 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
  • 团队将故事点(Story Point)分配给每个故事.

需求订单(Product Backlog)

记录用户需求的列表, 包括产品所有需要的特征.

  • 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
  • 需求订单式开放的, 团队每个成员都可以编写和维护
  • 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

燃尽图

在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

  • 具备可视性
  • 具备风险预估, 提醒团队目前完成情况
  • 具备可估量, 直接显示当前还需要的时间.

燃尽图常见问题

每日站立会议(Daily Scrum)

每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

  • 我们上次开会后你都干了什么
  • 在我们下次开会之前你要做什么
  • 每个你负责的、正在做的任务还剩下多少时间
  • 你的工作被阻碍了吗

任务板(Task board)

  • 为项目团队提供一个便利的工具用于管理他们的工作
  • 是团队成员对本冲刺的工作一目了然

任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

用户故事卡

每张卡片记录一条用户故事, 故事点.

任务卡

每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

任务板的使用

用户故事

作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

测试驱动开发(TDD)

先开发测试用例, 然后再开发代码

2010-08-24 13:55:00 jiulingchen126 阅读数 198
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

Java 项目开发过程中,由于开发人员的经验、代码风格各不相同,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。本文将结合敏捷开发周期短,变化快等特点,介绍如何通过在开发过程中采取一系列步骤来保证和提高整个开发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高质量的代码,减少测试的投入,并促进整个团队的技能提高,最终提高开发效率和质量。

  如图 1 所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下五个步骤来保证和提高整个项目的代码质量:统一编码规范、代码样式;静态代码分析(static code review);单元测试;持续集成;代码评审和重构(Review & Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。 

 敏捷开发中高质量Java代码开发实践

图 1. 敏捷开发中的 Java 代码质量保证步骤

2011-06-06 23:14:00 guolong1983811 阅读数 407
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

转贴:http://www.oschina.net/question/12_7693

 

Java 项目开发过程中,由于开发人员的经验、代码风格各不相同,以及缺乏统一的标准和管理流程,往往导致整个项目的代码质量较差,难于维护,需要较大的测试投入 和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。本文将结合敏捷开发周期短,变化快等特点,介 绍如何通过在开发过程中采取一系列步骤来保证和提高整个开发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高 质量的代码,减少测试的投入,并促进整个团队的技能提高,最终提高开发效率和质量。

如图 1 所示,敏捷开发过程经历需求调研,用例分析和用例分解,进入开发迭代阶段。在每个迭代过程中,可以采用以下五个步骤来保证和提高整个项目的代码质量:统一 编码规范、代码样式;静态代码分析(static code review);单元测试;持续集成;代码评审和重构(Review & Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。


图 1. 敏捷开发中的 Java 代码质量保证步骤
图 1. 敏捷开发中的 Java 代码质量保证步骤

步骤一:统一编码规范、代码样式

规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的 Java 代码开发人员的编码风格常常各不相同,这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他项目成员或者维护人员在阅读项目代码 时就需要花费更多的时间来理解代码作者的意图,所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面:

  • 一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。
  • 命名规则。例如包名、类名、变量、方法、接口、参数等命名规范
  • 文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。
  • 编程规范。例如异常、并发、多线程等方面的处理方式。
  • 其他规范。例如日志格式、属性文件格式,返回值和消息格式。

项目的编码规范可以参考已有的一些 Java 编程规范书籍和其他相关资料并结合项目的本身来制定,可供参考的书籍有《 Java 编程风格》(英文书名为:The Elements of Java Style)。编码规范要形成文档,而且要简洁明了,并组织项目成员一起学习,确保所有成员正确理解所有条目。

一旦编码规范确定,就可以利用 Eclipse 自身提供的功能来控制代码样式和格式。具体做法是,点击 Eclipse 的 Windows -> Preference 菜单项,在打开的 Preferences 对话框的左侧栏中找到 Java 节点下的子项 Code Style(如图 2),该项和它的子项允许您对 Java 代码的样式进行控制。


图 2. Eclipse 代码样式设置窗口
图 2. Eclipse 代码样式设置窗口

例如,为了使用自动格式化工具,可以在 Eclipse 提供的默认代码格式配置的基础上建立自定义的格式。在 Formatter 面板中,点击 New,输入新的名字并选择一个默认的配置作为初始化格式,如图 3 所示。


图 3. 创建新的代码格式配置
图 3. 创建新的代码格式配置

单击 OK 后就可以在新打开的窗口中进行修改定制自己需要的格式。如图 4 所示。


图 4. 创建新的代码格式配置
图 4. 创建新的代码格式配置

修改完成后点击 Apply 保存所作修改。同时可以点击 Export 将当前的格式定义导出成一个 XML 文件,这样项目组的其他成员就可以很方便通过点击图 3 中的 Import 按钮来导入该 XML 文件来使用同一个代码格式定义。

这样每次在提交代码到版本控制服务器前就可以通过 Eclipse 界面里的 Source->Format 菜单来对代码进行格式化,从而使整个项目的代码具有相同的格式。同样可以通过对 Code Style 下的其他项目进行设置来帮助对 Java 代码的样式进行控制。将所有这些样式文件导出成 XML 文件后,同编码规范一起归档,供所有项目成员使用。

步骤二:静态代码分析

在完成源代码的开发以后,下面要进行的工作就是审视和测试代码。除了通过运行测试代码来检查功能之外,还能利用一些静态分析工具来快速、直接 地提高代码质量。静态代码分析工具并不需要运行代码,可以直接对 Java 文件和 Class 文件进行分析,通过一些检查条件的设置,快速找到代码中的错误和潜在缺陷。现在的静态分析工具很多,有 FindBugs、PMD、IBM Rational Tool,等等。在这里,选择 FindBugs 作为静态代码分析工具。FindBugs 可以和日常开发工具 Eclipse 进行集成,在开发过程中,就可以方便的开始静态代码的检查。通过检查 Class 文件或者 JAR 文件,将字节码和一组缺陷模式进行对比,来发现可能存在的代码问题。在 Eclipse 的开发环境中,用插件安装的方式安装了 Findbugs 后,在 Eclipse 的配置选项中就会多出来 FindBugs 的配置选项。可以对自己的项目进行配置,选择需要的 Detector 检查代码。


图 5. FindBugs 的配置选项
图 5. FindBugs 的配置选项

设置好自己的规则后,在需要检查的代码文件夹上点击右键,就可以启动 FindBugs 检查。代码可以是一个项目,也可以只是几个文件。


图 6. 运行 FindBugs
图 6. 运行 FindBugs

检查完毕后,会出现 FindBugs 视图,把所有检查的结果根据错误分组展示。点击结果里面的每一个错误,会自动打开对应的代码。当根据规则改正了所有的错误,或者说潜在错误,这些代码也就 通过了静态代码检查。FindBugs 的检查结果可以是 XML 文件,也可以是文本文件,便于项目的集成管理和检查保存。


图 7. FindBugs 检查结果
图 7. FindBugs 检查结果

步骤三:单元测试

单元测试用例设计和评审

单元测试是软件开发过程中重要的质量保证环节,在此环节中,设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要 具体考虑要对哪些代码单元进行测试,被测单元之间的关系,测试策略,以及单元测试用例设计等,并最终输出《单元测试用例设计》文档,用来指导具体的单元测 试执行。在用例设计中,通过对代码单元输入和期待输出的定义来保证该单元的功能正确性,边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹 配方法来衡量用例设计的完整性。

在用例设计完成之后,下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的,用例评审可以借集体之力,对用例设计进入查漏补 缺,进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴,它主要通过对代码的逻辑结构进行分析来设计测试用例,因此,评审员的选择最好以理解代码 逻辑结构为前提,如果评审员来自相关模块,还能够有效的发现模块相关性和依赖性所带来的问题。

模拟对象技术

在实际项目中,开发人员自己的代码往往需要和其他的代码模块或系统进行交互,但在测试的过程中,这些需要被调用的真实对象常常很难被实例化, 或者这些对象在某些情况下无法被用来测试,例如,真实对象的行为无法预测,真实对象的行为难以触发,或者真实对象的运行速度很慢。这时候,就需要使用模拟 对象技术(Mock),利用一个模拟对象来模拟我们的代码所依赖的真实对象,来帮助完成测试,提高测试覆盖率,从而提高代码质量。模拟对象技术利用了在面 向接口的编程中,由于代码直接对接口进行调用,所以代码并不知道引用的是真实对象还是模拟对象,这样就可以顺利的完成对代码的测试。

模拟技术有很多种,如 jMock,EasyMock,Mockito,PowerMock 等等。其中 Mockito 消除了对期望行为的需求,避免了这些代码的大量初始化。


图 8. Mockito 示例
图 8. Mockito 示例

在模拟对象过程中,先模拟一个需要调用的 List 对象 LinkedList,再设定这个对象的行为,当调用 get(0) 的时候,返回”first”。这样,测试代码就可以利用这个对象来测试我们的功能代码,需要调用和返回值的时候,可以顺利的得到模拟对象的返回值。也需要 对模拟对象进行错误情况的模拟,保证代码对错误的处理的正确性。

测试覆盖率分析

为了衡量单元测试的质量和覆盖的范围,需要对单元测试的代码进行测试覆盖分析。常用的衡量测试覆盖率的指标主要有语句覆盖率、分支覆盖率、路 径覆盖率、条件覆盖率和方法覆盖率等。具体采用哪些指标可以根据项目的实际情况来定,以避免因过高的指标增加了代码开发人员的工作量而影响了项目整体的进 度。

EMMA 是一款比较流行的开源 Java 测试覆盖率分析工具,支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析,支持将覆盖率分析结果导出为多种格式的报告,并采用多种颜色来高亮显 示不同的覆盖率状态。EclEmma 是一款基于 EMMA 的 Eclipse 插件,方便在 Eclipse IDE 中进行测试覆盖率分析。如图 9,在测试用例写好后,可以在右键点击测试类,选择 Coverage As -> JUnit Test.


图 9. 运行测试覆盖分析
图 9. 运行测试覆盖分析

单元测试跑完后,Coverage视图中会显示所选择的测试的覆盖率。双击打开某一具体的类后,可以看到 高亮显示的覆盖分析结果,如图 10 所示。红色代表测试没有覆盖到该行,黄色表示部分覆盖,绿色的行表示该行在本次测试中被覆盖到。


图 10. 查看测试覆盖分析结果
图 10. 查看测试覆盖分析结果

在 Coverage 视图中可以通过点击鼠标右键将测试覆盖分析的结果导出成需要的格式,例如 HTML。


图 11. 导出测试覆盖分析结果
图 11. 导出测试覆盖分析结果

图 12 显示了导出的 report。


图 12. 测试覆盖分析报告
图 12. 测试覆盖分析报告

为了保证单元测试的有效性和质量,可以规定一个测试覆盖率的下限,例如所有的包和类的覆盖率必须达到 80% 以上。不过值得注意的是,不要单纯追求高覆盖率,要同时注意测试用例的质量,如果测试用例本身就写的有错误,那么即使测试覆盖率很高也没有意义。

步骤四:持续集成

持续集成(Continuous Integration)是利用一系列的工具,方法和规则,做到快速的构建开发代码,自动的测试化,来提高开发代码的效率和质量。利用自动构建工具,随时 都能把提交的代码构建出来,提供一个可以测试使用的版本,让用户和开发人员同时看到相同的功能,尽早的发现问题和错误,也可以尽快的得到测试人员和用户的 反馈。

要做到持续集成,就要利用一系列工具,把开发过程中的重复工作自动化。搭建自动的构建服务器,自动的进行单元测试和发布新版本,一个集成的服 务器可以提供构建过程的结果报告,自动通知开发人员构建结果,并且保存历史数据。IBM Rational Team Concert (RTC) 可以提供工作任务的管理,项目计划的安排,代码版本管理控制,自动构建可用版本,生成构建结果报告。这些过程构成了项目的持续集成过程,其中,版本的自动 构建和代码的自动单元测试是持续集成的关键过程,RTC 在这些过程上提供了有力的支持。

自动构建

RTC 提供了 build engine 来负责构建 build,首选,启动 build engine,并和 RTC 服务器建立了连接。再创建项目的 build 定义。在这个定义中,需要设定编译哪些模块的代码,需要跳动哪个 ANT 文件来启动编译,和一些编译过程中的参数的设定。当这些都准备好了,编译对于项目而言,就变成一个简单的事情。

可以看到,通过在 build 定义上,点击请求构建,就可以触发一次构建过程。选择需要的构建参数,这个过程就会在后台运行。每一个开发人员,做了稍许的代码改变和提交,都可以触发新 的构建过程,来保证我们代码的有效性。申请一个新的构建的过程如图 13、图 14 所示。


图 13. 申请一个新的构建
图 13. 申请一个新的构建

图 14. 构建申请界面
图 14. 构建申请界面

当构建结束后。RTC 服务器会提供构建结果报告。开发人员可以查询到这次构建的详细信息。


图 15. 构建结果
图 15. 构建结果

整个开发过程中,构建版本的过程应该是无数次的,通过每次构建,都可以得到当时代码的编译情况,并且可以得到一个可运行的软件版本。在构建定 义上,RTC 支持设置构建计划。定时自动的触发一次构建。


图 16. 构建定义
图 16. 构建定义

自动单元测试

构建可以自动了,重点提高代码质量的单元测试呢?如果每一天的代码,每一个版本的代码,都已经通过了我们的单元测试,这样我们就能对代码的质 量有了基本的保证。在构建脚本的自动调用过程中,通过 ANT 的脚本,可以加上 JUnit,EMMA,FindBugs 的 ANT 脚本调用,每一次的构建,都可以把这些检查工作自动的进行一遍测试。这些测试都要生成测试结果报告, RTC 不能提供这些报告的展示,就可以利用 Hudson 这个开源工具,集成测试报告来方便查阅。


图 17. 自动测试报告
图 17. 自动测试报告

步骤五:代码评审和重构

代码评审(Code Review)是 Java 项目开发过程中的一个重要步骤,代码评审可以帮助发现静态代码分析过程中无法发现的一些问题,例如代码的编写是否符合编码规范,代码在逻辑上或者功能上是 否存在错误,代码在执行效率和性能上是否有需要改进的地方,代码的注释是否完整正确,代码是否存在冗余和重复。代码评审还可以帮助新进入项目组的成员快速 学习和了解项目,促进经验分享,同时也能保证项目成员的良好沟通。代码评审主要包括两种形式,同级评审(Peer Review)和小组评审(Group Review)。同级评审主要指项目成员间的互相评审,小组评审是指通过召开评审会议,项目成员一起对项目代码进行评审。

为了提高代码评审的有效性和效率,可以借助一些外部工具,比较常用的代码评审工具有 Jupiter 和 Code Striker。Jupiter 是一款开源的 Eclipse 插件,允许成员将评审意见定位到真实代码的具体行,由于代码评审的结果以 XML 文件的形式保存,所以可以把结果提交到版本管理服务器进行共享。图 18 显示了使用 Jupiter 进行代码评审的界面。


图 18. Jupiter 代码评审界面
图 18. Jupiter 代码评审界面

在代码评审任务创建后,Jupiter 将代码评审分成三个阶段,个人评审阶段 (Individual Phase)、团队评审阶段(Team Phase)和问题修复阶段(Rework Phase)。在个人评审阶段,评审成员将发现的代码问题或者缺陷记录下来,每个问题都会作为一个记录保存在评审表格中。在团队评审阶段,团队的全部或者 部分成员会一起对个人评审阶段发现的问题进行定性,如果问题确实存在,就将该问题分配给某个成员去解决,并在 Jupiter 中将该问题设置成相应的状态。在问题修复阶段,团队成员会修复属于自己的问题,并将相应的记录设置成已解决等正确的状态。

Codestriker 是一款基于 Web 的常用代码评审工具,对代码的评审可以针对某一具体行,也可以针对整个代码文件,评审意见会被保存在数据库中。评审人员可以同时看到其他人的评论,代码作 者也可以针对某一具体的评论回复。Codestriker 支持邮件通知,还可以同版本控制服务器进行集成,以跟踪和显示文件内容的改变。图 19 显示了 Codestriker 的界面。


图 19. Codestriker 报告界面
图 19. Codestriker 报告界面

在实践中对所有代码进行小组评审会比较费时,所以可以根据实际情况来挑选一些核心代码进行小组评审,或者在项目的前期安排较多的小组评审,等 项目组的成员对代码评审的标准和要求有较好的理解,进行代码评审的经验提高后,就可以逐渐减少小组评审的次数,从而达到大部分代码即使只进行同级评审也能 保证很好的质量。

通过代码评审发现的问题要通过代码重构及时解决掉,较小的不涉及多人代码的重构可以由项目成员自己借助 Eclipse 的重构功能完成,不同项目成员写的实现相同功能的不同代码要通过讨论整合成公共的类或者方法。比较复杂的或者比较高层次的重构工作,例如整个项目层面的代 码组织形式的改变需要由整个项目组共同讨论完成。

结论

软件开发没有一成不变、万能通用的流程和方法,希望大家能从本文得到启发和收益,结合您的实际项目特点,实践以上步骤和方法,并加以完善和改 进,共同打造高效高质量的 Java 代码,为您的项目成功奠定坚实的基础。

没有更多推荐了,返回首页