我的前端工程師之旅 (二)

前言

上週 LinkedIn 突然跳出了通知，寫著 "OOO, liked your work anniversary". 回想起來，從開始寫第一段程式到當工程師一周年，這個過程充滿著幸運，也許值得記錄一下。

如果還沒有看過第一篇，可以先看看 我的前端工程師之旅 (一)。

這一年我學到了什麼

當一個只有做過 Toy Side Project，不知道實際的軟體工程跟協作流程是什麼的我，當初進到公司的蠢樣還是歷歷在目，雖然現在好像也是(?)，而在新創公司的現實就是沒有太多時間培養新人，所以進到公司沒多久我就開始經手我人生的第一個專案，也因此這樣讓我成長不少，感謝這個環境以及當初主管給我這個機會。 一年下來，經手了四個項目，雖然規模並不大，但要在有限的時程做完，讓什麼都不太懂得我，在前期瘋狂加班，只差沒睡公司而已。

而以下是我總結出來的心得:

技術

UI 工程

UI 工程這部份讓我在剛進公司時，整個適應不良。在還沒有進公司前，我完全沒有元件複用跟 CSS-in-JS 的概念，也不知道 Storybook 這個好用的套件。甚至當後端跟我討論 API 格式的時候，看到他回傳變數名稱跟我預期放到元件的參數名稱不一樣時一整個驚慌，還問主管這樣我要怎麼辦。因為當初寫 Side Project 的時候都是自己開自己接。完全不知道自己來是幹嘛的 XD。

一年後，我參與了 UI Library 的建置，從一開始四、五個左右的共用元件到現在有二十多個。瞭解到一個好用的元件，是需要跟設計師不斷溝通，並在得到最終設計圖後寫出一個可以複用並且有彈性的 UI 元件，再根據實際應用後，進行調整而產生出來的。 當頁面有的類似 UI 元件時，直接從 UI Library 引入，就不用再做重複的事情。可以更專注在程式可讀性，可維護以及效能身上。

React & Redux

目前專案的技術棧都是用 React + Redux，一開始根本不知道同一個元件底下 React.useEffect 可以放多個，也不知道 Custom Hook 是什麼東西。依稀記得第一個專案開發時，因為一點概念都沒有，反正就是寫在同一個檔案拉，塞好塞滿。使一個檔案 UI 加邏輯破千行。這份程式碼在 code review 後，就被燒毀了 XD. 被主管要求全部重寫，也拖累到主管假日跟我一起加班 Q_Q。

一年後，我慢慢可以掌握 React 的各個 API，也開始會在開發時想如何優化，思考這段程式碼有沒有貴到要包 React.useMemo 或 React.useCallback。以及如何用 React + Redux + Formik + Yup 處理複雜且多頁表單及表單資料的驗證。目前手中的重構專案，則是讓我知道一個平台建立時，其所需要的抽象化能力。

Code Quality

以前寫的程式總是讓它能動就好，沒有 Clean Code 的概念，讓我現在回頭看自己以前的程式碼，總是百般痛苦。各種 Side Effect、命名、可讀性以及擴充性問題等。

現在則是努力將一個函式可以讓 Code Review 的人在 10 秒內看懂，運用 Functional Programming 的概念，減少程式的 Side Effect ，訓練自己的抽象化能力，讓程式可以複用以及擴充。

也在部分專案導入測試，實踐方式有用過 TDD 跟 BDD， 好處是會在開發前先思考過產品需求與使用流程以及避免自己寫出一些低級的 Bug，讓當程式提測時更有信心。

產品開發流程

以前端來說任何一方的 blocking 都可能讓前端的開發時程延宕。當看完開發文件後，設計圖還沒有定版以及後端 API 還沒出時應該怎麼辦？前端總不能等到他們都完成後才開始動工，這樣一定會來不及交測。

以設計圖還沒定版這方面，我們可以先把所有的頁面檔案以及 User Flow 都先產出來，並同時跟 PM 確認是不是他們所預期的，若不是就快速做修正。這裡如果有做 BDD 測試的話，可以把 BDD 的 feature 跟 PM 對過一次，以及把頁面 Layout 大概實作出來。

在後端 API 還沒給我們時，可以跟後端工程師討論一下，是否可以先給 API 文件 ，接下來就可以用 Mock Service Worker (MSW) 進行 API 的 Mock，這部分至少可以做到 CRUD 的 mock, server response 的 refine 以及模擬各種錯誤情境。

通常在這些等做完時，後端 mock API 跟設計圖會在差不多時間給前端，這時就可以很快的將之前尚未預期的功能及需求補齊。並且快速上到測試環境做自測。

溝通技巧

一個好的溝通可以讓開發時減少與他方預期的落差，例如，

如何跟 PM 爭取足夠的開發時間以及功能是不是跟 PM 預期的一樣。

如何跟設計師討論某元件設計的可行性、以及這樣做是否達到設計師所預期的樣子。

如何跟後端或 Mobile Team 溝通 API 或 Webview 函式的串接。

如何跟主管清楚的匯報自己目前經手專案的進度，事情的解決方法或是事情討論出來後的決定實行的方案。

這些都是需要不斷的溝通跟協商，才可以達到雙方都滿意的結果。直到現在我依然在學習，希望有一天可以迎刃有餘的處理這些問題。

結語

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