一、日常问题
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__.22ebbc86.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
不压缩的行为是与常规优化手段背道而驰的，但是现在比较符合我们组的场景，还是那句老话，鱼和熊掌不可兼得。
posted on
