敏捷开发中高质量 Java 代码开发实践
例如，为了使用自动格式化工具，可以在 Eclipse 提供的默认代码格式配置的基础上建立自定义的格式。在 Formatter 面板中，点击 New，输入新的名字并选择一个默认的配置作为初始化格式，如图 3 所示。
图 3. 创建新的代码格式配置
单击 OK 后就可以在新打开的窗口中进行修改定制自己需要的格式。如图 4 所示。
图 4. 创建新的代码格式配置
修改完成后点击 Apply 保存所作修改。同时可以点击 Export 将当前的格式定义导出成一个 XML 文件，这样项目组的其他成员就可以很方便通过点击图 3 中的 Import 按钮来导入该 XML 文件来使用同一个代码格式定义。
这样每次在提交代码到版本控制服务器前就可以通过 Eclipse 界面里的 Source->Format 菜单来对代码进行格式化，从而使整个项目的代码具有相同的格式。同样可以通过对 Code Style 下的其他项目进行设置来帮助对 Java 代码的样式进行控制。将所有这些样式文件导出成 XML 文件后，同编码规范一起归档，供所有项目成员使用。
设置好自己的规则后，在需要检查的代码文件夹上点击右键，就可以启动 FindBugs 检查。代码可以是一个项目，也可以只是几个文件。
图 6. 运行 FindBugs
检查完毕后，会出现 FindBugs 视图，把所有检查的结果根据错误分组展示。点击结果里面的每一个错误，会自动打开对应的代码。当根据规则改正了所有的错误，或者说潜在错误，这些代码也就通过了静态代码检查。FindBugs 的检查结果可以是 XML 文件，也可以是文本文件，便于项目的集成管理和检查保存。
图 7. FindBugs 检查结果
在模拟对象过程中，先模拟一个需要调用的 List 对象 LinkedList，再设定这个对象的行为，当调用 get(0) 的时候，返回”first”。这样，测试代码就可以利用这个对象来测试我们的功能代码，需要调用和返回值的时候，可以顺利的得到模拟对象的返回值。也需要对模拟对象进行错误情况的模拟，保证代码对错误的处理的正确性。
单元测试跑完后，Coverage视图中会显示所选择的测试的覆盖率。双击打开某一具体的类后，可以看到高亮显示的覆盖分析结果，如图 10 所示。红色代表测试没有覆盖到该行，黄色表示部分覆盖，绿色的行表示该行在本次测试中被覆盖到。
图 10. 查看测试覆盖分析结果
在 Coverage 视图中可以通过点击鼠标右键将测试覆盖分析的结果导出成需要的格式，例如 HTML。
图 11. 导出测试覆盖分析结果
图 12 显示了导出的 report。
图 12. 测试覆盖分析报告
为了保证单元测试的有效性和质量，可以规定一个测试覆盖率的下限，例如所有的包和类的覆盖率必须达到 80% 以上。不过值得注意的是，不要单纯追求高覆盖率，要同时注意测试用例的质量，如果测试用例本身就写的有错误，那么即使测试覆盖率很高也没有意义。
图 14. 构建申请界面
当构建结束后。RTC 服务器会提供构建结果报告。开发人员可以查询到这次构建的详细信息。
图 15. 构建结果
整个开发过程中，构建版本的过程应该是无数次的，通过每次构建，都可以得到当时代码的编译情况，并且可以得到一个可运行的软件版本。在构建定义上，RTC 支持设置构建计划。定时自动的触发一次构建。
图 16. 构建定义
在代码评审任务创建后，Jupiter 将代码评审分成三个阶段，个人评审阶段 (Individual Phase)、团队评审阶段（Team Phase）和问题修复阶段（Rework Phase）。在个人评审阶段，评审成员将发现的代码问题或者缺陷记录下来，每个问题都会作为一个记录保存在评审表格中。在团队评审阶段，团队的全部或者部分成员会一起对个人评审阶段发现的问题进行定性，如果问题确实存在，就将该问题分配给某个成员去解决，并在 Jupiter 中将该问题设置成相应的状态。在问题修复阶段，团队成员会修复属于自己的问题，并将相应的记录设置成已解决等正确的状态。
Codestriker 是一款基于 Web 的常用代码评审工具，对代码的评审可以针对某一具体行，也可以针对整个代码文件，评审意见会被保存在数据库中。评审人员可以同时看到其他人的评论，代码作者也可以针对某一具体的评论回复。Codestriker 支持邮件通知，还可以同版本控制服务器进行集成，以跟踪和显示文件内容的改变。图 19 显示了 Codestriker 的界面。
图 19. Codestriker 报告界面
在实践中对所有代码进行小组评审会比较费时，所以可以根据实际情况来挑选一些核心代码进行小组评审，或者在项目的前期安排较多的小组评审，等项目组的成员对代码评审的标准和要求有较好的理解，进行代码评审的经验提高后，就可以逐渐减少小组评审的次数，从而达到大部分代码即使只进行同级评审也能保证很好的质量。
通过代码评审发现的问题要通过代码重构及时解决掉，较小的不涉及多人代码的重构可以由项目成员自己借助 Eclipse 的重构功能完成，不同项目成员写的实现相同功能的不同代码要通过讨论整合成公共的类或者方法。比较复杂的或者比较高层次的重构工作，例如整个项目层面的代码组织形式的改变需要由整个项目组共同讨论完成。
回页首
结论
软件开发没有一成不变、万能通用的流程和方法，希望大家能从本文得到启发和收益，结合您的实际项目特点，实践以上步骤和方法，并加以完善和改进，共同打造高效高质量的 Java 代码，为您的项目成功奠定坚实的基础。
?
原文地址: http://www.ibm.com/developerworks/cn/java/j-lo-agile/
?
