框架升級不順的背後

你有負責過公司主要服務的底層軟體——像是應用層的框架升級需求嗎？

如果有的話，一般都是什麼時候開始的呢？
是在剛釋出消息時就啟動研究，還是等到穩定版本後才動手？

我想對多數軟體工程師來說，都明白維持框架版本更新的必要性。除了提升 DX，還能同步避免潛在安全問題，而我們也都知道這些理由很難直接拿來當成提案的核心論點。

從興奮到焦慮的落差#

那時候公司的 Web 服務主要採用 Nuxt 作為應用層的框架，而 Nuxt 3 還在 beta 階段時，剛好手頭不是這麼忙的情況下，我的老闆 R 就問我有沒有興趣做一下前期研究，因此我就投入了前期探索。

坦白說我很喜歡做研究這件事情，在過程就是從陌生的題材把它理解透徹並且找到如何切入公司現況的方式說服利害關係人開案執行，而那時我也正想試試剛從 Sr. Staff Engineer V 身上學到的幾招。

在做了初步的研究，也實作了 PoC（概念驗證）之後，結果卻讓我的熱情冷下來——改的範圍實在太大，風險過高，而且過程會持續進版，根本難以管控一個妥當的時間切分。
半個月的投入帶來成就感，就此轉變為焦慮，因為我交不出一個可落地的方案。

這時候你會怎麼做呢？是雙手一攤的跟老闆說目前無解？還是繼續垂死掙扎？
又或者你有更好的方法，那恐怕就不會落到我這個田地了（笑）

我一直都相信自己不會是團隊中最優秀的人，但是我應該是數一數二有耐心的人，包含對於找到結果這件事情。所以我帶著些許沮喪找
R
分享研究成果，讓他理解看來難以直接落地的研究結果，但我還是希望將這些研究轉化為團隊共識與未來的可行方向，所以我想再找時間安排
team meeting 來確定方向。

工程師不愛沒效率的會議我很清楚，但這次不同，這是一場關鍵決策的會議。

我定義「好的會議」為——能收斂共識並產出未來的行動項目。既然議題橫跨微服務、升級路徑等特定主題，所以在會議通知中就附上了建議閱讀的會議資料，同時我也做好準備面對各種情境，例如同事沒時間事前閱讀，我該如何在會議中三言兩語補足關鍵的資訊。

這場會議進行得比預期熱烈，也許是因為這不只單純與技術有關，還影響著每個人未來半年內的工作走向。而鮮少開超過
10 人會議的我，在這次中收穫最大的是如何在當下整合想法、聚焦討論。

更重要的是我也從這裡學會，不要停在問題的本身，要學著看見背後的可能。

最終我們都想以風險可控的方式進行，畢竟我們都想活得輕鬆一點，也需要以對公司來說不那麼有風險的方式讓軟體變得更有韌性，於是大家就取得了團隊共識：

先讓服務可切分，再談升級。

而我則成了後續專案的 owner，歡呼吧！
如果事情就這麼簡單，就不會值得我一字一句地寫下來了。

在軟體工程層面，我們希望朝這個方向推進；但對公司而言，是否要投入人力，還得回到商業價值，很現實但非常實際。所以我從當時公司 Q1–Q2 的營運目標「擴大使用者」切入，以效能優化來提案。

接續我沿著這個角度再 PoC 了一個主要流量的頁面，驗證某個頁面若獨立成服務，效能是否能夠提升。同時，也著手儲備微前端相關的研究，包含產品切分策略、code sharing、專案架構等等。

這個 PoC 的關鍵指標是效能——可惜的是當前服務底層耦合過重，不大動刀就無法顯著提升效能。而當前專案的 DX 也讓人難以兼顧兩者，最後此案我只能以建議暫緩執行作收。

你想我就荒廢了這個專案的目標嗎？
絕對不可能的，那樣就不是我會做的事情了。（笑）

當時的我把整個事件重新想過一輪，如果我的真正目標是降低服務長期風險，那就不應只看升級與否，更應該思考架構彈性。

那時候在腦中浮現第一個方案，是建立 monorepo 的開發流程。

為什麼呢？

因為主要的專案中有大量共用元件、共用邏輯需要維護。拆成多個 repos 在理想狀況下看似有彈性，但我過去就曾見過 UI repo 與應用層 repo 分離導致的雙邊 out-of-sync 問題，維護反而更痛苦。

然而當時團隊尚未具備 micro frontend 或 monorepo 經驗，要推動的話自然也不會是一蹴可幾的事情，因此這個方向在接續的提案中被擱置一旁。

如果在這樣的情況下，你會覺得沮喪嗎？
那面對這樣的沮喪，你會怎麼做呢？

我一開始感受到的，是一種無能為力的感受，是那種「我已經做了這麼多，卻什麼都推不動」的挫敗，讓我懷疑自己及環境。卡在這樣的狀態中沒多久，我想這樣的自我否定，只會讓我停在原地，我需要找到可以行動的方向。

既然短期內無法推動 microservice，那麼在現有條件下，還有什麼是我可以為微前端這個長期方向先做的？深入檢視團隊的技術現況後，我決定從 codebase 的整體品質 下手，針對共享邏輯、架構設計、與微前端的潛在切入點，一步步提出改進方案，朝目標逐步接近。

也正因為這樣的轉念，我的沮喪沒有變成結果，而是在接下來的兩年中，逐一見證這些可能性被實作為具體的專案成果。

這次讓我理解：沒有不能解決的問題。

勇敢面對所謂的失敗，願意正視目前無法成功的事實，也就有機會讓它成為另一段可能的起點。

我當時只是想讓自己好過一點，卻沒想到這樣的動念帶我踏上了真正的 staff 之路，開始為團隊的工程文化創造改變，成為文化推動者的一份子。