带团队后的日常思考(十三)

一、日常问题

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

不压缩的行为是与常规优化手段背道而驰的,但是现在比较符合我们组的场景,还是那句老话,鱼和熊掌不可兼得。