代码集体所有权 XP提倡代码归属集体所有，这样做的理由是每个人都可以修改代码，而不是等待别人来修改代码。这种做法可以有效避免形成代码之间的鸿沟。但集体代码所有权也它的问题。
我们尝试了由多人共享代码的做法，其目的是为了加强交流，避免出现一段代码只有一个人了解的情况。这种方法一开始工作的很好，但很快我们发现出现了很多的问题，类的定义变得不清晰了，某些类变得臃肿，我们闻到了"Large Class"的味道。更为糟糕的是，这些类的清理和重构相当的困难，因为这些类的客户太多了。正是因为这些类被广泛的使用，因此大家都对其进行修改和扩充，导致了代码的混乱。于是，我们加大了重构的力度，对这些类不断的进行审查和重构，但是新的问题又出现了，很难找到一个平衡点，既能够保持团队的敏捷性，又保证类的高度可用性。更糟糕的是，不同的人对这些类有着不同的了解和期望，导致了这些类的设计风格有些怪异。
在本文中，我们不只一次的强调过，XP中所有的实践是配合使用的。项目中采用集体代码所有权不是不行，但有前提。在上面的例子中，我们至少犯了几个错误：
没有考虑到团队成员之间配合的默契程度。只有团队成员之间知识程度相近，或是具有相近的思维观，例如都熟悉面向对象，都熟悉设计模式。这样他们才能够共同保证代码的质量。在项目中，我们尝试了一种新的做法，将集体所有权的范围缩小到组，这个组由三到四个资深的开发人员组成，称为核心组，负责构建基础的框架。这个组之间采用高效的共享代码机制。其他的开发人员利用核心组的成果进行工作，他们并不修改核心代码，但可以提供修改意见。
忽视了代码质量。不同人修改代码要比单人修改代码更容易导致代码质量的下降。必须考虑这个成本，并找出恢复代码质量的办法。审查是非常有效的手段，FDD（Feature Driven Development 特征驱动开发）方法就非常强调审查在项目中的作用。只要成本能够接受，再多的审查都是不过分的。
代码标准化。这里说的代码标准化不仅仅指代码规范。还包括代码是不是具有可读性，代码的结构是否足够的清晰。这些都可能导致团队集体拥有代码时形成混乱。
此外，还应该注意到集体代码要求能够频繁的集成代码。代码必须要快速的同步和集成，共享代码往往意味着同一个包，同一个类都有可能被同时修改。这样大大增加了引入bug的可能。尽快的同步代码时非常有必要的。
如果一个软件组织不能够解决这些问题，冒然采用集体代码所有权的实践是比较危险的。相反，可以考虑采用个人代码所有权，或是微团队代码所有权。前者说的是个人对个人的代码负责，后者说的是两到四个人对某部分代码负责。
不论是个人代码所有权还是微团队代码所有权，其立足的根本是有明确的开发人员对代码负责，他保证代码的统一设计思路和风格，负责代码的客户端接口，负责维护和改进代码，负责代码的相关文档，负责解释代码的运行机理。个人代码所有权是最清晰的做法，但其坏处和集体所有权正好相反。某个人的代码可能造成进度的瓶颈，任何一个人离开团队都会造成损失。
个人代码所有权很容易理解，但微团队代码所有权就需要特别做解释了。他的组织思路非常类似于我们在结对编程中提倡的组织风格：
不同的人负责不同的代码，人员之间形成交叉。这样的组织比较灵活，和结对编程有着异曲同工之妙。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
