单体中心代码库 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等这样规模的公司就不适合用这个四象限模型,而是需要根据自身具体的情况而自己开发或者定制的代码管理工具,可以是中心服务器式,也可以是分布式,无论什么形式,只要适合自己的实际情况就可以了。


原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2017-07-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java技术栈

高级 Java 必须突破的 10 个知识点!

工作多少年了,还在传统公司写if / for 等简单的代码?那你就真的要被社会淘汰了,工作多年其实你与初级工程师又有多少区别呢?那么作为一个高级Java攻城狮需...

3855
来自专栏腾讯移动品质中心TMQ的专栏

探索式测试基础系列——生活协奏曲

前文讲过,探索式测试能为平常的生活带来浪漫因子,在浪漫一段时间后,新奇感消失,但效果仍在,探索式测试与日常测试真正融为一体,深刻作用于产品质量保证,共同演奏出...

20510
来自专栏云计算D1net

无服务器:云计算下一步的演变

行业专家在世界各地的会议中,以及与同事,客户,合作伙伴的沟通交流中,感觉到了业界对无服务器计算的困惑。 人们对于这种新架构如何革新组织处理开发和创新的方式,期...

32111
来自专栏JavaQ

三分钟学习持续集成

什么是持续集成 持续集成(Continuous Integration),简称CI,是持续地编译、测试、审查、打包、部署源代码的过程,是一种软件开发实践。 持续...

3585
来自专栏ThoughtWorks

2015.5 技术雷达 | 技术篇

(点击图片可查看大图) 当多个独立开发的服务通过 API 交互的时候,API 提供端的改动会让它所有的消费端调用失败。消费端服务通常也不会直接去连接处于开发中...

3015
来自专栏最新活动整理

腾讯云主机的特点和优势

很多朋友都想买腾讯云主机,但是对腾讯云主机的优势和特点缺乏一定的了解,腾讯云主机有什么特点?腾讯云主机有什么独特的优势呢?今天,简单总结下腾讯云主机的优势和特点...

4390
来自专栏云计算D1net

克服多云管理的6种工具

如今,服务器的数量正在激增,而现在的工作将由数十台、数百台甚至数千台服务器进行处理。以往人们可以用Word或Excel文档中的剪贴板或清单直接保存所有内容,现在...

4223
来自专栏大魏分享(微信公众号:david-share)

数据大爆炸,业务怎么办?

864
来自专栏hadoop学习笔记

DKHadoop大数据平台架构详解

大数据的时代已经来了,信息的爆炸式增长使得越来越多的行业面临这大量数据需要存储和分析的挑战。Hadoop作为一个开源的分布式并行处理平台,以其高拓展、高效率、高...

2710
来自专栏重庆的技术分享区

微服务介绍

原文地址:https://medium.freecodecamp.org/an-introduction-to-microservices-2705e7758f...

1832

扫码关注云+社区

领取腾讯云代金券