2021-08-24

记 两个星期只修一个配置

事情是这样的，我在半个月前收到了组里大哥分配的一个“小任务”——修改webpack配置，让生成的webpack离线包小一点。因为整个项目的代码量太大了，而用webpack打包时有一些不必要的代码混在其中，这些代码增大了生成离线包的体积，导致项目代码提交不上去（提交的时候对包大小有限制）。

第一次接触

因为我之前在学校的专业是计算机科学与技术专业，再加上自己不是很勤快，大学前三年对前端的理解与认识还停留在简单的HTML+CSS的阶段，在来到前端岗位之后，才第一次听说还有webpack这东西。而就在我还没有来的急细细理解webpack，我就接到了这个任务。我第一天去B站找了一个两个多小时的webpack5速成课视频学习了一下，还很认真的记了笔记.

但是第二天我边上的同事告诉我，我们项目创建的相对早一些，用的都是webpack4的技术，此时我的内心一万头草泥马奔腾而过，让我再拿一天出来细细学习webpack4我觉得有些不现实（当时确实有些急功近利），虽然我知道webpack4与webpack5之间一定有一些特性是不同的，但是我还是决定头铁，摸着石头过河，边写边试。

而我也真就是初生牛犊不怕虎，不知道天高地厚，现实给了我无情的一拳，让我认清了什么tmd是前端。我打算仿照国际化的配置经验，从package.json中script内的命令开始进行逆向工程，去解构整个项目的配置，但是整个项目的结构之庞大，调用之复杂，完全超乎了我的预料。也许是我工程能力确实有欠缺，我在研究了三天webpack配置之后，尝试了各种插件的使用（我还从csdn上自己掏钱花了九块大洋买了一个plugin），发现在不同的位置写入插件会有不同的效果，有的时候是插件调用的太早了，有的时候则是调用的太晚了，但就是找不到一个合适的调用时机。走投无路了，我抱了一个公司里的大腿，我之前在公司内网的论坛上看到过他写的一篇webpack优化打包的文章，洋洋洒洒，讲的清晰生动，我向大佬请教了一番之后，大佬过了一天之后告诉我，他自己尝试着也写了一个脚本，但是我们的代码运行不到他写的脚本，大佬也觉得过于复杂。

走投无路

整了四天的webpack，回到原点，这块硬骨头总不能啃了四天之后不啃了，和导师说整不动对吧？那摆在面前的只有一个不优雅的办法，就是在webpack打包结束之后调用node的API来完成一个强行的删除。于是我很不优雅的加上了两个函数，完成了删除操作。第一周也就此结束。

暴雷

我本来以为这就算完了，但是谁知道恐惧才刚刚开始。前一天晚上合入master，第二天早上大家就发现，新拉下来的master代码都不能运行了（这里指的是在生产网络中不能在web上正常运行），由于缺乏经验，我并不知道在前端开发环境下启动的本地代码只包括src文件夹下的代码，实际上我之前写的那些配置文件代码根本就跑不到，因而我在自己跑过之后，觉得一切正常，就真的觉得没问题了，从而导致了问题的出现。

排雷

出现问题之后，首先要做的便是复现问题，我将我的代码部署到生产环境之后，我在本地成功复现了白屏页面的bug，我打开F12，看到了network里一长串的404，仿佛我的心在滴血。我当时怎么也想不通，我就删了五个js文件，怎么会有这么多404（这些404都不是我之前删掉的那些资源）。因而，我对着代码冥思苦想，也想不明白。后来在一位前辈的提醒下，我才知道，流水线中可以看发布单详情（即打包产出的资源详情），我在仔细对比之后，我发现网页请求的资源url与我产出资源的url不一致，多了几个字母；然而这一信息并没有什么卵用，因为我做的操作都是删除资源的操作，根本就没改过文件路径，我还是想不明白，debug再一次陷入僵局。一天之后，在另一位前辈的提醒下，我才知道，原来流水线中的编译模块也可以点进去看详情。。。在编译详情中，我发现一个回调被执行了两次，这又触及了我的知识盲区；同时还有另一个问题，就是在编译时出现了路径错误的提示，这两个情况在一起出现，我觉得这一问题有些微妙，于是我决定更改script逻辑，将删除操作分离出来，只对指定的路径进行删除，这才解决了问题。

总结

这个故事告诉我们，我还太年轻，还需要多历练，开发工作还是需要多多积累经验，如果没有经验就要多多的尝试，敢于试错，敢于面对。

、、、事实远比上边的叙述曲折复杂的多，本人文笔不好，没能写出当时内心的绝望和孤独、、、

后记

终于写完了代码，可以CR了，然后一个组长和我说，把代码重构一下吧（带着原有的远古代码一起）。。。。。