代碼集體所有權 XP提倡代碼歸屬集體所有，這樣做的理由是每個人都可以修改代碼，而不是等待別人來修改代碼。這種做法可以有效避免形成代碼之間的鴻溝。但集體代碼所有權也它的問題。
我們嘗試了由多人共享代碼的做法，其目的是為了加強交流，避免出現一段代碼只有一個人了解的情況。這種方法一開始工作的很好，但很快我們發現出現了很多的問題，類的定義變得不清晰了，某些類變得臃腫，我們聞到了"Large Class"的味道。更為糟糕的是，這些類的清理和重構相當的困難，因為這些類的客戶太多了。正是因為這些類被廣泛的使用，因此大家都對其進行修改和擴充，導致了代碼的混亂。于是，我們加大了重構的力度，對這些類不斷的進行審查和重構，但是新的問題又出現了，很難找到一個平衡點，既能夠保持團隊的敏捷性，又保證類的高度可用性。更糟糕的是，不同的人對這些類有著不同的了解和期望，導致了這些類的設計風格有些怪異。
在本文中，我們不只一次的強調過，XP中所有的實踐是配合使用的。項目中采用集體代碼所有權不是不行，但有前提。在上面的例子中，我們至少犯了幾個錯誤：
沒有考慮到團隊成員之間配合的默契程度。只有團隊成員之間知識程度相近，或是具有相近的思維觀，例如都熟悉面向對象，都熟悉設計模式。這樣他們才能夠共同保證代碼的質量。在項目中，我們嘗試了一種新的做法，將集體所有權的范圍縮小到組，這個組由三到四個資深的開發人員組成，稱為核心組，負責構建基礎的框架。這個組之間采用高效的共享代碼機制。其他的開發人員利用核心組的成果進行工作，他們并不修改核心代碼，但可以提供修改意見。
忽視了代碼質量。不同人修改代碼要比單人修改代碼更容易導致代碼質量的下降。必須考慮這個成本，并找出恢復代碼質量的辦法。審查是非常有效的手段，FDD（Feature Driven Development 特征驅動開發）方法就非常強調審查在項目中的作用。只要成本能夠接受，再多的審查都是不過分的。
代碼標準化。這里說的代碼標準化不僅僅指代碼規范。還包括代碼是不是具有可讀性，代碼的結構是否足夠的清晰。這些都可能導致團隊集體擁有代碼時形成混亂。
此外，還應該注意到集體代碼要求能夠頻繁的集成代碼。代碼必須要快速的同步和集成，共享代碼往往意味著同一個包，同一個類都有可能被同時修改。這樣大大增加了引入bug的可能。盡快的同步代碼時非常有必要的。
如果一個軟件組織不能夠解決這些問題，冒然采用集體代碼所有權的實踐是比較危險的。相反，可以考慮采用個人代碼所有權，或是微團隊代碼所有權。前者說的是個人對個人的代碼負責，后者說的是兩到四個人對某部分代碼負責。
不論是個人代碼所有權還是微團隊代碼所有權，其立足的根本是有明確的開發人員對代碼負責，他保證代碼的統一設計思路和風格，負責代碼的客戶端接口，負責維護和改進代碼，負責代碼的相關文檔，負責解釋代碼的運行機理。個人代碼所有權是最清晰的做法，但其壞處和集體所有權正好相反。某個人的代碼可能造成進度的瓶頸，任何一個人離開團隊都會造成損失。
個人代碼所有權很容易理解，但微團隊代碼所有權就需要特別做解釋了。他的組織思路非常類似于我們在結對編程中提倡的組織風格：
不同的人負責不同的代碼，人員之間形成交叉。這樣的組織比較靈活，和結對編程有著異曲同工之妙。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
