持续集成避免了这种尴尬处境，由于间隔的时间很短，集成中出现的问题可以很轻易的发现。即便无法定位错误，最差的情况也可以不把代码集成到软件中。这样，软件的质量就会比较高。此外，持续集成的另一个重要任务是运行自动化测试，保证所有的代码都是经过测试的，没有发生问题的。这里的测试源自于单元测试，在本文的测试一章，可以找到更为详细的讨论。
对一些没有持续集成经验的团队来说，持续集成像是一块吊的很高的饼，看得见却摸不着。要做好持续继承并不容易，但我们可以使用持续集成的思路，来接近持续集成的目标。
持续集成最好的做法是自动化的构建和测试。这要求软件组织拥有很好的配置管理机制，以及丰富的测试脚本编写经验。对于一个企业应用软件来说（抱歉，我只有这方面的经验），软件设计包括很多的因素，要把这些因素都考虑到持续集成的过程中并不是一件容易的事情。因此很多组织都可能缺少这两个因素，但没有关系，我们可以利用半手工的方式来完成持续集成，然后再慢慢的将持续集成的过程自动化。这里提供一个半自动持续集成的思路和改进过程。
首先是定义职责。如果你采用了代码非集体所有权的形式，那么，请明确的指定各个类或包（对于面向过程语言来说是函数和模块）的负责团队（或个人）。同样，你还需要指定数据库模式的负责人。这些代码之间可能会有交叉的地方，但没有关系，只要保证沟通，少量的交叉职责没什么特别的。最好还必须指定一个专门负责持续集成的人，可以让项目中的不同人交替担任该职责。
其次是定义自动化代码。所有的测试都必须写成测试代码的形式，并能够运行。所有的数据库模式定义也必须编写为DDL的形式，而不是使用数据库工具。千万别偷这个懒。总的原则是，能够写成代码的都写成代码，只有代码才是可以执行的。我承认，工作量是很大的，但这是必须的。
再次是定义集成的频度。频度的制定取决于团队的规模和沟通质量。对于小的团队而言，一小时一次的集成也是可行的。对于大的项目，可以划分子团队，子团队中采用频繁集成（一小时一次），子团队之间采用日集成（每天集成一次）。有了子团队的集成保证，整个团队的集成一般不会有什么问题。
接下来是使用工具。最需要的是版本控制工具，可以选用正式的，例如ClearCase。也可以选用简单的，例如SourceSafe，还可以选用免费的（CVS）。都没有关系，关键在于是否合用。代码和文档的集成都通过这个工具，数据库的集成则通过数据库管理员（就是第一步指定的负责数据库模式的人）。而集成负责人负责协调集成过程，保证集成的成功。
最后是发现问题，这只是一个开始，你在集成的过程一定会遇到各种各样的问题的。例如集成的时间，数据的相关性，设计的耦合度，测试代码的变化等。没有关系，这里存在一个自适应的过程。一开始的持续集成过程一定是错误百出的，慢慢的就会稳定下来，这时候就是改进的时候了，改进的主要目标始终都是过程自动化。有时候，为了保证集成的质量，我们要求出现错误的人请吃冰淇淋，不要笑，这也是过程的一部分，实践证明，这可是非常有效的，所有人在提交代码之前都会很认真的保证测试成功。
代码标准
代码标准是非常基础的管理常识。但是我们这里并不打算再赘述代码标准的问题。我们将重点讨论开发标准。开发标准包括各种各样的标准。例如过程的标志、文档的标准、设计模型的标准、代码风格的标准、变量命名的标准、大小写标准等等。在XP中，其实并不非常强调标准，因为XP提倡简单的做法，但有时候标准往往是违背这一准则的，因为它会带来额外的标准化成本。而重量级方法之所以笨重，过分遵循标准正是一大原因。
但在实际的过程中，我认为宁可多投入一些资源在标准制定的执行上。这和国内目前的软件开发实际情况有关系。国外的轻量级方法出现在重量级方法之后，大部分的程序员都经历过强制性的标准化过程。但是国内不同，虽然轻量级方法很好，但是理解或执行不当的话，却常常导致画虎不成反类犬的后果。国内很多软件组织的开发过程仍然处于无序的状态，而开发人员也鲜有标准过程的经验，在这样一种情况下，盲目的推崇敏捷的做法，其实骨子里仍然是一种混沌的状态。
因此，标准的制定和执行总是值得的，虽然会需要一定的成本，但这个成本同它的带来的改善沟通、促进积累等效益比起来不算什么。
但是标准的制定绝对不是要把程序员上洗手间的时间都规范起来，如何保持标准的平衡是敏捷方法的重点。XP认为代码规范就已经足够了。但我认为至少还有几种标准是需要重视的：
文档标准：这是一个大的话题，最好的文档标准是UML。一幅图胜过千言万语。当UML2.0出世之后，UML将会越来越强大。因此，使用UML来代替部分的文档是必要的。UML的相关资料有很多，这里不做过多的讨论，但关于UML的一句忠告是，不要试图在一开始就利用UML的所有类型的图，也不要一开始就利用UML所有特性。这种做法，和摆弄文字处理器的特性，与不写文档的做法没啥区别。
设计标准：同样是一个大的话题。设计标准包括如何进行设计，如何表示设计，如何设计架构，如何设计各个层次等等问题。在一个组织中贯彻设计标准是一个长期的过程。但仍然是那句话，做总是比不做的好。
代码风格标准：XP非常看中代码的可读性，代码可读性好代表了程序员的水平，设计人员的努力。提高代码可读性的非常好的实践是重构和复审，这两项实践在本文的其它位置都有详细的讨论。
界面标准：界面标准有时候只是一个很小的问题，但对于现代的软件来说，界面正扮演越来越重要的角色。而在软工领域，优秀界面的关键是一致性。同样的按钮必须有同样的大小、位置和字体。制定一份界面标准是非常关键的。
如何制定标准：标准的制定其实并不需要大量的说明文档，这些文档晦涩难懂，也不会有多少人会看，就算看了也未必会懂。只能是浪费时间。最好的方式是示例和培训。文档标准的说明就编写一份文档范例，并加以简短的说明。再辅以面对面的讲解，其效果要远远超过说明文档。
参考资料
Martin Fowler and K. Scott, UML Distilled: A Brief Guide to the Standard Object Modeling Language, Addison-Wesley, 1997. 中文版：《UML精粹--标准对象建模语言简明指南》，徐家福译，清华大学出版社，2002 年6 月。
Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999.
Joshua, Kerievsky Refactoring To Patterns, 2002.
Gamma, E. Helm, R. Johnson and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. 中文版：《设计模式：可复用面向对象软件的基础》，李英军等译，机械工业出版社，2000 年9 月。
Deepak Alur, John Crupi, Dan Malks, Core J2EE Patterns: Best Practices and Design Strategies, Prentice Hall PTR, 2001. 中文版：《J2EE核心模式》 牛志奇等译，机械工业出版社，2002年。
Stephen R.Palmer,John M.Felsing, A Practical Guide to Feature-Driven Development, Prentice Hall PTR, 2001. 中文版：《特征驱动开发方法原理与实践》 Stephen R.Palmer, John M.Felsing 熊焕宇译，机械工业出版社 2003年4月。
Ken Auer,Roy Miller, Extreme Programming Applied:Playing to Win, Addison-Wesley, 2001. 中文版：《应用极限编程--积极求胜》， 唐东铭译，人民邮电出版社，2003年4月。
William C. Wake, Extreme Programming Explored, Pearson Education, 2001. 中文版：《探索极限编程》， 郑荣林译，人民邮电出版社，2002年6月。
Kent Beck,Martin Fowler, Planning Extreme Programming, Pearson Education, 2001. 中文版：《规划极限编程》， 曹济译，人民邮电出版社，2002年6月。
Giancarlo Succi, Michele Marchesi, Extreme Programming Examined, Pearson Education, 2001. 中文版：《极限编程研究》， 张辉译，人民邮电出版社，2002年6月。
Kent Beck, Extreme Programming Explained:embrace change, 2001. 中文版：《解析极限编程-拥抱变化》， 唐东铭，人民邮电出版社，2002年6月。
Ron Jeffries,Ann Anderson,Chet Hendrickson, Extreme Programming Installed, Pearson Education, 2001. 中文版：《极限编程实施》， 袁国忠译，人民邮电出版社，2002年6月。
