首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

应该将多模块项目何时拆分为单独的存储库树?

在多模块项目中,将项目拆分为单独的存储库树是一个重要的决策。以下是一些建议,以帮助您决定何时将多模块项目拆分为单独的存储库树:

  1. 代码共享和重用:如果项目中的多个模块共享代码或者有可能在其他项目中重用,那么将它们拆分为单独的存储库树是有益的。这样可以更容易地在其他项目中重用代码,并且可以更好地管理和维护代码。
  2. 独立开发和部署:如果项目中的不同模块可以独立开发和部署,那么将它们拆分为单独的存储库树可能是有益的。这样可以更好地管理开发和部署过程,并且可以更快地响应变更需求。
  3. 隔离风险:如果项目中的不同模块存在隔离风险,那么将它们拆分为单独的存储库树可能是有益的。这样可以更好地管理风险,并且可以更容易地识别和修复潜在问题。
  4. 更好的协作:如果项目中的不同模块需要不同的团队进行协作,那么将它们拆分为单独的存储库树可能是有益的。这样可以更好地管理协作过程,并且可以更容易地分配资源和任务。

总之,在多模块项目中,何时将项目拆分为单独的存储库树需要根据项目的具体情况来决定。如果项目中的不同模块有共享代码或者可能在其他项目中重用,或者它们可以独立开发和部署,或者它们存在隔离风险,或者它们需要不同的团队进行协作,那么将它们拆分为单独的存储库树可能是有益的。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

微信ANDROID客户端-会话速度提升70%背后

可以把Fragment想成Activity中模块,这个模块有自己布局,有自己生命周期,单独处理自己输入,在Activity运行时候可以加载或者移除Fragment模块,同时可以把Fragment...打头作为where过滤条件SQL是消息模块涉及查询语句,从平均执行耗时来看这些SQL应该存在一定优化空间。...当时能想到表之后一些优势如下: 数据内聚,减少I/O sqlite所有的表是通过B+进行存储,当整个message表数据量较大时候,因该表所在B+深度较大,所有的查询或更新操作都会因此而多走很多磁盘...则整个消息存储就在物理空间上被分成了多个区间,同一个联系人消息,在空间上被内聚到临近磁盘块,这样的话,整个消息模块所在B+深度就降低了,读取时候也会因磁盘临近性(连续4k,磁盘一次读取最小单位...(背景:关于B+介绍,可见http://www.semaphorecorp.com/btp/algo.html) 增加损坏后恢复数据成功机率 用过sqlite同学应该清楚,其存在不可避免损坏机率,

3.6K70

React组件设计实践总结02 - 组件组织

这些状态管理器通常都在组件外部维护一个或多个状态, 然后通过依赖注入形式, 局部状态注入到子树中. 通过视图和逻辑分离原则, 来维持组件纯净性....、views Domain-style/by-feature: 按照一个功能特性或业务创建单独文件夹,包含多种类型文件或目录 实际项目环境我们一般使用是混合模式,下面是一个典型 React 项目结构...这里页面组件放置在containers, 如其名,这个目录原本是用来放置容器组件, 实际项目中通常是‘容器组件’和‘页面组件’混合在了一起, 现阶段如果要实现纯粹逻辑分离,我个人觉得还是应该抽取到...你希望单独对某个页面进行构建和维护, 而不是所有页面混合在一起构建 这种场景可以利用lerna或者 yarn workspace 这里 monorepo 机制, 页应用隔离在不同 npm 模块下,...上述方法对组件 render 拆分为多个子 render, 当一个组件变得臃肿时, 就可以方便地这些子 render 方法拆分为组件.

1.9K31

iOS组件化设计与开发

【2】项目各个模块按照基础组件,功能组件,业务组件划分成一个个单独模块,以使得各个模块间可以单独开发、测试、组合运行。...组件化第二步-独立业务模块单独 在基础成体系基础上(基础依赖),下面需要对业务模块之间(横向依赖)进行拆解。这部分是比较难也是容易碰到问题。...我们可以按照需求定性一些相对独立业务模块独立成单独在一个工程上进行开发、测试。 往往在这个阶段有一个误区,千万不能为了组件化而强行将一些耦合严重业务模块分出。...另外拆分粒度需要大一点,需要在功能模块基础上,业务独立性考虑进去,如果没有就不,等以后有了相对独立模块之后再。...- 业务方开发效率不够高,开发人员一,每个人都只想关心自己组件,但是却要编译整个项目,与其他不相干代码糅合在一起。

1.3K50

React Native 包原理和实践

metro 介绍和打包流程 metro 是一种支持 ReactNative 打包工具,我们现在也是基于他来进行,metro 打包流程分为以下几个步骤: Resolution:Metro 需要从入口点构建所需所有模块图...id 只是在打包时生成,如果我们单独打业务包,基础包,这个 id 连续性就会丢失,所以对于 id 处理,我们还是可以参考上述开源项目,每个包有十万位间隔空间划分,基础包从 0 开始自增,业务 A...,export 编译后就就转换成了 __d 与 __r 三、后遗症 1、按序加载基础包和业务包 RN js 业务拆出了公共模块之后,在 bridge 加载 bundle 时候需要优先加载...如果有些模块需要在其他 App 内复用,建议采用携程模式,他们对路由进行了优化(没开源),管理起来应该会方便些。 4、路由表调整 包之后路由表怎么维护呢?...但后来突然想明白,本质就是通过设置多个入口文件代码给分割,那调试时候我们直接入口文件都在放在 index.js 里不就行了么。这样就实现了跟RN单包一样调试。

4.5K21

大厂原来都这么对MySQL分库分表!

1 何时分库分表 业务飞速发展,数据规模急速膨胀,单机DB已无法满足业务发展。 传统数据集中存储至单一数据节点解决方案,在容量、性能、可用性和运维成本这三方面难满足海量数据场景。...水平拆分意义 数据均匀放更多,然后用多个抗更高并发 多个存储进行扩容 5.2 垂直拆分() 解决问题 服务不能复用 连接数不够 一个数据,拆分成多个提供不同业务数据处理能力数据...原来老订单,切分为基础订单和订单流程。数据之间表结构不同 水平切分:将同个表数据分块,保存至不同数据 以解决单表中数据量增长压力。...4.1.1 查询切分 key和映射关系单独记录在一个数据。...比如一个订单,分库分表方案是32*32,即通过UserId后四位mod 32分到32个中,同时再将UserId后四位Div 32 Mod 32每个分为32个表,共计分为1024张表。

1.6K10

webpack 学习笔记系列06-打包优化

sunjianfeng@csxiaoyao.com QQ: 1724338257 1. splitChunks 拆分代码 1.1 三种拆分方式 webpack 三种代码拆分方式: entry 入口配置...(魔法注释),注意:若 minSize 设置较大,不会单独拆出 vendors~a.js lodash 为同一个 a-lodash.js(魔法注释) all: 推荐,在 initial 基础上尽可能生成复用代码...'] module.noParse: 排除不需要解析模块 尤其是 jQuery 等未采用模块化标准且体积庞大,但要注意,排除文件不能包含 import、require、define 等模块化语句...需要单独为 dll 文件创建一个配置文件,通过 DLLPlugin 插件第三方依赖打包到 bundle 文件,并生成 manifest.json 文件,在项目的 webpack 配置文件中使用 DllReferencePlugin...实现需要保持良好开发习惯: 必须使用 ES6 模块 按需引入,尤其是 UI 框架 减少代码中副作用(纯函数) // package.json { "name": "tree-shaking-side-effect

1.8K201

分库分表方案

商城项目使用单数据 如上图,商城系统包括主页 Portal 模板、用户模块、订单模块、库存模块等,所有的模块都共有一个数据,通常数据中有非常表。...第一个阶段商城系统单体架构按照功能模块分为子服务,比如:Portal 服务、用户服务、订单服务、库存服务等。...水平拆分方式也很多,除了上面说按照 id 表,还可以按照时间维度取拆分,比如订单表,可以按每日、每月等进行拆分。 每日表:只存储当天数据。...单拆分 在一个数据中将一张表拆分为几个子表在一定程度上可以解决单表查询性能问题,但是也会遇到一个问题:单数据库存储瓶颈。 所以在业界用更多还是子表拆分到多个数据中。...分库分表带来复杂性 既然分库分表这么好,那我们是不是在项目初期就应该采用这种方案呢?不要激动,冷静一下,分库分表的确解决了很多问题,但是也给系统带来了很多复杂性,下面简要说一说。

16811

Webpack中高级特性

探索webpack高级特性特性:treeShaking顾名思义treeShaking,就是摇,那么体现在代码模块里面就是摇掉那些没有被外部成员引用代码,指注意是在生产环境下treeShaking...optimization: { usedExports: true, // 只导出外部成员引用模块 // 此属性用于模块导入合并,因为单独模块导入要使用_webpack_require...根据项目背景,入口打包。结合ESMDynamic import特性,按需加载模块。对第三方包使用包策略。...入口打包具体实践入口打包体现在页应用,每一个页面依赖于一个打包文件,对于模块公共代码进行提取到公共结果中。...第三方包包策略所谓三方包,在在入口里面也提到过optimization.splitChunks只是一种提取三方包方式,我们现在要讲的是插件层面的DllPlugin和DllReferencePlugin

52120

大厂Java面试题解(45)-设计一个高并发系统

2 服务拆分 一个服务为多个服务。每个服务单独连一个数据,这样原本只有一个,现在有多个数据,最容易做到抗高并发。即微服务架构。...3 缓存 高并发场景,大多读写少,可以在数据和缓存里都写一份,然后读时大量走缓存。 而Redis轻轻松松单机几万并发,所有系统都有缓存中间件。...所以考虑在你项目中,让承载主要请求读场景,使用缓存来抗吧。 4 消息队列 可能还是会出现高并发写场景(秒杀场景)。...5 分库分表 可能到最后数据层,还是免不了抗高并发。 那么就将一个数据为多个,多个来抗更高并发。 一个表拆分为多个表,每个表数据量保持少一点,提高SQL性能。...6 读写分离 数据承载可能也大多是读写少,那就没必要所有请求都集中在一个。 可以设计主从架构,主库写,从读,实现读写分离。如果读流量太多,再加从

55210

浅谈MySQL数据面试必要掌握知识点

这消除了复杂、耗时且昂贵数据移动以及与单独分析数据集成需要。...查询特别慢,因为MyISAM行数单独存储了,而InnoDB需要朱行去统计行数;所以如果使用InnoDB,而且需要查询行数,则需要对行数进行特殊处理,如:离线查询并缓存; MySQL常用存储引擎底层原理...; 索引,不同存储引擎索引并不太一样;在选择存储引擎时,应该根据应用系统特点选择合适存储引擎。...比如对第2节两个job批量更新情形,简单方法是对id列表先排序,后执行,这样就避免了交叉等待锁情形;又比如对于3.1节情形,两个事务sql顺序调整为一致,也能避免死锁。 大事务小。...大事务更倾向于死锁,如果业务允许,大事务小。 在同一个事务中,尽可能做到一次锁定所需要所有资源,减少死锁概率。 降低隔离级别。

61310

分库分表设计时,需要避开哪些坑?

商城项目使用单数据 如上图,商城系统包括主页 Portal 模板、用户模块、订单模块、库存模块等,所有的模块都共有一个数据,通常数据中有非常表。...第一个阶段商城系统单体架构按照功能模块分为子服务,比如:Portal 服务、用户服务、订单服务、库存服务等。 ?...水平拆分方式也很多,除了上面说按照 id 表,还可以按照时间维度取拆分,比如订单表,可以按每日、每月等进行拆分。 每日表:只存储当天数据。...单拆分 在一个数据中将一张表拆分为几个子表在一定程度上可以解决单表查询性能问题,但是也会遇到一个问题:单数据库存储瓶颈。 所以在业界用更多还是子表拆分到多个数据中。...分库分表带来复杂性 既然分库分表这么好,那我们是不是在项目初期就应该采用这种方案呢?不要激动,冷静一下,分库分表的确解决了很多问题,但是也给系统带来了很多复杂性,下面简要说一说。

85520

大厂Java面试题解(45)-来设计个高并发系统?

2 服务拆分 一个服务为多个服务。每个服务单独连一个数据,这样原本只有一个,现在有多个数据,最容易做到抗高并发。即微服务架构。...3 缓存 高并发场景,大多读写少,可以在数据和缓存里都写一份,然后读时大量走缓存。 而Redis轻轻松松单机几万并发,所有系统都有缓存中间件。...所以考虑在你项目中,让承载主要请求读场景,使用缓存来抗吧。 4 消息队列 可能还是会出现高并发写场景(秒杀场景)。...5 分库分表 可能到最后数据层,还是免不了抗高并发。 那么就将一个数据为多个,多个来抗更高并发。 一个表拆分为多个表,每个表数据量保持少一点,提高SQL性能。...6 读写分离 数据承载可能也大多是读写少,那就没必要所有请求都集中在一个。 可以设计主从架构,主库写,从读,实现读写分离。如果读流量太多,再加从

67820

数据库存储层都涉及到哪些工作?

数据最本质功能,是存储数据,以对外提供数据查询和写入接口。不妨,就首先以这两条线串一下各个模块,然后再补充下不能归到这两条线中一些组件。...对于火山模型来说,我们可以执行计划理解为一个由基本算子(Executor)组成 DAG,甚至再简化一些可以想象成一棵。...如果 RPC 框架不管,就需要用额外线程池、异步(promise、future)、协程来手动控制请求执行流并发执行。 写入 分布式系统中,一般会使用副本来存储数据。...它解决问题是,如何数据组织在单机存储体系中,以最少空间,应对特定场景高效写入和读取。一般分为数据编码、索引组织、并发控制等等几个子模块。...其他模块 除了能直接归到读写流程相关组件,还有一些其他存储层交互比较频繁模块和一些后台运行常驻进程。

55720

前端-手摸手,带你用合理姿势使用webpack4(下)

我们不时会升级 UI 组件来解决一些现有的 bugs 或使用它一些新功能。所以建议 UI 组件单独拆成一个包。...自定义组件/函数 chunk-commons 这里 commons 主要分为 必要和非必要。 必要组件是指那些项目里必须加载它们才能正常运行组件或者函数。...所以应该将那些被大量共用组件单独打包成chunk-commons。 不过还是要结合具体情况来看。...所以还是那句话资源加载策略并没什么完全方案,都需要结合自己项目找到最合适包策略。...它含有 webpack records 记录 – 即「用于存储跨多次构建(across multiple builds)模块标识符」数据片段。

1.2K30

微服务粒度拆分原则

应该尽量处于生命周期中不同阶段接口分割,避免高频更新服务和低频更新服务捆绑,避免向稳定运行服务组添加新业务接口,而是应该考虑在新服务组中实现。 3...., 调整部署使其尽可能靠近数据源等策略,但是如果所有服务宿主都做成高配,会造成巨大资源浪费事实上也没有必要,所以应该高低频访问服务分割以使其能为获得更好性能和可靠性做针对性优化。...数据读写分离 上一维度其实已经涵盖了读写分离一部分,但是为了突出读写分离必要性,这里单独列出。一般数据操作模式分为 CQRS 和 CRUD 两种模式,各有优缺点。...这些和读操作都有巨大差异性, 因此建议流量较大或较为核心服务应该做读写分离,分为两个服务组发布。 最后 微服务“微”如何做到足够合适粒度,是一门艺术。...系统里每个名词一般都会在存储层面对应一个独立实体,如数据表,所以根据系统中出现名词来划分微服务,即可做到一定程度合理性。

2.4K10

关于 SAP Commerce Cloud Github 仓库需要遵循规范

您可以使用 git submodules 功能将内容拆分为多个存储。 在这样设置中,主存储指向单独存储特定提交。 在 Cloud Portal 中为主存储配置凭证随后也可用于子模块。...考虑这样一个场景: 在处理一个项目时,您需要使用其中另一个项目。也许它是第三方开发,或者您正在单独开发并在多个父项目中使用。...您决定使用,而不是编写自己 Atom 生成代码。您可能必须从共享(如 CPAN 安装或 Ruby gem)中包含此代码,或者源代码复制到您自己项目中。...包含问题在于,很难以任何方式自定义,而且通常更难以部署它,因为您需要确保每个客户端都有可用代码复制到您自己项目问题是,当上游更改可用时,您所做任何自定义更改都难以合并。...Git 使用子模块解决了这个问题。子模块允许您将 Git 存储保留为另一个 Git 存储子目录。这使您可以另一个存储库克隆到您项目中并保持您提交分开。

30410

留念 · 大学时代最后系统设计图

3、对于 MySQL 可以考虑存储过程,只要不是太复杂,因为存储过程调试是真的要呕血三升,我调过。 4、业务和数据之间一定要做熔断。...要知道,后端开发很大一个瓶颈就在于网络I/O,木有带宽呀!!! 4、数据字典。数据字典非常重要,在项目分析阶段一定要有明确数据字典,而且一定要做单例模式。可以改,但是不能没有,也不能实例。...---- 下一版架构图 结束是毕设,不是我项目。 简单讲一下变更: 1、业务层拆分微服务,核心业务单独划分,零碎业务凑到一起办了。...后面的业务都需要走登录这一块,也想过登录业务直接作为伴生业务划到网络层 pod 里面去,但是想了想万一登录业务崩了,连带整个网络层一起崩了。所以:做好熔断、 2、既然业务都了,说明流量大了。...那 Redis 也了吧,用来做锁单独一块儿,用来承载数据热点数据单独一块儿。 3、MySQL 暂时不,但是要有能分库分表能力。

26010

聊一聊如何搭建高性能网站哪一些事

用于清除我们项目一些无用代码,它依赖于ES中模块语法。...这样化就会大大减少我们包size。所以在日常引用第三方时候,需要注意导入方式。 如何开启摇 在webpack4.x 中默认对tree-shaking进行了支持。...拆分为 bundle(1M) + react桶(CDN)(1M) 两次请求并发拉取。 从这个角度来看,1+1模式拉取资源更快。...如图这种情况也是在我们项目中发生过。 很明显我们应该把主体“请求文章”接口前移,把一些非主体请求逻辑后移。这样的话可以尽快把主体渲染出来,就会快很多。 优化后顺序是这个样子。 ?...这里直接抛阮一峰入门文章:传送门 3.16 缓存 缓存方面可以讲非常内容,我会单独开一篇缓存全攻略文章来详细讲述,大家可以➕个关注哈,关注越多写越快。

63320

一名分布式存储工程师技能是怎样

先说主题:“一名分布式存储工程师技能是怎样?”我们认为广义上存储应该包含数据,不过分布式数据一般是“独挡一面”:技术特点、技术难度、应用场景上都独具特色。...讨论分布式数据完全可以是一个单独的话题,因此这里先聚焦讨论分布式数据之外分布式存储。 分布式存储的话题还是很大,从访问语义上,一般分为对象存储、块存储和文件存储。...我们YRCloudFile定位是高性能分布式文件系统,因此我们把重心放在着重讨论分布式文件系统工程师技能。鉴于每个部分都可做单独议题展开,所以这里仅简述。...因此我们认为,对于资深分布式存储工程师来说,挑战主要是优秀工程实践,主要是如何去把模块实现得更简洁、更合理、更高性能。...根据我们经验,要自己单打独斗地去构建这样知识,耗时很长,且对个人综合能力要求很高。 因此我们是非常推荐各位参与一个分布式存储项目。 可以是开源项目,也可以加入做分布式存储公司。

1.1K00

体积太大,怎么包?--vite

而通过Code Splitting我们可以按需加载代码拆分出单独 chunk,这样应用在首屏加载时只需要加载Initial Chunk 即可,避免了冗余加载过程,使页面性能得到提升。...我们先通过具体项目来体验一下 Vite 包,示例项目我已经放到了小册 Gihub 仓库中,你可以对照着来学习。...小结一下,Vite 默认优势在于实现了 CSS 代码分割与业务代码、第三方代码、动态 import 模块代码三者分离,但缺点也比较直观,第三方打包产物容易变得比较臃肿,上述例子中vendor.js...: { output: { // manualChunks 配置 manualChunks: { // React 相关打包成单独 chunk...中 'react-vendor': ['react', 'react-dom'], // Lodash 代码单独打包 'lodash':

1.6K100
领券