程式碼擁有權

我遇到的程式碼擁有權方案有很多種。我將它們分成三大類別

• 強程式碼擁有權將程式碼庫拆分成模組（類別、函式、檔案），並將每個模組指定給一位開發人員。開發人員只能變更他們擁有模組的程式碼。如果他們需要變更其他人模組的程式碼，他們需要與模組擁有者討論，並請他們變更。你可以透過為其他模組撰寫程式碼補丁，並將其傳送給模組擁有者，來加速此流程。
• 弱程式碼擁有權與強程式碼擁有權類似，在於模組會指定給擁有者，但不同之處在於開發人員可以變更其他人擁有的模組。模組擁有者預期要負責他們擁有的模組，並注意其他人所做的變更。如果你想要對其他人的模組進行重大變更，禮貌的做法是先與模組擁有者討論。
• 共同程式碼擁有權放棄了模組個人擁有權的概念。程式碼庫由整個團隊擁有，任何人都可以在任何地方進行變更。你可以將其視為沒有程式碼擁有權，但其倡導者比較強調團隊擁有權的概念，而不是個人擁有權。（共同程式碼擁有權一詞來自於極限程式設計，儘管在第二版中，此做法稱為共用程式碼。）

這三種方案中，我真正不喜歡的是強程式碼擁有權。有太多情況是你需要做的事情需要變更其他人的程式碼。說服他們進行變更並等待變更通常需要很長的時間，這會導致延誤和更嚴重的問題，當變更很簡單時，這尤其令人惱火。

導致問題的簡單變更的一個好例子是重新命名公開方法。現代重構工具可以安全地對廣泛使用的公開方法進行重構。但如果你跨越模組邊界，這會違反程式碼擁有權。基本上，你已將所有開發人員之間的介面轉換成PublishedInterface，並伴隨著所有變更的相關開銷。

更糟的是，當你想要進行實作變更時，但因為你無法快速取得，所以你將外部程式碼複製到你的模組中，呼叫你的程式碼副本並進行變更。當然，你打算稍後整理這個混亂的狀況。

薄弱的程式碼擁有權是一種減輕此類問題的絕佳方式。人們可以自由地進行變更，程式碼擁有者只需留意狀況即可。

在薄弱和集體擁有權之間的選擇，與團隊的社會動態關係更大。兩者似乎都能運作，也能失敗，表現一樣好。就我個人而言，我比較喜歡集體程式碼擁有權團隊的動態，特別是在極限編程的背景下。