两个类似的项目如何更好的做复用（团队）

[louieliu]

1.两个项目有大量雷同的代码 怎么能更好的复用？ 比如把公共部分拎出来打个包？ 2.如果需要合并到一个仓库里？怎么操作比较好呢？看到有使用 monorepos 来解决的 ？还有什么其他方法 或者各自优点是什么

[dcalsky]

个人复制粘贴。团队抽象成库

[louieliu]

@dcalsky 团队抽象成库当然是一种办法 但是我觉得合并为一个仓库然后去管理是更好的处理方式 这样可以复用的程度更大

[wangxiaoaer]

作为一个过来人，我不得不说复制粘贴大法真香。

曾几何时，我也想过做抽象，甚至考虑用一个库，通过不同分支或者不同的打包策略实现定制。

可是现实很骨感，上面那种方式非常考验你的前期架构和设计抽象能力，因为需求是奇葩的，时间是紧迫的，这意味着有的时候不得不在原本应该属于核心共用的地方做定制，所以就出现了各种 ifelse，长久下来，你已经忘了这个抽象的玩意儿到底是干什么的。

后来还是回归复制粘贴大法。

当然，作为技术人员，追求高层次的抽象，实现软件层面的高度复用是我们的追求，但是面向工资编程，妥协是不可避免的。

[prolic]

copy 成 utils 文件解决，最灵活，需求满足不了还能改改

[dcalsky]

@louieliu 不矛盾，库的源代码本来也就是通过仓库来管理的。

[xuanbg]

公共库+复制粘贴才是王道。

另外一个小技巧是参数名尽可能中性，譬如 data 、obj 、dto 这种，这样复制过去根本不用改。

[zqx]

楼上的做法会出现，一个抽象函数形式参数是 data ,value,list,map，调用的人一脸懵

[keepcleargas]

@wangxiaoaer 你是对的

[hitaoguo]

如果这两个项目后期迭代还是同时新增相同功能的话，把相同部分抽出来吧。
比如你公共部分写好逻辑，进入页面就获取一个列表，具体怎么获取列表就在项目里实现。

[dagouziwangwang]

webpack5 module federation

[wzzzx]

我就说一点，命名一定要中性！我们也有俩类似的，不过在上传文件的阶段，一个上传 pdf，一个上传 png 。就因为名字不中性，根本没法 cherry-pick

[luckyrayyy]

中台了解一下，kpi 在向你招手

[Kirsk]

如果是业务逻辑不要复用 基础组件一定要复用 其实这个问题属于工程管理问题

[BlackZhu]

正好 我们老板叫我们把所有系统统合在一起，数据库随便换，表字段随便换 我估计我在来个 100 年就能开发完成吧