代碼所有制（Code Ownership）

版權所有，歡迎轉載，但請注明作者，譯者和出處。如翻譯欠妥，歡迎不吝指正。

歡迎關注微網誌：風再起時我就走

英文原文連結：點選打開連結

在我的職業生涯中，碰到過各種各樣的代碼所有制模式。我把它們歸納為三大類：

1、         強代碼所有制：把程式分解組織為子產品（類，函數，檔案），然後為每一個子產品指定一個程式員。程式員隻能修改歸屬于自己的子產品代碼。如果他們需要修改其他子產品，則需要告知負責該子產品的程式員，然後讓這個程式員去做修改。如果你想加快這個過程，你可以直接對這個子產品寫完更新檔代碼，然後把它交給代碼所有者。

2、         弱代碼所有者：與強代碼所有制類似的是，它也把代碼子產品化之後分别指派給對應程式員，不同的是，它允許程式員直接對屬于其他程式員的代碼做出修改。所有者對自己的子產品代碼負責，并且需要時刻關注其他人在他所擁有的代碼做出的變更。如果你試圖對其他人的子產品代碼做出比較重大的修改，事先最好還是要與代碼所有者進行溝通。

3、         集體代碼所有制：它抛棄了個人擁有代碼的概念。在這種模式下，代碼為整個開發團隊所共同擁有，任何人可以對改動任何代碼。也可以了解為代碼無所有制。它強調的概念是代碼屬于整個團隊而非獨立的程式員個體。（代碼集體所有制的概念來自于XP極限程式設計，在XP第二版中，這被稱之為共享代碼）。

以上三種，我個人最不喜歡強代碼所有制。實際開發中，有太多的需要去改動其他人的代碼的情況。說服代碼所有者去修改代碼，然後再等待修改完成，需要太長時間，這通常會導緻項目延遲和其他更深層次的問題。當需要修改的内容很簡單的時候，這尤其令人郁悶。

僅僅是簡單修改但是卻不能順利快速完成的一個很好的例子是重命名一個公開的方法。現代的重構工具可以很好的完成這個，但是如果跨子產品修改，卻違背了這個代碼所有制的規定。

更糟的情況是，當你要進行改動的時候，因為你無法很快地修改，你直接複制了一份其他子產品的代碼到你們的子產品中，然後做出一些修改之後直接調用這部分代碼。很顯然，這是一個很糟糕的處理方式，将來，你必然需要對這個糟糕的代碼狀況做出處理。

弱代碼所有制是避免這些問題的一個很不錯的方式。大家都可以自由的修改代碼，而隻需要子產品所有者對這些改動保持關注并確定改動沒問題。

弱代碼所有制和集體代碼所有制之間如何選擇，這與團隊的成員工程密切相關，這兩個方式都可能成功，或者失敗，難以斷言孰優孰劣。就我個人而言，我更喜歡集體代碼所有制的創新的概念，尤其在極限程式設計的環境中。