单体中心代码库-分布式代码库-vs. (单体中心代码怎么写)

教程大全 2025-07-19 04:49:50 浏览次

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

2017-07-13 16:20:28一些正在快速增长或者需要转型的中小型公司，是应该学习Google的核心代码库，还是学习Linux，Android以及OpenStack等开源项目？

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

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

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

(1) 由于当前大部分的商业和开源代码管理工具或者系统在管理一个超过10亿个文件，20亿行代码的中心库时效率都十分低下，而且随时都有大量的代码同步(包括代码获取和提交)请求。

所以为了在不影响程序员日常工作效率的前提下对海量代码进行高效管理，一般情况下这样的团队或者公司都会开发或者定制自己专用的代码管理工具和系统，比如Google开发的Piper，Facebook定制化的Mercurial和Microsoft定制化的Git系统GVFS等。

(2) 大型公司一般是经过长时间的积累才有如此巨量的代码，并且都有自己特定的经历和原因，比如开发了大量定制化的外围辅助工具和系统，形成了特有的一套代码管理模型和流程。所以更换这种大型代码库的管理工具成本非常高，而且现实中很难找到一个代码管理系统能满足已有的管理和流程需求，所以一般情况下都不会更换。

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

戳这里，看该作者更多好文

为什么Ubuntu系统无法运行VS Code

是否正确安装。不然是无法运行的安装Visual Studio Code首先需要安装Ubuntu Make。 Ubuntu Make存在Ubuntu 15.04资源库中，但需要Ubuntu Make 0.7以上版本才能安装Visual Studio。所以，需要通过官方PPA更新到最新的Ubuntu Make，支持Ubuntu 14.04、14.10和15.04，但仅64位版本。打开终端，使用下列命令，通过官方PPA来安装Ubuntu Make：sudo add-apt-repository ppa:ubuntu-desktop/ubuntu-makesudo apt-get updatesudo apt-get install ubuntu-make安装Ubuntu Make完后，接着使用下列命令安装Visual Studio Code：umake web visual-studio-code　卸载Visual Studio Code，同样使用Ubuntu Make命令。如下：umake web visual-studio-code --remove如果不使用Ubuntu Make，也可以通过微软官方下载安装文件。 Download Visual Studio Code for Linux

在Java中什么是EJB

EJB (Enterprise JavaBean)是J2EE的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。在J2EE里，Enterprise Java Beans(EJB)称为Java 企业Bean，是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。 Bean用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个Session Bean来为客户端服务。 Session Bean可以直接访问数据库，但更多时候，它会通过Entity Bean实现数据访问。 Bean是域模型对象，用于实现O/R映射，负责将数据库中的表记录映射为内存中的Entity对象，事实上，创建一个Entity Bean对象相当于新建一条记录，删除一个Entity Bean会同时从数据库中删除对应记录，修改一个Entity Bean时，容器会自动将Entity Bean的状态和数据库同步。 Bean是EJB2.0中引入的新的企业Bean，它基于JMS消息，只能接收客户端发送的JMS消息然后处理。 MDB实际上是一个异步的无状态Session Bean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。 EJB实际上是Sun的J2EE中的一套规范,并且规定了一系列的API用来实现把EJB概念转换成EJB产品是BEANS,BEANS是什么概念,那就是得有一个容纳她,让她可劲造腾的地方,就是得有容器必须生存在EJB容器中.这个容器可是功能强大之极!她首先要包装你BEAN,EJB的客户程序实际上从来就不和你编写的EJB直接打交道,他们之间是通过HOME/REMOTE接口来发生关系的.它负责你的BEAN的所有的吃喝拉萨睡,比如BEAN的持续化,安全性,事务管理...