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

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

如图 所示，敏捷开发过程经历需求调研，用例分析和用例分解，进入开发迭代阶段。
在每一个迭代过程当中，能够采用如下五个步骤来保证和提升整个项目的代码质量：
统一 编码规范、代码样式；
静态代码分析（static code review）；
单元测试；
持续集成；
代码评审和重构（Review & Refactor）。

下文将针对每一个步骤和其所使用的工具、方法进行详细描述。

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

规范统一的编码会增长项目代码的可读性和可维护性，但实际状况每每是项目组内的 Java 代码开发人员的编码风格经常各不相同，这多是因为不一样的经验习惯或者缺少编码规范方面的学习形成的。这样一来，其余项目成员或者维护人员在阅读项目代码 时就须要花费更多的时间来理解代码做者的意图，因此制定并采起统一的编码规范就显得很重要。编码规范主要应包含如下几个方面：

通常规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。
命名规则。例如包名、类名、变量、方法、接口、参数等命名规范
文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。
编程规范。例如异常、并发、多线程等方面的处理方式。
其余规范。例如日志格式、属性文件格式，返回值和消息格式。
项目的编码规范能够参考已有的一些 Java 编程规范书籍和其余相关资料并结合项目的自己来制定，可供参考的书籍有《 Java 编程风格》（英文书名为：The Elements of Java Style）。编码规范要造成文档，并且要简洁明了，并组织项目成员一块儿学习，确保全部成员正确理解全部条目。

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

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

单击 OK 后就能够在新打开的窗口中进行修改定制本身须要的格式。如图 4 所示。

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

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

步骤二：静态代码分析

在完成源代码的开发之后，下面要进行的工做就是审视和测试代码。除了经过运行测试代码来检查功能以外，还能利用一些静态分析工具来快速、直接 地提升代码质量。
静态代码分析工具并不须要运行代码，能够直接对 Java 文件和 Class 文件进行分析，经过一些检查条件的设置，快速找到代码中的错误和潜在缺陷。
如今的静态分析工具不少，有 FindBugs、PMD、IBM Rational Tool，等等。
在这里介绍PMD，具体看以前写的文章；

步骤三：单元测试

单元测试用例设计和评审

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

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

模拟对象技术

在实际项目中，开发人员本身的代码每每须要和其余的代码模块或系统进行交互，但在测试的过程当中，这些须要被调用的真实对象经常很难被实例化， 或者这些对象在某些状况下没法被用来测试，例如，真实对象的行为没法预测，真实对象的行为难以触发，或者真实对象的运行速度很慢。这时候，就须要使用模拟 对象技术（Mock），利用一个模拟对象来模拟咱们的代码所依赖的真实对象，来帮助完成测试，提升测试覆盖率，从而提升代码质量。模拟对象技术利用了在面 向接口的编程中，因为代码直接对接口进行调用，因此代码并不知道引用的是真实对象仍是模拟对象，这样就能够顺利的完成对代码的测试。

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

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

测试覆盖率分析

为了衡量单元测试的质量和覆盖的范围，须要对单元测试的代码进行测试覆盖分析。经常使用的衡量测试覆盖率的指标主要有语句覆盖率、分支覆盖率、路 径覆盖率、条件覆盖率和方法覆盖率等。具体采用哪些指标能够根据项目的实际状况来定，以免因太高的指标增长了代码开发人员的工做量而影响了项目总体的进 度。

EMMA 是一款比较流行的开源 Java 测试覆盖率分析工具，支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析，支持将覆盖率分析结果导出为多种格式的报告，并采用多种颜色来高亮显 示不一样的覆盖率状态。EclEmma 是一款基于 EMMA 的 Eclipse 插件，方便在 Eclipse IDE 中进行测试覆盖率分析。

为了保证单元测试的有效性和质量，能够规定一个测试覆盖率的下限，例如全部的包和类的覆盖率必须达到 80% 以上。不过值得注意的是，不要单纯追求高覆盖率，要同时注意测试用例的质量，若是测试用例自己就写的有错误，那么即便测试覆盖率很高也没有意义。

步骤四：持续集成

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

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

自动构建

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

步骤五：代码评审和重构

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

为了提升代码评审的有效性和效率，能够借助一些外部工具，比较经常使用的代码评审工具备 Jupiter 和 Code Striker。Jupiter 是一款开源的 Eclipse 插件，容许成员将评审意见定位到真实代码的具体行，因为代码评审的结果以 XML 文件的形式保存，因此能够把结果提交到版本管理服务器进行共享。

在代码评审任务建立后，Jupiter 将代码评审分红三个阶段，我的评审阶段 (Individual Phase)、团队评审阶段（Team Phase）和问题修复阶段（Rework Phase）。在我的评审阶段，评审成员将发现的代码问题或者缺陷记录下来，每一个问题都会做为一个记录保存在评审表格中。在团队评审阶段，团队的所有或者 部分红员会一块儿对我的评审阶段发现的问题进行定性，若是问题确实存在，就将该问题分配给某个成员去解决，并在 Jupiter 中将该问题设置成相应的状态。在问题修复阶段，团队成员会修复属于本身的问题，并将相应的记录设置成已解决等正确的状态。

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

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

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

结论

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