当前位置: 首页 > 科技观察

Singlecentralcodebasevs.distributedcodebase

时间:2023-03-16 00:06:29 科技观察

去年年中,谷歌的两位工程师在《美国计算机学会通讯》发表了一篇论文《WhyGoogleStoresBillionsofLinesofCodeinaSingleRepository》,介绍了谷歌为什么采用A自定义大型单体中心代码库并在多个会议上分享了主题。InfoQ中文网还发表了一篇比较客观的文章《谷歌为什么要把几十亿行代码放在一个库里?点评谷歌的代码管理方式,总结了谷歌号称独树一帜的中央库代码管理方式的优势包括:统一版本控制广泛的代码共享和复用简化依赖管理,避免菱形依赖原子修改大规模重构交叉-团队协作灵活的团队边界和代码所有权代码可见性和清晰的树结构提供隐含的团队命名空间也总结了谷歌独特的中央库代码管理方法的一些问题,包括:工具投资(谷歌开发了自己专用的EclipseID插件)代码basecomplexity(需要依赖重构和codeCleanup辅助工具)Codehealth(专门工具可以自动检测和删除无用代码,分配codereview任务等)对于像Google这样的大团队或公司,他们的代码管理似乎是一个简单的单一码库管理方法,其实并不容易管理,甚至需要大量的额外投入来辅助管理,因为它是各种前提和约束下的历史产物,其中最重要的是:(1)由于目前大多数商业和开源的代码管理工具或者系统在管理一个拥有超过10亿个文件和20亿行代码的中央库时效率非常低,并且随时有大量的代码同步(包括代码获取和提交)请求。因此,为了在不影响程序员日常工作效率的情况下高效管理海量代码,一般此类团队或公司会开发或定制自己专用的代码管理工具和系统,例如Google开发、Facebook定制的Piper。Mercurial和微软定制的Git系统GVFS等(2)大公司一般经过长时间的积累会有如此庞大的代码量,都有自己特定的经历和原因,比如开发了大量的定制化周边辅助工具和系统,形成一套独特的代码治理模型和流程。因此,更换这么大的代码库管理工具的成本非常高,而且现实中很难找到能够满足现有管理和流程要求的代码管理系统,所以一般情况下不会更换。例如,谷歌最初使用Peforce来管理其庞大的中央代码库,但后来发现无法支撑其庞大的代码量,因此开发了Piper来管理中央库管理,并在代码健康方面投入了大量成本,例如开发了专用工具来自动检测和删除死代码、分配代码审查任务等等。尽管谷歌也曾尝试迁移到Git,最终由于文化和工作流程的巨大变化而放弃,但它仍会尝试使用一些新的代码管理工具来用于一些新的实验性或开源项目。尽管谷歌的大部分核心代码都是使用Piper在中央代码库中进行管理和维护的,但它仍然有许多开源项目,包括AndroidOpenSourceProject(2008年)和Chromium(2014年转为Git)。大型项目或者创新初期的项目还是可以选择使用Git等开源代码管理工具进行代码管理,所以要给项目组足够的权利去选择适合自己项目的代码管理工具,让团队能够感到足够的尊重和尊重。力量。世界上很少有像谷歌和微软这样有财力物力开发或定制适合自己的专用代码管理和周边辅助工具的公司,大多数公司也只是通过购买开源软件来适合商业使用。免费管理您自己的代码或使用基于云的代码管理系统。由于选择单一代码库还是分布式代码库直接影响到团队对代码管理工具的选择和使用,所以一些快速成长或需要转型的中小型公司对代码管理方式的选择产生了疑惑,代码管理工具:是学习Google的核心代码库,继续使用单一的代码库管理方式,然后开发定制自己的代码管理工具,还是学习Linux、Android、OpenStack等开源项目,转向分布式代码管理方法和免费的分布式代码管理工具,或者直接使用基于云端的代码管理系统等。为此,我总结了一个代码管理工具,并选择了一个四象限图来帮助中小企业选择代码管理方法和代码管理工具:资源主要是指资金和人力资源,而技术是指大部分工程师的技术能力尼尔斯。通过这个四象限图,中小企业可以从另一个角度思考和判断自己应该选择什么样的代码管理方式和代码管理工具。对于大型软件公司,如谷歌、Facebook、微软等,不适合使用这种四象限模型。相反,他们需要根据自己的具体情况开发或定制代码管理工具,可以是中央服务器。也可以分发,不管是什么形式,只要适合自己的实际情况即可。【本文为专栏作家《ThoughtWorks》原创稿件,微信公众号:Thinkworker,转载请联系原作者】点此查看该作者更多好文