【IT168 技术文章】
XP 还拥有其它优秀的实践，本文讨论了 XP 的另外三个实践，并研究如何在项目中灵活的使用它们。
代码集体所有权
XP提倡代码归属集体所有，这样做的理由是每个人都可以修改代码，而不是等待别人来修改代码。这种做法可以有效避免形成代码之间的鸿沟。但集体代码所有权也它的问题。
我们尝试了由多人共享代码的做法，其目的是为了加强交流，避免出现一段代码只有一个人了解的情况。这种方法一开始工作的很好，但很快我们发现出现了很多的问题，类的定义变得不清晰了，某些类变得臃肿，我们闻到了"Large Class"的味道。更为糟糕的是，这些类的清理和重构相当的困难，因为这些类的客户太多了。正是因为这些类被广泛的使用，因此大家都对其进行修改和扩充，导致了代码的混乱。于是，我们加大了重构的力度，对这些类不断的进行审查和重构，但是新的问题又出现了，很难找到一个平衡点，既能够保持团队的敏捷性，又保证类的高度可用性。更糟糕的是，不同的人对这些类有着不同的了解和期望，导致了这些类的设计风格有些怪异。
在本文中，我们不只一次的强调过，XP中所有的实践是配合使用的。项目中采用集体代码所有权不是不行，但有前提。在上面的例子中，我们至少犯了几个错误：
. 没有考虑到团队成员之间配合的默契程度。只有团队成员之间知识程度相近，或是具有相近的思维观，例如都熟悉面向对象，都熟悉设计模式。这样他们才能够共同保证代码的质量。在项目中，我们尝试了一种新的做法，将集体所有权的范围缩小到组，这个组由三到四个资深的开发人员组成，称为核心组，负责构建基础的框架。这个组之间采用高效的共享代码机制。其他的开发人员利用核心组的成果进行工作，他们并不修改核心代码，但可以提供修改意见。
. 忽视了代码质量。不同人修改代码要比单人修改代码更容易导致代码质量的下降。必须考虑这个成本，并找出恢复代码质量的办法。审查是非常有效的手段，FDD（Feature Driven Development 特征驱动开发）方法就非常强调审查在项目中的作用。只要成本能够接受，再多的审查都是不过分的。
. 代码标准化。这里说的代码标准化不仅仅指代码规范。还包括代码是不是具有可读性，代码的结构是否足够的清晰。这些都可能导致团队集体拥有代码时形成混乱。
此外，还应该注意到集体代码要求能够频繁的集成代码。代码必须要快速的同步和集成，共享代码往往意味着同一个包，同一个类都有可能被同时修改。这样大大增加了引入bug的可能。尽快的同步代码时非常有必要的。
如果一个软件组织不能够解决这些问题，冒然采用集体代码所有权的实践是比较危险的。相反，可以考虑采用个人代码所有权，或是微团队代码所有权。前者说的是个人对个人的代码负责，后者说的是两到四个人对某部分代码负责。
不论是个人代码所有权还是微团队代码所有权，其立足的根本是有明确的开发人员对代码负责，他保证代码的统一设计思路和风格，负责代码的客户端接口，负责维护和改进代码，负责代码的相关文档，负责解释代码的运行机理。个人代码所有权是最清晰的做法，但其坏处和集体所有权正好相反。某个人的代码可能造成进度的瓶颈，任何一个人离开团队都会造成损失。
个人代码所有权很容易理解，但微团队代码所有权就需要特别做解释了。他的组织思路非常类似于我们在结对编程中提倡的组织风格：
不同的人负责不同的代码，人员之间形成交叉。这样的组织比较灵活，和结对编程有着异曲同工之妙。
持续集成
在Martin Fowler的持续集成（在Agilechina网站上可以找到该文的中文译本）一文中，对持续继承有着这样的描述：
在软件开发的领域里有各种各样的"非常好的实践"，它们经常被人们谈起，但是似乎很少有真正得到实现的。这些实践最基本、最有价值的就是：都有一个完全自动化的创建、测试过程，让开发团队可以每天多次创建他们的软件。"日创建"也是人们经常讨论的一个观点，McConnell在他的《快速软件开发》中将日创建作为一个非常好的实践来推荐，同时日创建也是微软很出名的一项开发方法。但是，我们更支持XP社群的观点：日创建只是最低要求。一个完全自动化的过程让你可以每天完成多次创建，这是可以做到的，也是完全值得的。
和本文提到的其它实践一样，持续集成的主要思路是将软件过程末期的软件继承分摊到软件的全过程。虽然没有办法评判两种持续方式的成本，但是持续集成可以获得很多额外的好处。单次集成最要命的地方是除bug的过程，尤其是那些隐藏的很深，让人觉得无从下手的bug。如果说写代码是一种享受，那修复bug的过程绝对是一种煎熬。在这个过程中花费的时间有时候是惊人的，更糟糕的问题是，这部分的时间根本无法估计，这令项目管理者头疼不已。向编码者询问进度时得到的回复永远都是"还差一点儿"。
