这是一个创建于 1200 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司目前有一老旧的前端项目（ 5 年前开发）
采用的是 webpack2 + vue2 构建的，而且还是个多页应用（历史原因 不知道为什么，其实是一个平台项目，一个团队维护）
每个 pages 都是一个 spa，导致 build 会全量 build，随着几年的埋坑和堆屎。项目越来越大。
预计有 45 个 pages 目录，每个目录下有 10 个路由页面。
现在每次更改项目 热更新 都要几十秒才生效，构建不用说要 15 分钟左右（相当于 45 个项目 build ）
我的想法：
1. 升级构建工具
2. 分析 build 慢的原因(webpack 分析工具)，逐步解决，抽离 dll 什么的。
3. 按照目录结构(45 个 pages)，一个一个目录优化代码，去掉无效的引用，冗余代码等等……
4. 改成 dev 和 build 都只启动和编译修改的 pages 。
其中关于 4，我有点尴尬。因为这些 pages 内部的组件有都交叉引用的。在不重构的方式下，我修改一个组件。不知道哪些 pages 引用了。。。这样重新 build 不知道 build 哪些 pages 。。。
还有个想法是，改成 spa，一个目录一个目录的慢慢整理，就是相当于重构了。时间成本比较大。
不知道我的思路是否正确。特来请教前端大佬们~~~~感谢~~~~
打算搞成 kpi 项目。如果大佬们的意见采纳，最后拿到奖金了，绝对来发红包。。。\(^o^)/~
---
补充：前后端分离项目。想搞成 spa 的原因是我们的用户访问量并不是很大（日均 2000 ip ），体验想搞好点。
采用的是 webpack2 + vue2 构建的，而且还是个多页应用（历史原因 不知道为什么，其实是一个平台项目，一个团队维护）
每个 pages 都是一个 spa，导致 build 会全量 build，随着几年的埋坑和堆屎。项目越来越大。
预计有 45 个 pages 目录，每个目录下有 10 个路由页面。
现在每次更改项目 热更新 都要几十秒才生效，构建不用说要 15 分钟左右（相当于 45 个项目 build ）
我的想法：
1. 升级构建工具
2. 分析 build 慢的原因(webpack 分析工具)，逐步解决，抽离 dll 什么的。
3. 按照目录结构(45 个 pages)，一个一个目录优化代码，去掉无效的引用，冗余代码等等……
4. 改成 dev 和 build 都只启动和编译修改的 pages 。
其中关于 4，我有点尴尬。因为这些 pages 内部的组件有都交叉引用的。在不重构的方式下，我修改一个组件。不知道哪些 pages 引用了。。。这样重新 build 不知道 build 哪些 pages 。。。
还有个想法是，改成 spa，一个目录一个目录的慢慢整理，就是相当于重构了。时间成本比较大。
不知道我的思路是否正确。特来请教前端大佬们~~~~感谢~~~~
打算搞成 kpi 项目。如果大佬们的意见采纳，最后拿到奖金了，绝对来发红包。。。\(^o^)/~
---
补充：前后端分离项目。想搞成 spa 的原因是我们的用户访问量并不是很大（日均 2000 ip ），体验想搞好点。
 |
1
renmu123 2021-07-26 19:09:25 +08:00 via Android
又不是不能用.jpg 。
可以每个 page 单独进行 build 上传到一个总的打包目录，最后上传打包目录。 这样一可以避免修改全局配置 二可以快速热更新 也可以用 webpack 单独 watch 一个 page |
 |
2
slert 2021-07-26 20:02:34 +08:00
有什么老板能感知的好处吗 不要反而改出很多问题得不偿失
|
 |
3
liuxu 2021-07-26 20:11:19 +08:00
换开发机，上 amd 5950x+1t sn850 ssd+64G 3733Mhz 内存
|
 |
4
JerryCha 2021-07-26 22:04:17 +08:00
先 3 后 4，汇报的时候着重阐述编译构建的效率导致的开发效率问题。
|
 |
5
mostkia 2021-07-26 22:11:15 +08:00  1
确保整个屎山垮塌后能够有足够技术实力和办事速度，确保能够兜底的情况下再搞，注意备份，实在不行回滚。说实话这种事情吃力不讨好，改得快又好，老板可能觉得我上我也行，改的不好，磨磨蹭蹭，人家就觉得你技术不行还逞强，因为领导一般是不懂技术的，人家只会觉得项目跑的好好的，你个二愣子一上来就要改，那改就改吧，期望值就高起来了，如果没有肉眼可见的明显优化，人家可能完全不认可你的辛苦工作
|
 |
6
jiyinyiyong 2021-07-26 22:43:57 +08:00
老项目麻烦的地方, 你永远不知道以前为了赶进度插入过什么奇怪的功能, 特别是复杂的项目, 说不定正常的修改也因为历史原因有个什么奇怪的设定, 改了就跪了. 先从影响范围小的开始改吧.
Vite 试一试, 虽然我估计大概率是换不了的. |
 |
7
mongodb 2021-07-26 22:57:40 +08:00 4
不管你觉得动手多难，其实按我动屎山的经验，交叉关联再多的东西，总归可以从一个函数来起，逐步迁移，小范围折腾。 务必保证每次修改的原子性（这里的原子指的是尽可能的影响小，越小越好），然后修改个半个月下来，其实发现也还好。
但小伙子你听我一言。对这种前端项目，你第一个要动的可能不是上手动已有组件。而是去看看 package.json 里引用的第三方包，是不是有些有坑。最好逐个去看完，一些可以从外部依赖改成放到本地 vendor 的，就放到本地。 安内必先攘外。 对外部第三方的组件和模块引用，不把它摸个门清，你后面会发现左右为难，有的动也不是不动也不是。 新开发的时候大量依赖外部组件是个多快好省的方法，但时候差不多的话，就得把它本地化，改成自己的。然后你才能放心的去愚公移屎…… |
|
8
mongodb 2021-07-26 23:00:30 +08:00
还有我有个习惯就是，老旧项目会尝试在动结构之前，把包依赖在可以的情况下升级版本…… 优先级比动代码本身高。
有的时候是换了就不能跑，但也得折腾。 这事很重要。 升级到新版本，你才有足够好用的工具来继续往下折腾。 尽可能选兼容性高的方案来升级，让自己可进可退。 |
 |
9
ianva 2021-07-26 23:18:19 +08:00
还是要重构，用 mono repo 的方式重构项目结构
1. mono repo 的方式把所有的组件抽出作为一个项目，另外把所有的 SPA 作为单独的项目，因为是 mono repo 本身也很方便引用 2. 增量编译，既然做城了 mono repo，增量编译和启动就会很简单了，发布的时候写个脚本判断下文件变更在哪个子项目然后编译相应的文件 3. 建立脚手架用于新增 SPA 项目 |
 |
10
akira 2021-07-26 23:53:06 +08:00
预计有 45 个 pages 目录，每个目录下有 10 个路由页面。
现在每次更改项目 热更新 都要几十秒才生效，构建不用说要 15 分钟左右（相当于 45 个项目 build ） 这 2 个都不是问题啊。。 开发成本 维护成本 那些才是问题 |
 |
11
statumer 2021-07-27 00:25:13 +08:00 via Android
个人看法，当务之急是修改 webpack 编译配置，项目本身没啥问题
|
 |
12
dayeye2006199 2021-07-27 05:10:35 +08:00
试试 https://github.com/lerna/lerna 这种管理子项目的工具？感觉合理的拆分和构建工具，应该可以带来构建时间的降低
|
 |
13
wd 2021-07-27 07:24:48 +08:00 via iPhone
日均 2000 的项目，你搞到天上去也就那样了。你不如去找找有没有更好的项目。
|
 |
14
lneoi 2021-07-27 08:59:14 +08:00
webpack 版本那么老，先把 webpack 升级把，然后构建优化下，打包速度肯定能提升。但这个对用户感知比较低，只是提升开发体验
|
 |
15
karott7 2021-07-27 09:20:04 +08:00
访问量才 2000，就别动业务代码了，升级 webpack 配置和依赖吧
|
 |
16
james2013 2021-07-27 10:47:10 +08:00
真佩服敢去重构老旧代码
以前我也一腔热血想重构某个老旧项目 改了比较少一部分就没有改了,因为代码没有说明文档,有些地方也没有注释,容易出问题,改好了是份内的事情,出了不少问题就背锅 |
 |
17
cw2k13as 2021-07-27 11:22:21 +08:00
别动他了吧，放到服务器去打包
|
 |
18
chenmobuys 2021-07-27 11:37:21 +08:00
什么都不要动，要不然之后你会甩你自己两嘴巴子
|
 |
19
meloncc 2021-07-27 12:01:21 +08:00 1
渐进式的升级，旧代码别动，在旧项目新增一个子系统，通过路径访问子系统，升级一个模块替换一个模块，升级完成后，就可以把子系统独立出来，一个完整的新系统，个人认为这种方式是最好的，连系统的技术栈也可以重现选择。
|
 |
20
LastStarDust 2021-07-28 10:24:19 +08:00
这个项目有点大，不是很建议（耗时和风险），我说下之前重新升级老项目的过程吧，可以先开一个分支，把 webpack 配置改为 vue-cli 方式，降低配置难度，在把一些公共代码做下抽取，这时应该会有一定的提升了，你这个刚开始可以考虑把 2-3pages 先坐下合并，渐进式的查看是否有问题
|
Select Language