代码所有权

原文： CodeOwnership        敏捷    2006年5月12日

关于代码所有权，我见过很多种配置方案，我把它们归并成以下三大类：

•      强代码所有权——把整个代码库划分成多个模块（class、函数、文件），给每个模块指定一名开发者，只允许开发者改动属于自己的模块，如果你需要修改一下别人的模块，你得先告诉那个模块的所有者，让他们去做相应的修改。你可以给那个模块写个修改补丁发给其所有者，这样能加速修改过程。

•     弱代码所有权——同样是给模块指定所有者，不同的是允许开发者改动其他人的模块。开发者不仅要负责编写分给他的那些模块，还得留只眼睛时刻瞄着别人对这些模块的修改。要是你想给别人的某个模块动一个大手术，礼貌的做法是事先与它的主人交流一下。

•     集体代码所有权——抛弃了模块个人所有制的全部观念，整个代码库由整个团队共有，任何人可以改动任何地方。你也可以把这叫做“无代码所有权”，但前种叫法的支持者更喜欢强调那种由团队所有而非某某个人所有的观念。（“集体代码所有权”这个术语源自极限编程，但在第二版里这种实践被改称为“共享代码”了。）

这三者之中，我最不喜欢的是强代码所有权。因为你需要修改一下别人代码的情况实在是太常见了，说服他们那么改，然后等着他们改完，这往往花费大量的时间，从而导致开发延期甚至更严重的问题——假若那只是个简单的小修改，这种后果就越发恼人了。

举一个简单修改就会导致问题的好例子：给一个public的方法改名。不管这个public方法被调用得多么广泛，现代化的重构工具都能安全地解决这个问题。但如果你的修改越出了属于你的模块的边界，那就违反了强代码所有权规则。重要的是你的这些不同开发者都会用到的接口已经成为了 发布接口，一旦改名，你得承担所有连带后果。

更麻烦的情况是，当你需要修改一个接口的实现，但你等不及它的主人改好了，你只能把这份外来代码拷贝到自己的模块里，亲自改好后为你所用。当然，你是计划着事后清理这种混乱局面的。

弱代码所有权是减轻这类问题的一种好办法。大家可以自由修改，代码所有者只需一直关注着就行。

选择弱代码所有权还是集体代码所有权，这更多的是与该团队应对变化及适应变化的能力相关的。两者都可以正常工作，也都可能发生问题，机会均等。我个人更欣赏推行集体代码所有权的团队具备的应变活动力——尤其是在极限编程的情境下。