完美主義者的一跤

在工作上受到肯定之後就會一切太平了嗎？
事實上，並不是的。

被看到，往往就代表會被託付更多困難的責任。
至少這次的我，是這樣遇到的。

在一次 reorg 後，我就接下 Monolithic 到 Microservice 的契機 中提到的 Monolithic Critical Service 重構為 Monorepo + Micro service 的任務。

因為上次的成功案例讓工程師開心、產品開心、公司開心，而我老闆 R 也很開心，於是他接著想把主要的服務也變成 microservices 的模樣，來善用全新的架構帶來的優勢。而我呢，一開始其實是非常抗拒的。只是當時短期內沒辦法離開，所以，雖然內心是「打不過只好加入」，但還是接下來找出路（並不是）。

不過這次的事情沒有這麼順利，可謂一波三折。

我知道自己算是有韌性的工程師，特別在技術正確性及商業價值的取捨上一直是相當有彈性的。這個空間並不是放棄標準，而是會去衡量如何在不偏離工程原則的前提下，用一種更能推進商業目標的方式去前進。當然我還是會試圖佈局，使技術朝向 Best Practice 靠攏，但不是因為我是工程師就只守護技術價值。

但這次我卻跌了一跤，雖然不重但足以警惕自己。

當理想敵不過現實#

回到故事的主角，重構 Critical Service。

故事主角是那個臭又長的 legacy 系統，代碼量龐大、歷史脈絡複雜、邏輯交錯混雜，可以說是技術債一籮筐。

起初我是這樣想的——這是 legacy 包袱最重的一包程式碼。臭又長、充滿歷史脈絡，也代表著終究得面對。所以我試著以技術上的正確性去做拆分，把共用功能中拆出 public interface，而不是直接使用 同一個 instance 操作。

我一開始試著從工程原則出發，以 interface 重構模組邊界，想靠技術手段整理出乾淨的耦合關係。當中我甚至設計了一種理想化的鬆耦合解法，希望改善既有架構下的混用亂象。但說實話，這些做法正確歸正確，卻太理想化。面對大量不一致的使用方式與模組界線，要將這些改造做得乾淨漂亮，需要的不是一季，而是像是另一個重寫。

為了讓 members 也能實踐在前一階段累積的能力，我給了更多自由度，讓他們主導設計與執行，但在某次 OKR retrofit 會議後，大家共同意識到進度卡住，所以我們決定約個會議時間來確認現況跟尋找解法。

這場會議簡單來說是發現我們的問題並不是某件事做得不夠好，而是一次想做太多事。

這個專案從升級框架、JavaScript 轉 TypeScript、調整架構、導入基礎建設、處理部署策略，每項任務都高度耦合，讓專案像陷進了工程沼澤。大家都在努力，也都有 delivery，但卻很難感受到推進交付帶來的成就感，因為總覺得「下一個才能看到成果」。

我也檢討自己。

作為 PO 與 Tech Lead，我希望給予發揮空間，但卻沒設定邊界。時間本身就是一種管理工具，若沒有設好止損點，最初的理想會反過來變成集體消耗。支持與信任很重要，但收斂與聚焦同樣是必要的。

更重要的教訓來自於那個「看起來完美的技術方案」。當初投入太多心力在優雅解法上，卻沒先處理眼前急需解決的問題。我才發現，看懂最佳解固然是一種技術力，但真正讓專案走遠的，是持續交付。懂得什麼時候該放棄優雅，回到現實，我想是資深工作者的成熟。

從理想回到現實#

這場會議之後，我們重新調整優先順序，從「能不能做完」轉向「做出來能不能用」。我們決定先把地基打穩，導入 Monorepo、建立穩定可靠的 CI/CD，搭配清楚的文件與可重複使用的遷移腳本，確保每個人都能站在同一條起跑線上。

更重要的是，在這些調整的過程中，我們逐漸建立出一套可規模化的技術心法：將能被標準化與自動化的流程提前抽象出來，減少決策時間浪費，用一致的方法處理一致的問題。這不只讓交付變快，也讓許多繁瑣細節從手工業轉為可複用的模板工具。

每個階段的交付，也不再只是單純被實作完成，而是真的能被人用，可以被部署、被接手、甚至被寫進 SOP。從小規模、可驗證的顆粒度開始，透過功能拆分與流程導入，穩紮穩打地建立起團隊對架構與交付的信心，也一步步確認基礎建設的穩定性，持續推進拆分後續的服務。

在過程中也保持與第一線產品開發的團隊密切合作，從那邊搜集需求與回饋，調整進度及方向，讓系統的維護與擴展變得更簡單一些。這些調整說穿了不是為了證明能做出來，而是為了回到最一開始的初衷，讓大家工作起來沒那麼難。

最終，這些原則奠定了未來規模化實作的基礎，也讓整體架構具備持續演進的韌性。讓我們順利導入分階段策略，持續穩定拆出服務，並且建立起可維護的 Monorepo 工作流程，也讓不同團隊能無痛接手與參與。這樣的結果不只是單純提升交付效率，也讓組織在調整人力與架構時更加彈性。

所謂的 Staff Engineer#

而我也開始有意識地問自己：「如果今天我離開，這件事還能繼續被做好嗎？」

於是我把原本只在我腦中的判斷標準與邏輯，逐步轉化為明確的 decision log 文件與實作準則，讓團隊可以在沒有我介入的情況下也能對齊決策。在過程中協助 members 熟悉關鍵背景與拆解脈絡，讓知識得以流動、累積，並逐漸從我一個人的專案變成團隊的集體經驗。

真是可喜可賀，從燃燒自己到開始思考如何打造可持續運行的團隊合作，這轉變對我來說無疑是一個巨大的禮物，雖然過程不免痛苦。

這次專案的真正習得，不只是做到我佈局已久的目標，而是我終於理解了一句以前聽了很多次的話。

一群人才能走得遠，從來不是一個自然發生的結果，而是需要經過巧妙設計，刻意經營的。而作為 staff，本來就應該是做這件事情的人，不是那個走得最快的人，而是讓別人也能一起走得久的人。

至於怎麼把這件事每次都做得好，現在的我可能還不知道全貌，但我知道我正在往這個方向慢慢靠近。