将代码集体所有权进行到底！

极限编程中有一个实践是代码集体所有权（Collective Ownership）。这个实践从字面意思理解起来很简单，就是大家共同拥有代码，都有权限浏览、修改代码。这个实践从表面看是一个技术问题，只不过是源代码管理系统的权限如何设置的问题。但从本质上来讲，这是一个团队乃至整个公司的团队协作和勇气的问题。今天借这篇文章和大家仔细展开聊聊。

开始讨论之前先来问个问题：是不是将源代码管理系统（如Git或者Subversion）的权限都放开，就是实施了代码集体所有权呢？请大家认真思考一下这个问题。我想有很多公司是这样设置的，但这只是技术上的一个设置而已，是不是真正实施了集体所有权，我们还要看团队实际的行为。

正如我在前面的文章里谈到的，很多团队的分工是按照模块划分的，一个人负责一个模块，并且团队之间的界限也比较明显。我负责我的模块，你负责你的模块，井水不犯河水。虽然大家都是工作在一个代码库下面，代码也会做集成打包，但我认为真正意义上的代码集体所有权应该从分工上打破这种方式，每个人都可以参与到每个模块的开发中，每个人都有能力修改任一模块的代码以完成新功能的开发或者Bug的修复。所以说只是将权限分配给大家，这种表面的做法是远远不够的。将大家之间的无形界限打破，做到你中有我，我中有你，才是真正意义上的代码集体所有权。下面是禅道项目的实际例子，大家可以看看历史的提交记录。

谈到这儿，估计有朋友就会问，这样做会有很多问题啊。比如某个开发人员对某个模块不熟悉，让他来开发，会影响项目进度；再比如，团队几个人的编码风格不统一，容易打架。这类问题如何解决呢？极限编程也有解决方案，比如推行编码规范、结对编程和代码评审，都可以很好地促进代码集体所有权。请大家参考我之前写过的《极限编程里最容易被忽略的实践》和《无结对，不编程》这两篇文章。

接下来聊聊开篇提到的勇气的问题。是否真正实施集体所有权，从根本上来讲是团队勇气的体现。站在团队管理者角度来看，是否有勇气接受因为打破模块之间原有分工带来的不确定性，诸如代码不熟悉而带来的工期延长、Bug增加？站在团队成员角度来讲，是否有勇气去改动其他同事维护的代码，是否有勇气对过往代码里不合理的地方进行重构？

所以极限编程的核心价值会讲到勇气。价值观的东西比较虚幻，大家都找不到抓手，怎么做就是有勇气了呢？实施代码集体所有权就是勇气的体现。短期看确实会因为打破之前的分工模式会带来一些混乱，甚至是一些故障乃至事故。但对整个团队乃至公司来讲，要有这样的勇气来经历这样一个过程。当真正经历这个过程中之后，会有很多意想不到的收获。代码集体所有权会让团队真正地成长为一个互相信任、深度协作的团队；也可以进一步地促进技术和业务经验在团队里的推广，避免单点的问题；还能减少重复造轮子的问题，提高代码的复用率。

就拿禅道自身来讲，代码从2009年开始到今天，已经迭代了13年多。这期间有大量同事参与到了代码的开发。大家感兴趣的话可以看看我们的代码，不看提交记录的话，你会感觉禅道的代码就像是一个人写的。对团队情况不熟悉的话，基本上分辨不出代码是谁写的。这就是我们团队践行代码集体所有权的结晶，对我们的好处就是团队的任意一人可以参与禅道的任一模块，这样在排兵布阵时就可以很灵活。

有的公司出于保密需求，可能没有办法做到这种程度的开放和协作，但也可以通过项目内部的权限控制、内部开源、开放SDK、开放参考手册等方式，促进团队之间的分享和协作，带来的优势也是显而易见的。

有勇气，就将代码集体所有权进行到底吧！