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

[0xxf]

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

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

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

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

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

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

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

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

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

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

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

我说，好的好的。

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

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

[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]

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

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