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