记 两个星期只修一个配置
事情是这样的,我在半个月前收到了组里大哥分配的一个“小任务”——修改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了,然后一个组长和我说,把代码重构一下吧(带着原有的远古代码一起)。。。。。