持续整合：大量减少在整合中耗费的时间，减少团队开发问题。
用一个实例来讲述这一章吧，2002年的时候，我们的团队开始使用新的技术，并在我们自己设计的软件开发框架下工作，这套框架在设计上充分贯彻了J2EE的开发模式和MVC的设计模式。
MVC是Model、View、Control的缩写，我们做的业务类就是Model，JSP是View，而连接它们的就是各种事件响应的Servlet就是Control。
n Model: 应用的数据和业务逻辑处理。knows nothing about view and controller
n View: 从 model 取得数据,但不能设置 model 数据,决定 model 的数据表现， model 的改变，view 也相应改变。knows nothing about controller
n Controller: 接受输入，创建和设置 model，控制功能实现的流程。
当时因为大家都是刚刚开始从C/S模式转为B/S开发，使用新技术，为了能够在最短的时间内使每个开发人员成为“高手”，我们牺牲了全面发展的机会，采用术业有专攻的策略，决定按照技术将开发人员分层编码，主要分为Java、JavaScript和JSP。工作方式如下：
1、 采用组件式开发，将功能点划分成组件，一个或者多个组件实现一个功能。
2、 根据界面功能设计，利用组件配置工具参照模板或者自定义创建组件定义。
3、 根据界面功能设计以及组件定义文件，Java开发人员实现业务对象类、业务对象实现类、事件类；JavaScript开发人员实现Js文件；JSP开发人员实现JSP文件。
4、 由JavaScript开发人员联调。
5、 通过测试代码，保证每个组件能够在框架上独立运行，展现效果，以便用户及时看到效果，进行评估。
界面功能设计 Java开发人员 JavaScipt开发人员 JSP开发人员 组件配置工具 Java类 JSP文件
在这种模式下，整个软件系统就如同搭积木一般能够快速的展现给用户一个个的功能，并能够通过组件配置相对灵活的改变组件间的配合效果。经过一段时间的适应，所有的开发人员都能够感受到这种模式的快速开发效果，然而同时也发现了问题：通常编码时间仅占整个开发周期的30%左右，而我们调试的时候通常是编码时间的3到4倍！这样的话，不但造成了进度的不可控（因为你根本不知道什么时候能够调试好！），而且极大的浪费了人力（因为分层开发导致沟通成本增加，往往一个很小的问题要花费很长时间，甚至牵涉很多人）。
针对这个问题，我们进行了改进，解决的方式其实很简单：在界面、功能设计的时候加强接口设计，编码的时候严格遵照设计，提交联调前做好单元测试工作。
因为JSP和Js的修改都能够实现即改即生效，而且大多与业务无关，而Java的每次修改需要重起服务，所以我们这里所说的单元测试主要指Java部分。单元测试首先要求设计的比较合理，比如对于业务的处理集中到业务处理类、将处理与展现分离，做好封装等等。然后保留好测试代码，并将测试的输入、输出结果与代码一起提交测试，这样的话对于调试的人员来说增强了代码的可信度，而且一旦出了问题也便于更快的定位问题。我们的日常工作中，因为Java端的输入输出错误（这些错误中包括与设计不符）造成调试时间的严重浪费，而且也一定程度上浪费了其他开发人员的精力！
经过以上的之后，我们就采用了如下的改进：
l 每个组件的详细设计按照场景、结果方式编写，严格定义接口。
l Java端开发人员按照设计首先用数据类实现接口，并通过单元调试的方法将接口的输入、输出产生为XML文件。
l 以XML文件为接口标准，Java、JavaScript、Jsp三部分人员进行编码实现。
l 每日构造，要求每天下班前各个组件进行联调，问题定位，确定负责人。同时采用自动化处理每晚自动编译整个系统交给用户（当时用户和我们一起开发，主要负责用户测试和需求确认）
经过这样不断的改进，在当时还不知道敏捷开发理论的情况下，我们的做法居然无意中与敏捷开发的理念有了几分相符之处。所以，当我开始接触到敏捷开发、极限编程理论之后，深深地感觉到这些理论其实并不是什么新奇的东西，只是我们的很多实践没有形成理论和体系。同样，敏捷开发、极限编程也不应该是和传统的软件工程格格不入、相互矛盾的。在具体的应用中，我们完全可以在日常的开发实践中灵活运用，不断改善我们的工作，适用才是最好的！