代码所有制（Code Ownership）

版权所有，欢迎转载，但请注明作者，译者和出处。如翻译欠妥，欢迎不吝指正。

欢迎关注微博：风再起时我就走

英文原文链接：点击打开链接

 

在我的职业生涯中，碰到过各种各样的代码所有制模式。我把它们归纳为三大类：

1、         强代码所有制：把程序分解组织为模块（类，函数，文件），然后为每一个模块指定一个程序员。程序员只能修改归属于自己的模块代码。如果他们需要修改其他模块，则需要告知负责该模块的程序员，然后让这个程序员去做修改。如果你想加快这个过程，你可以直接对这个模块写完补丁代码，然后把它交给代码所有者。

2、         弱代码所有者：与强代码所有制类似的是，它也把代码模块化之后分别指派给对应程序员，不同的是，它允许程序员直接对属于其他程序员的代码做出修改。所有者对自己的模块代码负责，并且需要时刻关注其他人在他所拥有的代码做出的变更。如果你试图对其他人的模块代码做出比较重大的修改，事先最好还是要与代码所有者进行沟通。

3、         集体代码所有制：它抛弃了个人拥有代码的概念。在这种模式下，代码为整个开发团队所共同拥有，任何人可以对改动任何代码。也可以理解为代码无所有制。它强调的概念是代码属于整个团队而非独立的程序员个体。（代码集体所有制的概念来自于XP极限编程，在XP第二版中，这被称之为共享代码）。

 

以上三种，我个人最不喜欢强代码所有制。实际开发中，有太多的需要去改动其他人的代码的情况。说服代码所有者去修改代码，然后再等待修改完成，需要太长时间，这通常会导致项目延迟和其他更深层次的问题。当需要修改的内容很简单的时候，这尤其令人郁闷。

 

仅仅是简单修改但是却不能顺利快速完成的一个很好的例子是重命名一个公开的方法。现代的重构工具可以很好的完成这个，但是如果跨模块修改，却违背了这个代码所有制的规定。

 

更糟的情况是，当你要进行改动的时候，因为你无法很快地修改，你直接复制了一份其他模块的代码到你们的模块中，然后做出一些修改之后直接调用这部分代码。很显然，这是一个很糟糕的处理方式，将来，你必然需要对这个糟糕的代码状况做出处理。

 

弱代码所有制是避免这些问题的一个很不错的方式。大家都可以自由的修改代码，而只需要模块所有者对这些改动保持关注并确保改动没问题。

 

弱代码所有制和集体代码所有制之间如何选择，这与团队的成员工程密切相关，这两个方式都可能成功，或者失败，难以断言孰优孰劣。就我个人而言，我更喜欢集体代码所有制的创新的概念，尤其在极限编程的环境中。