一、日常问题
1)你为什么不连数据库
最近遇到个站内信的需求,在页面中有个发送账号的选择框,现在要新增两个官方账号。
于是我就根据需求,让产品提供相关信息,然后产品说服务端也维护着一套官方账号,为什么不连数据库或不调他们的接口,而是写死。
在一端维护数据源,理论上是比较理想的处理方式,但是目前会有几个问题。
首先,服务端需要参与进来,提供账号接口,那么开发就变成多端,然后需要两端都抽出时间。
其次,改成接口调用后,会改变原先的逻辑,那么就需要 QA 介入,这时就需要三端都抽出时间来。
再有,官方账号不会频繁变动,维护成本也就不会很大。
一个原本可以几分钟完成的需求,变成多端协作才能实现,我是觉得大大增加了开发成本,得到的收益却并不高。
还有就是公司的服务端和 QA 资源非常紧张,难以马上抽身到这个并不算非常紧急的需求,开发周期会被拉长,可能要几周几个月后才能完成。
那就非常影响业务方的体验了,所以在和产品辩论时,我比较坚持当前的实现方案。
在日常开发中,经常需要做取舍,平衡出在当前环境中收益比较大的方案。
2)裁员
9 月底公司 APP 因某些原因惨遭下架,直接影响到了公司营收,公司三分之二的用户是 iOS。
而 iOS 下架后,就无法支付,并且不能连续包月扣款,虽然在国庆前紧急上架了 H5 网页版的支付,但是营收还是少了些。
国庆上来后,公司管理层立刻就调整了大方向,将重点转移到了另一个项目组,而我们这边的技术部就要瘦身。
整个技术部裁掉了一半的人,十月中旬的一天,早上还在认真的改需求,下午就逐个谈话,谈完后,大家心情都很糟糕。
活也干不了了,都没有状态了,赔偿款还是蛮爽气的,都给足了。
接下来就是工作的交接,交接分为两块。第一块是记录还未发线上的代码分支,并且配上注意事项。
第二块,就是常用功能的文档说明,例如榜单活动的页面和接口代码,在各自写完后,进行 Code Review。
对有疑问、有歧义的位置当场提问,也帮他们理解代码意图。
对于团队组员的离开,还是不舍的,期间又进行了两次聚餐,自己团队一次,和隔壁团队一次。
10 月份找工作,还是挺麻烦的,不太好找。
自己根据这些年的招聘经验,对他们的简历,也给了许多改进的意见,希望他们能尽快找到合适的工作。
其实我只想安静的打份工而已,但现在人员减少,未来看来会比较忙,我不想卷,公司的同僚应该和我是一个想法。
二、工作优化
1)Ant Design 升级
公司目前使用的 Ant Design 版本还是 3 年前的 3.X 版本,为了体验更好的性能、以及有价值的新功能、新组件,我决定做升级。
目前最新的是 5.X 版本,由于跨了一个版本,所以需要先升级到 4.X 版本。
一开始还挺忐忑的,不过在使用官方的工具后,自动就修改了几百个文件。
还贴心的提供了兼容库,可以使用在 4.X 中废弃的组件,改造成本并不高。
随后就是些零零散散的修改,诸如样式、表格宽度等,组内验收后,打算放到预发环境,让业务人员验收 2 天。
不过,都没怎么看预发环境的页面,我们团队内的人将自己负责的比较重要的页面都看了下,修复了些问题。
有些样式问题都比较好处理,有个比较麻烦的问题是,在 Modal 组件中无法自动展开 Select 组件的选项。
最后查了 ChatGPT,说给两个属性赋值,才实现了自动展开。
还有些组件渲染出的 HTML 元素与之前不同,而导致了布局问题。
2 天后正式上线,又陆陆续续的收到了些问题反馈,好在之前准备充分,没有出现致命性影响工作的问题。
2)管理后台发布优化
管理后台的发布一直很慢,前段时间对后台的页面做了剪枝,减少了将近 100 张页面。
但是发布时间收效甚微,仍然比较慢,基本上都要 9 分钟以上,甚至 10 多分钟。
其中构建时间占了比较大的比重,在 5~6 分钟之间。执行查看包结构的命令后,就能展示产物的依赖占比。
ANALYZE=1 umi build
于是想到了 splitChunks 策略,将依赖的大库单独拆分到一个脚本中。
export default { dynamicImport: {}, chunks: ['vendors', 'umi'], chainWebpack: function (config, { webpack }) { config.merge({ optimization: { splitChunks: { chunks: 'all', minSize: 30000, minChunks: 3, automaticNameDelimiter: '.', cacheGroups: { vendor: { name: 'vendors', test({ resource }) { return /[/]node_modules[/]/.test(resource); }, priority: 10, }, 服务器托管网 }, }, } }); }, }
加上配置后,生成了 vendors.js 和 umi.js(umi 框架的版本是 3.5),以及各个页面的脚本,原先所有的脚本都打包在 umi.js 中。
dist/vendors.744fbc30.async.js 5.6 MB 1.5 MB dist/umi.783bf8b4.js 2.9 MB 614.1 KB dist/p__live__report__chatAudit.4b06356 2.async.js 1.3 MB 366.6 KB dist/p__live__liveMonitorDetail__.a7a89995.async.js 1.2 MB 348.8 KB dist/p__live__liveList__.22ebbc8服务器托管网6.async .js 1.2 MB 347.4 KB
从发布的时间看,并没有降低多少。接下来是减少浏览器补丁的尺寸,由于后台都是本公司使用,所以浏览器版本可控,就配的高点。
export default { targets: { chrome: 79, firefox: false, safari: false, edge: false, ios: false, }, }
发布时间变化不大,但是 umi.js 降低了 0.7M 左右。
最后看到一条优化策略是不压缩脚本,由于是内部使用,即使不压缩应该也不会有什么大问题。
COMPRESS=none umi build
执行不压缩的命令后,发布时间明显变少,能维持在 6.5 分钟,并且构建时间缩短到了 3~4 分钟,但是脚本明显变大了。
dist/vendors.782e42a9.async.js 14.6 MB 2.7 MB dist/umi.8acb3c22.js 6.4 MB 1.2 MB dist/p__live__report__chatAudit.928e7ae1.async.js 1.5 MB 390.8 KB dist/p__live__liveMonitorDetail__.876c5 322.async.js 3.7 MB 731.9 KB dist/p__live__liveList__.2d7339aa .async.js 2.1 MB 399.5 KB
不压缩的行为是与常规优化手段背道而驰的,但是现在比较符合我们组的场景,还是那句老话,鱼和熊掌不可兼得。
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
机房租用,北京机房租用,IDC机房托管, http://www.fwqtg.net
目录 前言 题目 编辑 核心代码 总结 前言 我是歌谣 我有个兄弟 巅峰的时候排名c站总榜19 叫前端小歌谣 曾经我花了三年的时间创作了他 现在我要用五年的时间超越他 今天又是接近兄弟的一天人生难免坎坷 大不了从头再来 歌谣的意志是永恒的 放弃很容易 但是坚持…