代码所有权

我遇到过各种代码所有权方案。我将它们分为三大类

• 强代码所有权将代码库分解成模块（类、函数、文件），并将每个模块分配给一名开发人员。开发人员只能更改他们拥有的模块。如果他们需要更改其他人的模块，他们需要与模块所有者交谈并让他们进行更改。您可以通过为其他模块编写补丁并将其发送给模块所有者来加快此过程。
• 弱代码所有权与之类似，模块分配给所有者，但不同之处在于开发人员可以更改其他人拥有的模块。模块所有者应负责他们拥有的模块，并关注其他人所做的更改。如果您想对其他人的模块进行重大更改，最好先与模块所有者讨论。
• 集体代码所有权放弃了对模块的个人所有权的概念。代码库由整个团队拥有，任何人都可以在任何地方进行更改。您可以将其视为没有代码所有权，但其倡导者更强调团队而不是个人拥有代码的概念。（集体代码所有权一词来自 极限编程，尽管在第二版中，这种实践被称为共享代码。）

在这三种中，我最不喜欢的是强代码所有权。有太多情况需要更改其他人的代码才能完成某项工作。说服他们进行更改并等待更改通常需要很长时间，从而导致延迟和更深层次的问题，当更改很简单时，这尤其令人恼火。

一个简单的更改导致麻烦的一个很好的例子是重命名公共方法。现代重构工具可以安全地对广泛使用的公共方法进行此操作。但这违反了代码所有权，因为您跨越了模块边界。本质上，您将开发人员之间所有接口都变成了 PublishedInterface，并附带了所有更改的额外开销。

更糟糕的是，当您想要进行实现更改时，但由于无法快速获得更改，因此将外部代码复制到您的模块中，调用您的代码副本并进行更改。当然，您打算稍后解决这个混乱局面。

弱代码所有权是缓解此类问题的一种好方法。人们可以自由地进行更改，代码所有者只需关注事情。

弱所有权和集体所有权之间的选择更多地取决于团队的社会动态。两者似乎都同样有效，也同样会失败。就我个人而言，我更喜欢集体代码所有权团队的动态 - 特别是在极限编程的背景下。