我开发了项目 A ，一开始是为区域 A 服务的，后来变成标准化产品，也要给别的区域部署开发，但区域都有自己的个性化需求，所以我尝试过下面的解决方案：
-
在项目 A 新建一个针对区域 B 的分支，在上面维护开发区域 B 的需求，但这样在后期有很多区域的时候，很难维护。举例，有些 bug 在这个分支修复了，别的分支还存在；突然上面说要改版首页或功能，要求所有区域升级，这 NM 的
-
主仓库为基础库 fork 出子仓库的模式开发，只能复用部分功能，而且很麻烦，各种合并或 cherry pick
各位进来的大佬，有什么好的解决方案吗，主要是想维护方便。感谢分享指教
把公共的部分抽出来啊
创建自用的组件库/模板库
@babyoung 怎么抽，展开讲讲
把你公共部分封装成组件复用
@xfq2 高耦合，低内聚
通用模块发布到 npm 仓库，用到的地方安装一下
@DesnLee 公共部分太多了，个性化都是局部的修改
无解，不管是组件还是分支，只要定制化就是坑，纯人力维护。
@codingguy 很难以组件的形式复用
专门弄个人 对提交的代码审查了入库
复制粘贴吧，个性化内容越多组件越难写
@MRG0 这就是目前的方法 难受啊
复制粘贴其实是最快的, 考虑的越多麻烦越多, 需求有变化改起来考虑的就越多
submodule
你都能辨别出来哪些是公共部分，为啥抽不出来？
无解。只能很多个 if-else 。但代码会臃肿，判断也复杂。
@ayase252 举例，区域 B 相对于项目 A 增加了一个霸屏功能，功能较复杂开发时需要修动很多公共部分代码，而这在区域 A 是不需要的
无非就是一些常见的手段：组件化开发、参数配置化、版本和分支管理、代码动态加载分割、高度可配置的模块等等。
具体一点的话就是基于上面的一些思想去做的事情，比如：
1.使用组件库去维护一些常见的 UI 模块；
2.模块化开发，将项目去拆分多个模块，每个模块去负责实现一个功能，尽量单一职责，最终目的是更好地管理和复用代码；
3.可以结合一些配置文件，把一些可变的配置项抽离出去，放在单独的配置文件中，可以包括一些主题样式，api ，功能开关等等，针对不同的版本项目去创建不同的配置文件
4.还有就是一些条件编译、模块动态加载，异步组件等等。
用一个 npm 包，包里面拆分出来各个区域路径，
如
xxxpkg/区域 A/组件 A
xxxpkg/区域 B/组件 A
组件 A 在 xxxpkg 中可以维护公共部分，在各区域路径下，实现自定义部分。
有 bug 修复了更新版本，其他项目更新一下包版本即可。
考虑下 git 子仓库？公用的丢子仓库里
Monorepo: npm workspace
@xfq2 加开关来配置各项功能呢？
@xfq b 区域抽出来，参数里添加 config 对象。根据 config 字段选择执行的逻辑。其他项目调用的时候传 config 呗
不过就怕项目单测太少，重构这边导致其他 bug ，单测要全覆盖就还好，否则费力不讨好...
@ayase252 是 isB 这种开关吗 会增加好多判断 而且区域多了就混乱了
@goldenAndGreen 参数添加 config 对象能展开说说吗
@tomieric @6379616e @wpzz @liberty1900 研究下感谢分享
以前也搞过这种 接了二三十和客户 ,实践下来还是一个仓库一个分支好维护.
定制功能就直接 isA isB 区分
复杂度高的内容提升为公共模块，复杂度低的弱智类个性化，转化为 monkey script
试了一下 npm link ，上了 vue3 把 api 和 hooks ，以及一些工具类拆出来了
复制粘贴
一开始就不造轮子，剩下的就是业务代码了，业务代码怎么服用，直接粘贴啊
不要多发布分支，很乱
设计模式：工厂模式、策略模式、适配器模式。你可以看哪个合适。
举个小例子，
上面说的这些根本不是 ToB 行业内的解决方案, 正确的解法是通过 rpa 扩展来实现不同企业的不同需求
git 的 submodule
我也想问，目前还没有找到切实可行的方法
你需要项目产品化方面知识，有两个维度，一个是需求，一个是技术，需求方面得按产品化思路定义产品需求，哪些是产品核心需求，哪些是定制化需求，需要边界，这个产品化的过程是一个过程，涉及到需求的上升和下沉，技术架构的重构。实际上大部分情况实施的时候往是从客户定制化的项目需求转换成产品需求，这里需要有产品思维的人把关。
在说回技术层面，涉及到技术架构的重构调整，这个架构是产品化的基础，要有良好的扩展性，特别是对产品需需的额外订制和扩展。从这里又引伸出来代码分支模型，核心产品做为主库，正常开发按迭代推进，识别核心需求和定制需求，可以按客户创建定制化分支，优先开发核心需求，引入特性分支，按特性分支模式开发新需求，特性需求和定制需求通过 pr 合并到主分支或者是客户的定制分支。。。。反正挺复杂的
无解的事，越封装越拆分开发成本越高，能抽组件抽组件，不能抽组件就复制粘贴。无解~
定制化开发，不抽离。
@LOWINC 你这 20 、30 个版本这么维护太猛了 有针对很多 isA, isB 做什么优化吗
@SoloCompany monkey script 是什么手段，能展开讲讲不
很多业务就不会再第二个客户上出现. 这种也只能 isA,isB
建个 partner 文件夹 专门写这种 isA,isB 的代码, 项目主体并不会很乱
其它就参考 @xuhai951753 ,不要搞复杂了
@xfq2 #9 不一定必须是组件的形式，可以就一坨代码都发上去，暴露接口
@adonislsh 什么是 rpa 啊
必须要和产品，UI ，一起设计，定制规范才可行，不然开发一个人去做，是很难适应产品 UI 的需求变化
@xfq2 #9 或者看看这个 https://bit.dev/
pnpm workspace + monorepo
怎么方便怎么做。 后面干不下去就跑路👀
复制 跟 java 一个思路就行
静态页面 client side render ，动态页面就 server side render,然后分库维护？
通过配置来处理吧 一个页面 可能就一两个字段的区别
我也推荐 isA 、isB 的做法，多分支维护非常痛苦。然后最好说服给你需求的人，让他少提差异化需求
功能做成插件化模式. 提供各种通用接口到插件里, 需要定制的功能,就引入一个独立插件专门处理.
环境变量是最佳实践，18 年政务云原生的实践经验，其实就类似 C 的宏定义编译那套
公司也有类似的场景，一开始就担心一些定制化的需求会修改标准化模块，所以从标准化的 fork 了一个项目出来，在跌跌撞撞的维护了半年左右以后，再想从标准化通过 git 同步代码已经变得举步维艰，因为上游的产品经理和下游的产品经理对于“标准”的定义起了分歧。
目前唯一还完全通用的模块，都是在业务代码之外的，比如组件库之类的。时间久了，最开始没抽出来的东西，都会发生变化的，自己考量吧。
1 、前后端分离，前端按区域定制开发，代码级复用；后端一个版本打天下，定制业务提供定制接口，调用公共接口
2 、需求管控，尽量将同类功能统一，不定制；