《軟體工程師記》EP.2: 街口支付

前言

上週 LinkedIn 突然跳出了通知，寫著 "OOO, liked your work anniversary". 回想起來，從加入公司到現在已經滿一年了，這個過程充滿著幸運，也許值得記錄一下。

如果還沒有看過第一篇，可以先看看 《軟體工程師記》EP.1: 從零到一。

這一年我學到了什麼

回想剛進公司的自己，還只是個只做過幾個簡單作品、對真正的軟體工程與團隊協作毫無概念的菜鳥，當時的蠢樣至今仍歷歷在目，雖然一年又過去了，看起來好像也沒好到哪去（？）。

新創公司的迭代速度非常快，往往沒有太多時間能手把手地帶新人。加入團隊不久，我便接下了人生中第一個專案。這段經歷迫使我快速成長，也讓我學到很多。非常感謝當時願意信任我的主管，以及這個充滿挑戰的環境。

一年下來，我陸續參與了四個項目，雖然規模都不算大，但要在有限的時程內完成，對當時還什麼都不太懂的我來說壓力山大。為了趕進度，我幾乎天天加班，差點就睡在公司了。而以下是我總結出來的心得:

技術

模組化 UI 元件

剛進公司的時候，我在 UI 開發這部分非常不適應。進公司之前，我從來沒有接觸過「元件複用」或「CSS-in-JS」的概念，更沒聽過 Storybook 協助開發與測試的好用工具。記得第一次和後端同事討論 API 資料格式時，光是看到他回傳的變數名稱和我預想放進元件參數的名稱不一樣，就讓我當場慌了，還跑去問主管：「這樣我要怎麼辦？」

畢竟以前做作品都是自己開 API 自己接，沒合作與標準流程，更別說團隊協作了。老實說，那時候我真的有點搞不清楚自己來幹嘛的 🫥。

一年後，我參與了元件庫的建置，從一開始四、五個共用元件，慢慢累積到二十多個。在這個過程中我學到，一個好用又能被重複使用的元件，不只是把畫面做出來而已，而是需要和設計師充分溝通，了解設計的邏輯和實際的使用情境，在拿到最終設計稿後，寫出一個既有彈性又能延伸使用的元件，並根據實際使用的情況進一步優化。

React & Redux

目前專案的技術棧都是用 React + Redux，一開始根本不知道同一個元件底下 React.useEffect 可以放多個，也不知道 Custom Hooks 是什麼東西。

還記得開發第一個專案的時候，因為對這些概念一無所知，乾脆就把所有東西都塞在同一個檔案裡 從 UI、邏輯到資料處理通通混在一起，最後整個檔案超過上千行，完全失控。這份程式碼在被主管審閱後，就被宣告無法使用了，被主管要求全部重寫，也拖累到主管假日跟我一起加班 Q_Q。

一年後，我逐漸掌握了 React 的各種 API，也開始在開發過程中思考效能與架構設計。像是會評估某段邏輯是否有必要使用 React.useMemo 或 React.useCallback 來優化；也會在撰寫時注意元件的重新渲染行為，讓程式更乾淨可控。

此外，我也開始熟悉如何使用 React + Redux 搭配 Formik 與 Yup 來處理複雜、多頁的表單流程，包含表單驗證、資料管理與錯誤提示等細節，讓整體用戶體驗更順暢。

目前則是負責的遷移舊的 MPA 專案到 SPA，也讓我更深刻體會到當一個平台逐漸擴展時，所需要的抽象化與模組化設計能力，如何在靈活性與可維護性取得平衡，是我現在特別關注與學習的方向。

程式碼品質

以前寫程式只求「能動就好」，完全沒有程式設計的典範概念。現在回頭看自己幾個月前寫的程式碼，就會覺得非常痛苦，副作用滿天飛、命名混亂、可讀性差、幾乎沒辦法擴充。

現在則是努力將一個函式可以讓審閱程式碼的人在幾秒內看懂，開始使用函數式編程的概念，減少程式的副作用，訓練自己的抽象化能力，讓程式可以複用以及擴充。

也在部分專案中導入測試流程，實踐過 TDD（Test-Driven Development）與 BDD（Behavior-Driven Development）。這樣做的好處是：能在開發前就先釐清產品需求與使用流程，同時也能避免自己寫出一些基本錯誤的 bug，當程式進入測試階段時也能更有信心。

產品開發流程

軟體開發中，任何一方的延遲都可能導致整體時程延宕，而這對前端特別明顯，因為我們極度依賴設計與後端的交付。如果大家都壓線交付，最後承壓的一定是前端。那麼，當我們看完開發文件後，設計圖還沒定稿、API 也尚未完成時，該怎麼辦？前端總不能等所有條件就緒後才開始開發，那一定來不及交測。

面對設計圖未定的情況，我會先根據已知需求產出所有頁面結構與基本 User Flow，並與專案經理反覆確認流程是否符合預期，快速調整方向。如果有導入 BDD，可以先把 feature spec 與專案經理對一次，並同步實作初版頁面版型，讓整體流程有個清晰雛形。

至於 API 尚未完成時，我會主動與後端工程師討論是否能先提供初版 API 文件。只要有規格，我就可以使用 Mock Service Worker（MSW）進行 API 模擬，這樣至少能模擬頁面基本的操作、後端回傳格式，甚至預演錯誤情境的處理。

通常等這些初步工作都完成後，實際設計圖與後端 mock API 也會陸續就緒，這時就能迅速補上剩餘邏輯與細節，並盡快上到測試環境進行自測，確保整體流程順利推進。

溝通技巧

良好的溝通能大幅減少開發過程中與其他團隊之間的認知落差，對時程掌控與需求對齊都非常關鍵。例如：

• 與專案經理溝通時，需要清楚爭取合理的開發時間，並確認功能是否真的是他們所預期的樣子，避免開發方向走偏。
• 與設計師協作時，要討論元件設計的可行性，理解設計背後的邏輯，並確認我們實作出來的 UI 是否能滿足他們對細節的期待。
• 與後端或移動端串接時，則需要釐清 API 或 WebView 函式的定義與整合方式，確保兩端對接順暢。
• 向主管彙報專案進度時，要能簡潔清楚地說明目前的進展、遇到的問題、解法，以及團隊討論後決定採行的策略。

這些情境都需要不斷地溝通與協調，才能達成雙方都滿意的結果。直到現在，我仍在學習如何在這些協作中更有效率、更有同理心地傳遞資訊。希望未來能更加從容地處理各種溝通挑戰，讓每一次合作都更順利。

結語

一年前加入這間公司時，公司的網頁前端團隊還處於草創階段，只有我跟主管。組內的開發文化都還尚未成形，從專案的開發到 Nginx 建置與專案的發佈都是弄髒自己的雙手去摸索出來的。這過程會踩到無數多個坑也犯過無數個錯，前期壓力或許稍大，又或許沒有所謂的休假日，但當問題是由自己的雙手解決時，心裡的成就感真的是無法言喻。也感謝主管以及各組的同事們，總是願意回答我無知且基礎的問題。到現在網頁前端團隊已經有五位成員了，而且同事們個個都是高手！