背景
我于今年7月加入现在的公司。 记录在公司做过的后端代码优化。 如果您也遇到了同样的问题，希望可以帮到您，也可以在评论区交流。
搭建私服后台
我刚进公司的时候，前端已经有私服了，但是后端还没有私服。
后端有业务组件库，经常使用的组件会转移到gitLab仓库。 当需要新功能或错误修复时，需要先构建它们，然后拖入项目中
问题
引入麻烦。组件库更新时，只能本地构建后才能加载到依赖包中
没有版本的概念，只能使用最新的代码。 如果发生破坏性修改，后果不堪设想
提升
搭建私人服务器。 你可以阅读我的另一篇关于后端私服verdaccio的介绍和使用的文章[1]
构建工具（webpack）优化背景
刚来公司的时候，问老员工如何启动后端项目（自己安装后，npmrunserve）启动了，调用socket不成功
老员工发给我一个nginx安装包
图片.png
这个是来做什么的？ 我去面对面交流。 原来在启动项目时，需要在本地启动一个nginx，进行socket转发。
当时我就在想这家公司用的是什么中间功能。 webpack的devserver中是否有无法实现的转发？ 算了，我跑到跟前问道。
后来看了nginx的配置，直接把socket全部转发了，然后加了一个devserver就解决了。
解决了之后其他后端开发也都聊到了。 我知道这很简单，而且我很久以前就做到了。 。 。
image.png 启动时间优化背景
一个后端项目已经迭代了3年多了（上面的一些功能也是外包的，而且代码杂乱多），非常庞大，可以说是一个巨石项目，而且启动时间达到120秒左右（node_modules场景下还有缓存（不是第一次启动），如果使用公司配置的window笔记本的话需要5分钟
再次测试
图片.png
直接看优化后的效果图
你没看错，比优化前多了50秒，你可能有这个疑问（我知道你很着急，也不着急，请继续往上看）
第二次开始
第三次开始
原则
HardSourceWebpackPlugin 是一个 webpack 插件，为模块提供中间缓存步骤。 简单来说，它会将一些文件缓存到你的node_modules中。
缓存的目录是node_modules/.cache/hard-source。
在解决的过程中，我也尝试了很多webpack插件（多线程打包、happyPack等没有明显效果），目前测试的只有这个hard-source-webpack-plugin[2]最有效率
HardSourceWebpackPlugin文档[3]列出了您可能遇到的一些问题以及解决方法，例如热更新失败，或者个别配置不生效等。
用法
安装依赖项
复制代码
npm install hard-source-webpack-plugin -D
更改 webpack 配置：
ini
复制代码
//webpack.config.js
var HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
module.exports = {
//...
plugins: [
new HardSourceWebpackPlugin()
]
}
打包时间优化背景
依然是里面的巨石项目，启动时间2分钟左右（公司发的台式电脑5分钟），项目使用vuecli，打包时间20多分钟，但是Jenkins经常构建失败，并且打包命令需要添加最大Memory限制。
css
复制代码
node --max_old_space_size=8192 node_modules/@vue/cli-service/bin/vue-cli-service.js build
我问我的朋友为什么花了这么长时间才建立这个项目。 上网的时候怎么操作呢？
朋友也很真诚的回答我：我们几个人同时打包后端，然后玩王者荣耀。 谁打包得快，谁就用他笔记本电脑上做的包。 。 。
在这种情况下，仍然存在一个问题。 如果个人笔记本的nodejs版本不同，或者有人忘记拉取最新的代码，都会导致发布失败。 和个人的关系太密切了。 我们应该越来越信任机器。 使用jekins进行打包
结果
包装时间从20多分钟优化至5分钟。
优化
添加了一个配置项，这样就不用单独提取css了。
image.png解决过程
虽然相比之前只增加了一行代码，但花了大半天的时间才找出真正的原因。
首先找出插件和加载器的持续时间。 检查持续时间。 speed-measure-webpack-plugin插件可以检测每个插件和加载器所花费的时间。
如何使用门户[4]
测试后没有发现有用的数据
想想启动哪个开发环境花了5分钟，怎么打包花了20多分钟。 （想想打包时默认没有启用sourceMap和eslint，按理说应该更快，然而却更慢），
该项目使用vuecli（3.5.3）。 vuecli 对 webpack 中的默认值做了一些改变吗？ 然后一一检查配置，看看哪些是启用用于生产的，哪些是不启用用于开发的。
找了很久也没找到合适的。 曾经想升级vuecli到5，但是又怕一系列组件依赖都要升级。 项目稳定性不够好，所以继续寻找。
终于，我找到了嫌疑人。 经过测试，我发现创建时间确实会缩短。
图片.png
推测该项目是一个巨石应用，代码量过多，因此拆分css生成单独文件的时间过长。 开发环境的这个参数默认是关闭的，所以启动时间是5分钟，打包时间是打开这个参数时拆分css，会写入大量的文件，所以很慢。
代码优化图标库优化[5]下载体验优化后台
项目中有一个学习课程的功能，需要有下载功能。 目前的流程是前端返回文件流，后端将文件流转换为链接然后下载。
600M的视频大约需要1-2分钟的加载时间。 目前在下载过程中加入了加载，导致用户在这2分钟内无法进行操作，极大影响了用户体验。
问：为什么我不能直接使用window.location.href？
答：视频课程存储ID。 前端有一个单独的服务是文件服务，需要网段信令。 当前信令放置在请求的标头中。
目标
预计就像从软件官网下载文件一样，调用浏览器的默认下载，如右图，不会影响用户的操作。
image.png 已解决
查了一些资料，location.href或者window.open都可以实现这些效果，以及如何用token解决问题。
我想到将令牌存储在 cookie 中。 当用户发起请求时，默认会带回来。 前端可以扩展下载接口，支持从cookie中获取。
优化前的 Jekins 优化
image.png 优化
image.png-背景
团队人员反映，Jenkins后端项目每次打包时，nodejs都会占满服务器显存，导致打包排队。 我们看看是否可以减少显存。
每次都需要安装。 您只能像本地更新一样更新新安装的软件包。
还有一个很大的原因是前端帮忙写打包脚本。 前端不理解后端的封装，后端不理解封装脚本，导致中间信息出现断层。
提升
我自己也不懂Jenkins，所以只能自学。 我之前的公司是由专业的运维团队管理的，有点尴尬。
查了官方文档和打包脚本脸皮厚了之后，还是又问了一遍前端，渐渐明白了。我找到了每次打包都要deleteDir()的原因。 查看官方解释清理工作空间。 我想知道是否是这个原因。
图片.png
删除这个脚本后，发现每次都比较快。每次清空工作空间后，再次执行该脚本时，安装都要从0开始，导致对c盘的读写。 这样就解决了占用CPU并且每次都从头安装的问题。
此时有两种情况需要考虑：
当引入新的依赖项时，它们会安装成功吗？
当依赖升级时拆分css，能否升级成功？
测试过程中没有发现问题
包装流水线优化
以前，npminstall 和 npmrunbuild 被统一到管道 ProtalNpmBuild 中。 不方便统计是安装包慢还是npmrunbuild慢。
提升
将npminstall和npmrunbuild分开，将.npmrc（.npmrc中指定的仓库指定为私服仓库）提交到仓库（这样安装时会优先从私服安装）
打包产品可以下载
群里的成员希望在发布到生产时直接从测试环境下载压缩包并更新到生产环境。
查看官方文档[6]，成功时将压缩包上传到服务器。
yaml
复制代码
archiveArtifacts artifacts: 'dist/*.tar.gz', fingerprint: true结论
我是林三鑫，一名热心的后端程序员新手。 如果你有动力，喜欢后端，想学习后端，以后我们可以做同学，一起钓鱼。 哈哈，鱼群，跟我来，我拉你进群，有5000多个后端男等着一起。 学习-->
模拟笔试、简历指导、入职指导、项目指导、问答都可以私信我~我已经帮助100+同事完成装修了！
