一、日常問題
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
不壓縮的行爲是與常規優化手段背道而馳的，但是現在比較符合我們組的場景，還是那句老話，魚和熊掌不可兼得。