優沛團隊成員介紹 [後端] – 投稿者 Jack

我是 Jack，優沛的後端工程師。這篇要介紹的是我們後端這邊的三個人：Bryan、Ben、還有我自己。

我們負責的東西大致上就是 POS 系統背後的那些服務——支付、交易、訂單、結算、排程，這些使用者不會直接看到的部分。產品本身是微服務架構，拆了蠻多獨立的服務出來，三個人就在這些服務之間各自做各自的事情，需要的時候互相配合。

在我們團隊裡，資料庫的 schema 設計大部分是他在規劃的，服務之間的事件要怎麼傳、欄位要長什麼樣子，通常也是他先定好，我們再各自往上疊自己的部分。除此之外他也負責了結算系統、裝置管理的重構、角色權限這些功能。最近這兩週他同時在做批次報表、交易報表強化、序號管理，橫跨五個不同的程式庫在推進。

另外一塊比較不容易被注意到的是他在 CI/CD 上做的事。他在 GitHub Actions 裡接了 AI 自動 code review，也建了資料庫結構自動生成的 pipeline，還有自動打版號、PR 自動留言這些工具。這些不是哪張 ticket 要求他做的，就是他自己覺得能自動化的東西不應該靠人記得去做。不過他對工具的要求也蠻明確的——不是裝上去能跑就好，效果不夠好就先關掉再調。

Bryan 是我們團隊裡 code review 做最多的人，基本上所有 PR 都會經過他。他不太會逐行去挑程式碼風格的問題，但如果你的做法跟既有架構不一致，他會跟你說應該怎麼調。大部分 PR 開出來五到三十分鐘內就會被處理——他對整個系統夠熟，看的時候很快就能判斷這個改動跟既有的東西合不合。

除了技術面之外，Bryan 也會幫忙盯團隊的節奏。環境出問題他會自己去處理，PR 的測試跑失敗了他會主動來追，平常也會提醒行政上的事情或設明確的 deadline。

Ben 是優沛的第一位工程師。中山大學資工系畢業，來優沛之前在醫療科技公司獨立交付過好幾套院所的數位化系統，之後做過一段時間的量化交易策略研發。他手上有 Azure Solution Architect Expert 和 CompTIA Security+ 這些證照，雲端架構和資安這塊也有底子。

因為早期只有他一個工程師，所以系統裡大部分的東西他都碰過。到現在他的守備範圍還是三個人裡面最廣的——退款、作廢、金額計算、收據、外送功能、跨服務的設定同步都是他在顧。最近他在做收據系統的改版（用模板產生 PDF，支援 Email 和 SMS 發送）、還有跟主服務對齊取消訂單的行為、處理商店設定變更的事件推送。

我們的架構是微服務，大部分的時候一個工程師會待在一兩個程式庫裡面做事，但 Ben 經常是一個功能從資料庫、共用元件、到 API 層、到排程服務，五六個程式庫一路做完。退款和作廢的流程重新設計就是這樣——一筆退款從 POS 端發起，經過業務判斷（什麼時候要 void、什麼時候要 refund），到支付閘道的實際操作，再到狀態同步和收據更新，他就是順著這條路從頭走到尾，幾乎是一個人串起來的。

他做 code review 的時候不只看程式碼本身，也會去看資料庫的 migration、比對部署順序，確認這些改動上線之後不會因為部署先後而出問題。碰到生產環境的狀況，他的處理方式是分版推進——先止血、再治本、最後確保穩定，不會一次改一大堆東西。

在群組裡 Ben 平常話不多，但回報進度的時候會列出上週做了什麼、這週預計做什麼、之後還有哪些要處理的，一段話裡把狀態講得很清楚。他也會主動去想開發流程上的事——最近他在群組裡分享了一份從 git flow 遷移到 trunk-based development 的討論文件，請大家有空看看、有想法直接留 comment。

我台大資工畢業，之前在街口支付做支付流程的開發。來到優沛之後剛好也是做支付相關的東西，算是延續了之前的方向，只是從台灣的行動支付換到了美國的信用卡處理。

進優沛之後主要做的事情就是支付閘道整合。第一個是信用卡處理系統，從資料庫結構到 API 介面都是從零開始建的。第二個是第三方支付閘道的串接，同樣是從資料庫一路到 API，橫跨了五個程式庫。除了支付之外，也做了雙價格系統（現金價跟刷卡價的切換）和小費計算這些功能。最近在做的是結算狀態查詢的對接，還有針對測試環境建立 sandbox gateway 的切換機制。

支付的東西比較麻煩的地方在於對正確性的要求很高。一筆交易的金額算錯一分錢就是帳對不上，退款狀態沒更新客戶就會來問。所以每一個變更我都希望有完整的紀錄——每個 PR 會附上改了什麼、為什麼這樣改、影響範圍在哪裡。不過手寫這些東西太花時間，所以我把 Claude 接上了任務管理系統和 Git，讓它根據程式碼變更去生成對應的描述，我再確認內容正不正確。

我卡住的時候習慣在群組裡把問題拆開來寫——限制在哪裡、有哪些可能的方案、各自的取捨是什麼。寫完之後問題的結構通常就清楚了，tag Bryan 讓他確認一下方向就能繼續做。碰到分支衝突或需要決策的時候也是，我會先列幾個選項出來讓對方選，不太喜歡卡在那裡等。

我的工作節奏比較看狀態。好的時候可以一口氣把一整個功能做完，不好的時候就換個方式推進——改去做比較不吃腦力的事情，或者先把文件寫一寫。

個性上我大概是三個人裡面比較會把想法和情緒帶進工作的那個。不是會發脾氣，而是講話的時候比較容易讓人感受到我的狀態。

工作之外我喜歡卡牌遊戲和看漫畫。

我們三個人沒有硬性規定誰負責哪個服務。比較自然的狀況是，你做了某個領域一段時間之後就會變成那塊最熟的人，後續相關的需求也會繼續交給你做，一方面是效率考量，一方面是避免開發衝突。但如果某個人手上的事情太多，也會拆出來分給別人。

一個功能需要跨好幾個服務的情況在我們這裡很常見。以結算功能為例，Bryan 先在資料庫把結構建好、寫了 background job 跟資料處理的邏輯，然後把 Linear issue 交接給我，跟我說：「這個 task 在這，background job 跟資料處理我已經做完，你只要把 TSYS 查詢這段跟如何判斷是 settle 做好就行。」Ben 差不多同時間去更新共用元件和排程端的事件接收。三個人各自推進，不用等彼此做完——前提是一開始的資料結構和介面就定清楚了。

但也不是每個功能都適合這樣拆。有些功能的邏輯從頭到尾是連貫的，一個人做到底反而比較順——像我的支付閘道整合、Ben 的退款流程，都是一個人從資料庫寫到 API 層全部自己來。

溝通的方式很簡單。在 Teams 群組裡貼 PR 連結、附一兩句說明，Bryan 看完就直接合併或者回覆修改建議。不太需要開會討論，大部分的對齊在聊天裡就完成了。偶爾碰到比較複雜的技術問題會直接在聊天室裡一起 debug，不太需要另外約時間。

我覺得我們團隊比較明顯的特點是信任感。PR 開出來通常很快就會被處理，不需要追著人看。生產環境出了問題也不會有人在那邊追究是誰的 code 有 bug，就是趕快修完繼續做事。

我們三個人都有在用 AI 輔助開發，但用的方式不太一樣。

Bryan 把 AI 接進了 CI/CD 流程。他在 GitHub Actions 裡建了自動 AI code review，每個 PR 在人看之前會先過一遍 AI 的檢查，算是多一道自動化的品質把關。裝了之後他會實際測效果，不滿意就先關掉調整，確定品質夠了再重新啟用。

Ben 會用 Cursor 和 Claude 混合著用。他比較偏向先跟 AI 對談，把架構和方案理清楚之後，再讓 AI 協助產出程式碼。

我走的方向是盡量用一個介面做完所有事情。我把 Claude 接上了 Linear（任務管理工具）和 Git，PR 描述、議題查閱和更新這些日常操作都讓 AI 代勞。目標是只透過 Claude Code 這個介面就能完成大部分的開發流程，雖然還在持續調整，但大方向已經跑起來了。

老闆對 AI 工具的投資也很支持，基本上覺得有幫助的工具都可以申請。我們之間也不時會交流各自的用法，聊聊最近發現了什麼好用的新功能之類的。

如果你對優沛的後端開發有興趣，歡迎跟我們聊聊！