步骤四：持续集成
持续集成（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进行代码评审的界面。
图18.Jupiter代码评审界面
在代码评审任务创建后，Jupiter将代码评审分成三个阶段，个人评审阶段（IndividualPhase）、团队评审阶段（TeamPhase）和问题修复阶段（ReworkPhase）。在个人评审阶段，评审成员将发现的代码问题或者缺陷记录下来，每个问题都会作为一个记录保存在评审表格中。在团队评审阶段，团队的全部或者部分成员会一起对个人评审阶段发现的问题进行定性，如果问题确实存在，就将该问题分配给某个成员去解决，并在Jupiter中将该问题设置成相应的状态。在问题修复阶段，团队成员会修复属于自己的问题，并将相应的记录设置成已解决等正确的状态。
Codestriker是一款基于Web的常用代码评审工具，对代码的评审可以针对某一具体行，也可以针对整个代码文件，评审意见会被保存在数据库中。评审人员可以同时看到其他人的评论，代码作者也可以针对某一具体的评论回复。Codestriker支持邮件通知，还可以同版本控制服务器进行集成，以跟踪和显示文件内容的改变。图19显示了Codestriker的界面。
图19.Codestriker报告界面
在实践中对所有代码进行小组评审会比较费时，所以可以根据实际情况来挑选一些核心代码进行小组评审，或者在项目的前期安排较多的小组评审，等项目组的成员对代码评审的标准和要求有较好的理解，进行代码评审的经验提高后，就可以逐渐减少小组评审的次数，从而达到大部分代码即使只进行同级评审也能保证很好的质量。
通过代码评审发现的问题要通过代码重构及时解决掉，较小的不涉及多人代码的重构可以由项目成员自己借助Eclipse的重构功能完成，不同项目成员写的实现相同功能的不同代码要通过讨论整合成公共的类或者方法。比较复杂的或者比较高层次的重构工作，例如整个项目层面的代码组织形式的改变需要由整个项目组共同讨论完成。
结论
软件开发没有一成不变、万能通用的流程和方法，希望大家能从本文得到启发和收益，结合您的实际项目特点，实践以上步骤和方法，并加以完善和改进，共同打造高效高质量的Java代码，为您的项目成功奠定坚实的基础。
相关链接：
在敏捷开发中编写高质量Java代码（1）
与那些新人和旧人们共同经历吧！
