從零建起整個後端（上）
本篇是「我的職涯地圖：一個工程師的 20 年回顧」系列的第 7 / 12 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
2018 年八月，帶著剛出生不久的女兒和一段在直播公司的記憶，我走進了一家美商醫療器材公司的辦公室。
這是一家美國醫療器材公司，做的是可攜式心電圖（ECG）設備。把複雜的醫療設備小型化，讓醫生和病患可以在醫院之外也能做心電圖檢測。硬體團隊已經做了好幾年，但軟體這邊——特別是後端——幾乎是一片空白。
他們需要一個人從零開始建構整個後端系統。
而那個人，就是我。
第一個月：從零到一
「到職第一個月就完成 API 規劃與開發」——這句話寫在我的履歷上，看起來很輕描淡寫。但背後的壓力和強度，只有親身經歷過才知道。
我是團隊裡的第一位 Backend & DevOps 工程師。沒有前人留下的程式碼可以參考，沒有既有的架構可以沿用，甚至連要用什麼技術棧都需要我自己決定。
我選擇了最熟悉也最有信心的組合：PHP + Laravel 作為後端框架——在 KKBOX 和接案累積的深厚經驗讓我對 Laravel 的生態系統了然於胸。
但其他的技術選擇就不是「用熟的就好」了，而是根據醫療場景的需求做的判斷。
Protocol Buffers（protobuf）取代 JSON 做資料序列化。一般的 Web API 用 JSON 傳資料已經夠用了，但心電圖設備每秒會產生大量的波形數據點，JSON 的文字格式既佔頻寬又慢。Protobuf 是 Google 開發的二進位序列化格式，同樣的資料量可以壓到 JSON 的三分之一大小，解析速度快好幾倍，而且有嚴格的型別定義——在醫療數據傳輸中，「少傳一個欄位」或「型別搞錯」是不能接受的。
Redis 做快取和 Message Queue——心電圖數據從設備傳上來後不是馬上處理，而是先放進佇列，後端再按順序取出來分析，確保在大量數據湧入時系統不會崩潰。
Docker 做開發環境的容器化，確保「在我的電腦上能跑」等於「在正式環境也能跑」。Kubernetes 部署到 GCP 的 GKE（Google Kubernetes Engine）——GKE 是 Google 代管的 Kubernetes 服務，你不用自己管 Kubernetes 的控制平面，專注在你的應用就好。選 GCP 是因為它在醫療合規方面的支援比較完整。
第一個月，我完成了 Restful API 的規劃與開發，供 Client-side 的 APP 和 Web 介面串接。同時開發了第一版的後台 Dashboard (Web Portal)，讓 to B 和 to C 的客戶都能使用。
回想那個月，每天的工作節奏大概是這樣：早上規劃架構和 API 設計，下午寫程式，晚上測試和修 bug。沒有人可以問，所有的技術決策都是我一個人做的。但也因為沒有歷史包袱，我可以用最乾淨的方式從頭搭建，每一個決定都是深思熟慮後的結果。
制定 Deployment Flow
系統開發只是一半的工作，另一半是確保這個系統能夠穩定地部署和運行。
我花了不少時間評估和與主管討論各種 Deployment Flow 的優缺點。最後制定了一套適合我們團隊規模和產品特性的部署流程：從開發環境到測試環境到正式環境，每一步都有明確的檢查點和回滾方案。
對於一家醫療器材公司來說，部署流程的嚴謹程度跟一般網路公司完全不同。你的系統如果出了問題，影響的不是使用者看不到某張圖片，而是醫生可能收到錯誤的心電圖數據。這個壓力讓我在設計每一個環節的時候都格外謹慎。
醫療軟體的不同
在那家公司工作，最大的不同是你時刻意識到自己寫的程式碼和「人命」有關。
一般的網路服務出了 bug，最糟的結果是使用者體驗不好、公司損失一些營收。但醫療軟體出了 bug，可能影響到醫生的診斷判讀。這種責任感讓我養成了一個很強的習慣：每一行程式碼都要經過仔細的思考，每一個 API 的回傳都要確保資料的正確性。
這也是我開始認真看待測試的時期。在之前的工作中，我知道測試很重要，也上過 91 哥的 TDD 課程。但在那家公司，測試從「應該做的事」變成了「不得不做的事」。Unit Test、BDD、API Testing——每一種測試都有它存在的理由，而且在醫療領域，這些理由格外充分。
一個人的後端世界
在那家公司的前兩年，後端基本上就是我一個人的世界。
所有的 API 設計、資料庫架構、部署流程、監控機制、效能優化——全部都是我一個人做。這聽起來很辛苦，但也有一個好處：我對整個系統有完整的理解，從第一行程式碼到最後一個部署設定，每一個細節我都清楚。
當你對一個系統有這種程度的理解時，解決問題的速度會非常快。線上出了 bug，我通常能在幾分鐘內定位問題，因為整個系統就是我設計的，我知道資料會從哪裡進來、經過哪些處理、最後從哪裡出去。
這段「一個人撐起後端」的經歷，也讓我深刻體會到文件化的重要性。當所有的知識都在你一個人的腦袋裡，如果你哪天突然不在了，整個後端就成了一個黑箱。所以我很早就開始寫技術文件，不只是給未來的同事看，也是給未來的自己看。
埋下成長的種子
公司的前兩年，是我職涯中最純粹的「技術打底」時期。沒有管理的壓力、沒有跨部門的政治、沒有KPI的焦慮。就是一個工程師和他的系統，安靜地把每一塊磚頭砌好。
我不知道的是，這些扎實的基礎，正在為接下來的故事做準備——從工程師到研發處長的蛻變，以及更多意想不到的挑戰。
那是下半場的故事。
