请教一下各位关于前端多项目的问题

[0xxf]

公司最近新开一个后台管理系统的项目，我负责前端，技术栈 Vue。

领导却提出一些不同的想法，让我不要把所有内容都放到一个项目里面，把它拆成多个子项目。

比如「用户管理」是一个项目，「系统设置」是一个项目，「设备管理」是一个项目，

要是我来做，肯定就是 Vue 全家桶，直接按文件目录目录的形式来划分模块，然后点菜单路由跳转就完事了，都堆在一个项目里面。

• 我问领导为啥要这样做，他说，这样方便管理，这个项目很大的，有很多内容，为了以后维护方便，维护某一个模块的时候不需要关心别的模块，

我想了下，好像是那么回事。

• 领导还说了，你要是放到了一起，以后我想升级一些包，比如升级一下 Vue 的版本，是不是要对别的包有所顾忌？假如，将来某个模块，用 react 实现会好很多，那我是不是这部分就是直接用 react 来实现？

我想了下，好像是那么回事，领导牛逼，考虑了这么多场景。

• 领导还说，你把这些用了很多次的组件也弄成一个子项目，比如这个「菜单」，别的子项目也需要用到，你抽出来，以后大家用的时候直接npm install就可以了

我想了下，好像是那么回事。

• 领导还说了，到时候部署的时候，可能是每个子项目一个独立的二级域名或者二级目录，虽然这样弄，模块间的跳转会刷新整个页面，但是莫的关系，你赶紧开工。

我说，好的好的。

V 友，你们有试过这样组织项目的方式吗？这整的和后端微服务一样。。。。

主要是我感觉有点不习惯。

[ansonpro]

个人理解：项目没发展到一定规模的时候，做这些都是过度设计

[zz25]

好的好的。

[hoythan]

领导太闲了吧。

[zz25]

我也想了下，好像是那么回事。

[ansonpro]

@zz25 合理

[luob]

上次有个老铁在这问，他有一大堆前端项目的 node_modules 都有 1 个 G，有没有办法合并一下。

我觉得过不了多久，你也会来问的。

[ansonpro]

@0xxf 实现这种多个 project 的管理可以尝试引入 Lerna，只能帮你到这里啦

[huai]

一个人维护我认为会比较蛋疼 ，多个人合作开发还可以

[learnshare]

目标很理想，现实会啪啪打脸

按路由拆分多个子项目倒是可行，但项目能有多复杂
前端很多东西并不方便 npm install

领导明天还有新想法，你得思考、调研和试验之后，再决定要不要执行

[Inside]

git submodule/subtree 考虑一下。

[mgso]

建议三思而后行

[harde]

15 年年末接了一单 Web 的销售系统，很微小、很简单，简单到报价只有 3,000 块钱。工期 7 天。
在这 7 天里，客户多了些想法，还好，工期延长到 14 天。总报价 15,000。
中间的过程就不细说了，18 年年末，这个项目还在维护中。总建设费用超过了 100 万（不含服务器、带宽、防火墙、高防等费用），拆分了很多业务，演变出多个子系统。

目前来说坑是不少的，但程序还算健壮，通过这个系统走过的现金流水，将近 5 个亿。

虽然我们应该高瞻远瞩，但同时也不要好高骛远，项目初期，够用就好。劝劝你领导吧。

[0xxf]

@luob node_modules/这个大倒不是什么问题，主要是这些子项目的目录结构都差不多大，弄多几次就好烦了，要是都在同一个项目就好了。

@harde 老哥，你这个系统就牛逼了。劝估计是劝不动了，已经决定这么做一个多月了。

@mgso 我就没法思了，领导都决定这么做一个多月了

@learnshare 主要是很多类似的东西本可以放到同一个目录结构，但是拆开了要重复做好几次，烦。

@huai 领导也这么说了，说以后让别人一起来维护也是很方便的。 -_-!

@ansonpro 好的，先谢谢了。弄这个多个子项目，也不知道需不需要独立管理版本的问题，感觉领导没考虑到这个东西

[orozot]

微前端了解一下，你这个就是个典型场景。。。。。不过跟楼上说的一样，项目规模和需求没达到的话，采用微前端结构感觉算是过度设计

[sugars]

过早的优化是罪恶之源。
Code Optimization as a Double-Edged Sword.

[blackywkl]

可以考虑用 lerna 来管理

[maichael]

想法没问题，做法有问题。

[0xxf]

@maichael 怎么说，老哥

[KuroNekoFan]

可以先不分，不过在代码，结构方面可以做好以后会分的准备

[maichael]

@0xxf #18

楼上说的项目没这么大是一个问题。另外微服务也好，微前端也好，通常是已有一部分老的项目，现在需要添加新的项目，使用”微“这种理念来使得新老项目能兼容使用。单单一个新项目强行使用这种方式纯粹是浪费时间精力。

[ducklyl]

听领导的，没错

[lylijincheng]

这种后台管理系统公共的模块和组件应该有很多，包括 API call，工具函数，公共配置等，拆分多个项目要考虑代码重用问题，处理不好后期可能会有很多重复代码，如果拆分成多个 git repo/npm packages 升级维护可能也比较麻烦。

[lylijincheng]

开发成本应该会增加，效果也不一定像领导想的那样

[zarte]

为何没人考虑用传统的 iframe ？两个 iframe 就好了，每个菜单想用啥就用啥。后台管理系统为啥要弄成前后端分离的，数据异步加载。

[0xxf]

@lylijincheng 我的感受和你的差不多。就是会有很多重复的东西，做起来很麻烦。

[jsq2627]

大厂一般是尽量业务拆分，模块拆分，最小单元维护和部署，好处：
* 人员快速流动的大环境里，新人可以很快拿起一个小模块上手
* 模块的大版本更新很容易做灰度
* 大部分一线干活的人只需要掌握自己模块的业务知识，自己的仓库再怎么乱改也不会波及别的业务
* 抽离出架构师职位，专门研究怎么做拆分，怎么提高效率

缺点：
* 如果各个仓库工程体系没统一好，那么多仓库维护很费精力，思维跳转，程序员精力不容易集中
* 复杂依赖关系如果不经常治理，同一库的不同版本会被重复引入

自己大项目模式和拆分小项目模式都经历过，自认为拆分还是利大于弊的

[flyingghost]

我问领导为啥要这样做，他说，这样方便管理，这个项目很大的，有很多内容，为了以后维护方便，维护某一个模块的时候不需要关心别的模块，
我想了下，好像多模块并不等于必须多工程，一般工程内模块划分有按目录的（ java ），有按文件的（ c/python ），都可以做到方便合理清晰。多库多项目依赖管理和发布版本管理的时候简直罗嗦最好有独立的项目经理和构建工程师来做这破事。

领导还说了，你要是放到了一起，以后我想升级一些包，比如升级一下 Vue 的版本，是不是要对别的包有所顾忌？假如，将来某个模块，用 react 实现会好很多，那我是不是这部分就是直接用 react 来实现？
我想了下，好像升级 vue 这种底层包无论在哪个项目中都是一件非常蛋疼的事情，而项目异构简直是双蛋齐疼。

领导还说，你把这些用了很多次的组件也弄成一个子项目，比如这个「菜单」，别的子项目也需要用到，你抽出来，以后大家用的时候直接 npm install 就可以了
我想了下，好像组件复用并不等于必须子项目一种实现方式。别的项目组 /别的公司 /别的星球的人要用，到时候再针对性的抽就是了。这么早就假设不怕这项目下个季度就死掉吗？

领导还说了，到时候部署的时候，可能是每个子项目一个独立的二级域名或者二级目录，虽然这样弄，模块间的跳转会刷新整个页面，但是莫的关系，你赶紧开工。
我想了下，独立二级目录还好，独立二级域名简直是架构级别重新设计，单一个跨域问题就烦死个人。
————心里 MMP 脸上笑嘻嘻的分割线————
我说，好的好的。

[sealong200j]

你们这个项目撑到那时候，再拆也不迟，相信我

[codespots]

挺好的，我们现在的项目升级，我就是采用这种方案来实现的，新老版本并存

[real3cho]

项目周期长的话 随便你设计拆分
项目周期短的话 同样的工期 直接怼基本能开发完大部分功能 这么设计的话可能临近 deadline 都没做几个功能

[as7645820]

我们现在刚好就是这样的，多个项目。用的静态托管的方式，现在我们还是在 php 服务器上进行的静态托管，正在迁移到 node 便于自己维护。
如果楼主要做的话也可以考虑下这个方案，在实际开发中是感觉不到托管项目，托管项目是在服务器上，可以通过 jenkins 或者其他部署到服务上面去就好了。这样项目一个个都是独立，后期也不要拆。也不需要对这个项目做其他处理，只需要另外建一个项目用来托管就好了

[blue0125]

额。。是我的那个项目么 0.0

[green0511]

感觉项目复杂度上来了再考虑这些吧。另外你老大提的方案应该是 [前端微服务] ，可以知乎搜一下相关内容看看

[sunzongzheng]

分久必合合久必分

[otakustay]

多项目其实很烦的，越是大的项目，数据的全局同步越多，比如你项目 A 做了个列表，项目 B 做了个表单，你就不得不面对：

1. 列表唤起表单，可能不是简单的跳转，而是弹窗或者出侧边栏
2. 表单提交后，列表数据同步变化

而事实上，“表单提交后列表变化”不能用过程化的形式去描述，即不能在表单里假设有列表这个东西，因为你并不知道你更新的数据在多少地方有使用到，所以你必须有全局的同步机制

当全局的同步是基本要求时，一个项目提供的就不是单纯、自治、可隔离的一个视图了，它们之间有很强的天然的逻辑耦合性，所以每个项目怎么组织，对外暴露什么，如何引入并组合成完整的系统会非常复杂

所以我是不怎么建议在非必要的情况下擅自以项目为粒度去拆的，会累死

[moxiaonai]

微服务

[VDimos]

不赞同上面的看法，我觉得你们大佬说得没错，后期再考虑这些的话，工程量也不小，还不如一开始就拆分

[mscststs]

过度设计等于没有设计，从你的描述上来看，我觉得这种多项目会带来指数级的开发难度，尤其是依赖和部署上。

[ibegyourpardon]

这个我有话要说。

我就干过类似楼主领导的事，要求别人（最后因能力问题搁浅，后来重新慢慢尝试，小步慢跑）。

中间不同的项目里反反复复很多次。

目前我仍然持有和楼主领导接近的想法，但不再那么激进，会根据实际情况进行调整和妥协。

但从一个系统架构设计的角度来看，我仍然认为拆分利大于弊，包括这种有人认为的过度设计的部分。首先过度设计就是个并没有绝对标准的东西，怎样算是过度的设计？

在项目进度允许，团队成员能力足够的情况下，一个总体复杂度为 10 的东西，而这个复杂度其实是大致可以预见到的，比如 3 个月做出来这个东西，相对可控，但 3 个月后这个项目会变成什么样，怎么发展，我不可预知，不可控，那就不考虑那种做成运行几年，团队扩充到 20 人的事。 但这 3 个月内可能会有的变动，模块和组件的拆分，部署的调整，哪些事情我提前做是可以预留的，这个讲实话，我是觉得需要很深厚的经验积累的。而运用的恰到好处的话，对团队，项目都是有极大的好处。

也就是说，我并不赞同一上来把整体复杂度为 10 的单体应用拆成 10 个 复杂度为 1 的模块，但根据实际情况，拆成一个略小的复杂度为 5 的小单体+ 5 个复杂度为 1 的小模块，是不是会更有利于项目推进、迭代试错、能力培养呢？

而且在开发周期较长的项目里，不考虑因为拆分带来的额外复杂度的情况，就项目本身而言，经常是这么一个转换节奏：

5 +3 + 2
5 + 1 + 1 + 1 + 1 +1
4 + 1 +1 +1 +1 +1 +1
4+ 2 + 2 +1 +1
3 + 1 +1 +2 +1 +1 +1

也就是楼上有人说的那句话，合久必分，分久必合。楼主的领导可能有过度设计的嫌疑，但楼主这种一个大单体的思路其实也有些理想化了——什么项目都经不起变啊，变着变着就要了亲命了，尤其是前端这种没有好的工程化体系的地方（不管 webpack 有多强，vue 多好用，只要还是 js，就注定没有好的工程化的基因）。

当然，我说了也白说，领导最大，木已成舟，估计楼主应该已经吭哧吭哧的做了蛮久了……

[ibegyourpardon]

也是老生常谈的话题了，讲的其实挺没意思的。

说到底啊，这行业的业务变化啊，太快了。。唉，做的累。

[xiaotuzi]

分布式设计，让项目的每个模块可以部署到不同的服务器。

[unco020511]

我看了一遍又一遍，这不就是我们移动端常用的组件化吗

[0xxf]

@flyingghost 老哥，你真是我的知音。独立二级域名，其实就是多个全家桶应用

@green0511 微个鸡儿的服务，其实就是多个 Vue 全家桶项目

@otakustay 你这种情况也是有可能存在的，子项目 A 的模块和子项目 B 的模块的交互。不过你这种情况，为啥列表和表单不做到一起？

@unco020511 不是，组件化不包含业务，我领导这种做法，每个项目都涵盖了业务