单体中心代码库 vs 分布式代码库

去年中旬两位Google工程师在《美国计算机学会通讯》发表了一篇论文“Why Google Stores Billions of Lines of Code in a Single Repository”，它介绍了谷歌为什么采用一个定制的大型单体中心代码库，并且在多个大会上分享了这个话题。InfoQ中文网站也发表了一篇较为客观的文章”Google为什么要把数十亿行代码放到一个库中？”来评论Google这种代码管理方法 ，其中总结了Google宣称的这种唯一中心库代码管理方式的优势，包括：

• 统一版本控制
• 广泛地代码共享和重用
• 简化依赖管理，避免菱形依赖
• 原子修改
• 大规模重构
• 跨团队协作
• 灵活的团队边界和代码所有权
• 代码可见性以及清晰的树形结构提供了隐含的团队命名空间

并且也总结了Google这种唯一中心库代码管理方式的一些问题，包括：

• 工具投入(Google开发了自己专用的Eclipse ID插件)
• 代码库复杂性(需要有依赖重构和代码清理辅助工具)
• 代码健康(专用工具可以自动检测和删除无用代码、分派代码评审任务等)

更多的问题讨论参见这里。

对于Google这样的大型团队或者公司，他们的代码管理看起来是简单的单体代码库管理方式，其实真正管理起来并不简单，甚至需要大量的额外投入来辅助管理，因为它是在各种前提和限制条件下的历史产物，其中最为重要的两点是：

• 由于当前大部分的商业和开源代码管理工具或者系统在管理一个超过10亿个文件，20亿行代码的中心库时效率都十分低下，而且随时都有大量的代码同步(包括代码获取和提交)请求。所以为了在不影响程序员日常工作效率的前提下对海量代码进行高效管理，一般情况下这样的团队或者公司都会开发或者定制自己专用的代码管理工具和系统，比如Google开发的Piper，Facebook定制化的Mercurial和Microsoft定制化的Git系统GVFS等。
• 大型公司一般是经过长时间的积累才有如此巨量的代码，并且都有自己特定的经历和原因，比如开发了大量定制化的外围辅助工具和系统，形成了特有的一套代码管理模型和流程。所以更换这种大型代码库的管理工具成本非常高，而且现实中很难找到一个代码管理系统能满足已有的管理和流程需求，所以一般情况下都不会更换。比如Google最开始使用Peforce来管理其单体中心代码库，后来发现它无法支持其巨大的代码量，所以开发了Piper用以管理中心库管理，并且其在代码健康上投入了大量的成本，比如开发了专用的工具来自动检测和删除无用代码、分派代码评审任务等。虽然Google也尝试过向Git进行迁移，最终由于文化和工作流程的巨大变更而放弃了，但是仍然对于一些新的实验性的或者一些开源的项目会尝试使用一些新的代码管理工具。

虽然说Google的大部分核心代码都是使用Piper在一个中心代码库进行管理和维护的，但是它仍然有不少开源项目，其中包括Android Open Source Project(2008)和Chromium(2014转向Git)这样的大型项目，或者创新的初始项目依然可以选择使用Git这样的开源代码管理工具进行代码管理，所以应该给予项目组足够的权利去选择适合自己项目的代码管理工具，从而让团队感受到足够的尊重和动力。

而世界范围内像Google和Microsoft等用有财力和物力去开发或者定制一款适合自己的专用代码管理及其周边辅助工具的公司是很少的，而绝大多数公司只适合通过购买商用，使用开源免费或者使用基于云的代码管理系统来管理自己的代码。

由于选择单体代码库还是分布式代码库直接影响了团队对于代码管理工具的选择和使用，所以一些正在快速增长或者需要转型的中小型公司就对代码管理方式和代码管理工具的选择产生了疑惑：是应该学习Google的核心代码库而继续使用单体代码库的管理方式，然后自己开发和定制化自有的代码管理工具，还是学习Linux，Android以及OpenStack等开源项目而转向分布式代码管理方式和免费的分布式代码管理工具，或者直接使用基于云端的代码管理系统等。

为此我总结了一个代码管理工具，选择四象限图用以帮助中小型公司选择代码管理方式和代码管理工具：

其中资源主要是指钱和人力资源，而技术是指项目组或者公司里面的大部分工程师的技术能力。

通过这个四象限图，中小型公司就可以通过另外一个角度去思考和判断自己应该选用什么样的代码管理方式和代码管理工具。而对于大型软件公司，比如类似于Google，Facebook，Microsoft等这样规模的公司就不适合用这个四象限模型，而是需要根据自身具体的情况而自己开发或者定制的代码管理工具，可以是中心服务器式，也可以是分布式，无论什么形式，只要适合自己的实际情况就可以了。