商业网站如何备案,一个网站如何做推广方案设计,项目经理查询系统,遵义广告公司网站建设本文转自#xff1a;http://dev.yesky.com/103/11164603.shtml 敏捷开发的理念已经流行了很长的时间#xff0c;在敏捷开发中的开发迭代阶段中#xff0c;我们可以通过五个步骤#xff0c;来有效的提高整个项目的代码质量。 Java项目开发过程中#xff0c;由于开发人员的…本文转自http://dev.yesky.com/103/11164603.shtml 敏捷开发的理念已经流行了很长的时间在敏捷开发中的开发迭代阶段中我们可以通过五个步骤来有效的提高整个项目的代码质量。 Java项目开发过程中由于开发人员的经验、Java代码编写习惯以及缺乏统一的标准和管理流程往往导致整个项目的代码质量较差难于维 护需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。 如图1所示敏捷开发过程经历需求调研用例分析和用例分解进入开发迭代阶段。在每个迭代过程中可以采用以下步骤来保证和提高整个项目的代 码质量统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构 (ReviewRefactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。 图1.敏捷开发中的Java代码质量保证步骤 步骤一统一编码规范、代码样式 规范统一的编码会增加项目代码的可读性和可维护性但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同这可能是由于不同 的经验习惯或者缺乏编码规范方面的学习造成的。这样一来其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图所以制定 并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面 ◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。 ◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范 ◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。 ◆编程规范。例如异常、并发、多线程等方面的处理方式。 ◆其他规范。例如日志格式、属性文件格式返回值和消息格式。 项目的编码规范可以参考已有的一些Java编程规范书籍和其他相关资料并结合项目的本身来制定可供参考的书籍有《Java编程风格》(英文书 名为TheElementsofJavaStyle)。编码规范要形成文档而且要简洁明了并组织项目成员一起学习确保所有成员正确理解所有条目。 一旦编码规范确定就可以利用Eclipse自身提供的功能来控制代码样式和格式。具体做法是点击Eclipse的 Windows-Preference菜单项在打开的Preferences对话框的左侧栏中找到Java节点下的子项CodeStyle(如图2)该项 和它的子项允许您对Java代码的样式进行控制。 图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检查代码。 图5.FindBugs的配置选项 设置好自己的规则后在需要检查的代码文件夹上点击右键就可以启动FindBugs检查。代码可以是一个项目也可以只是几个文件。 图6.运行FindBugs 检查完毕后会出现FindBugs视图把所有检查的结果根据错误分组展示。点击结果里面的每一个错误会自动打开对应的代码。当根据规则改 正了所有的错误或者说潜在错误这些代码也就通过了静态代码检查。FindBugs的检查结果可以是XML文件也可以是文本文件便于项目的集成管理 和检查保存。 图7.FindBugs检查结果 步骤三单元测试 单元测试用例设计和评审 单元测试是软件开发过程中重要的质量保证环节在此环节中设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要具 体考虑要对哪些代码单元进行测试被测单元之间的关系测试策略以及单元测试用例设计等并最终输出《单元测试用例设计》文档用来指导具体的单元测试 执行。在用例设计中通过对代码单元输入和期待输出的定义来保证该单元的功能正确性边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹配 方法来衡量用例设计的完整性。 在用例设计完成之后下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的用例评审可以借集体之力对用例设计进入查漏补缺 进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴它主要通过对代码的逻辑结构进行分析来设计测试用例因此评审员的选择最好以理解代码逻辑 结构为前提如果评审员来自相关模块还能够有效的发现模块相关性和依赖性所带来的问题。 模拟对象技术 在实际项目中开发人员自己的代码往往需要和其他的代码模块或系统进行交互但在测试的过程中这些需要被调用的真实对象常常很难被实例化或 者这些对象在某些情况下无法被用来测试例如真实对象的行为无法预测真实对象的行为难以触发或者真实对象的运行速度很慢。这时候就需要使用模拟对 象技术(Mock)利用一个模拟对象来模拟我们的代码所依赖的真实对象来帮助完成测试提高测试覆盖率从而提高代码质量。模拟对象技术利用了在面向 接口的编程中由于代码直接对接口进行调用所以代码并不知道引用的是真实对象还是模拟对象这样就可以顺利的完成对代码的测试模拟技术有很多种如 jMockEasyMockMockitoPowerMock等等。其中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的脚本可以加上JUnitEMMAFindBugs的ANT脚本调用每一次的构建都可 以把这些检查工作自动的进行一遍测试。这些测试都要生成测试结果报告RTC不能提供这些报告的展示就可以利用Hudson这个开源工具集成测试报告 来方便查阅。 图17.自动测试报告 步骤五代码评审和重构 代码评审(CodeReview)是Java项目开发过程中的一个重要步骤代码评审可以帮助发现静态代码分析过程中无法发现的一些问题例如 代码的编写是否符合编码规范代码在逻辑上或者功能上是否存在错误代码在执行效率和性能上是否有需要改进的地方代码的注释是否完整正确代码是否存在 冗余和重复。代码评审还可以帮助新进入项目组的成员快速学习和了解项目促进经验分享同时也能保证项目成员的良好沟通。代码评审主要包括两种形式同级 评审(PeerReview)和小组评审(GroupReview)。同级评审主要指项目成员间的互相评审小组评审是指通过召开评审会议项目成员一起 对项目代码进行评审。 为了提高代码评审的有效性和效率可以借助一些外部工具比较常用的代码评审工具有Jupiter和CodeStriker。Jupiter是 一款开源的Eclipse插件允许成员将评审意见定位到真实代码的具体行由于代码评审的结果以XML文件的形式保存所以可以把结果提交到版本管理服务器进 行共享。图18显示了使用Jupiter进行代码评审的界面。 图18.Jupiter代码评审界面 在代码评审任务创建后Jupiter将代码评审分成三个阶段个人评审阶段(IndividualPhase)、团队评审阶段 (TeamPhase)和问题修复阶段(ReworkPhase)。在个人评审阶段评审成员将发现的代码问题或者缺陷记录下来每个问题都会作为一个记 录保存在评审表格中。在团队评审阶段团队的全部或者部分成员会一起对个人评审阶段发现的问题进行定性如果问题确实存在就将该问题分配给某个成员去解 决并在Jupiter中将该问题设置成相应的状态。在问题修复阶段团队成员会修复属于自己的问题并将相应的记录设置成已解决等正确的状态。 Codestriker是一款基于Web的常用代码评审工具对代码的评审可以针对某一具体行也可以针对整个代码文件评审意见会被保存在数据库中。评审人员可以同时看到其他人的评论代码作者也可以针对某一具体的评 论回复。Codestriker支持邮件通知还可以同版本控制服务器进行集成以跟踪和显示文件内容的改变。图19显示了Codestriker的界 面。 图19.Codestriker报告界面 在实践中对所有代码进行小组评审会比较费时所以可以根据实际情况来挑选一些核心代码进行小组评审或者在项目的前期安排较多的小组评审等项 目组的成员对代码评审的标准和要求有较好的理解进行代码评审的经验提高后就可以逐渐减少小组评审的次数从而达到大部分代码即使只进行同级评审也能保 证很好的质量。 通过代码评审发现的问题要通过代码重构及时解决掉较小的不涉及多人代码的重构可以由项目成员自己借助Eclipse的重构功能完成不同项目 成员写的实现相同功能的不同代码要通过讨论整合成公共的类或者方法。比较复杂的或者比较高层次的重构工作例如整个项目层面的代码组织形式的改变需要由整 个项目组共同讨论完成。 结论 软件开发没有一成不变、万能通用的流程和方法希望大家能从本文得到启发和收益结合您的实际项目特点实践以上步骤和方法并加以完善和改 进共同打造高效高质量的Java代码为您的项目成功奠定坚实的基础。
