接手現有的前端專案時可以做什麼
· 閱讀時間約 5 分鐘
轉眼間轉職也快滿一年了，想分享一下這一年來維護舊專案的心得！
接手一份缺乏文件或註解的專案，可能是個人人都有機會歷經的噩夢，
因為很難馬上理解這些 magic number 的含意或整體的設計意圖，
怕隨意改動程式就造成破壞。
我們可以先分析 issue 類型，制定短、中、長期的解決方案，
短期以熟悉專案為主，而不要「大量」重構現有的業務邏輯，
因為有可能不小心刪減到某些功能，或者新加入的邏輯和原本的衝突了。
短期
以前端來說，我認為短期可以聚焦在使用者體驗相關的部分，包涵：
- 操作回饋：如 CRUD 操作後給予使用者的提示、表單輸入格式錯誤的提示
- 等待回饋：如進度條、讀取動畫、按鈕禁用、骨架讀取
- 畫面跳轉：如閃爍、路由守衛、錯誤頁面、重載 機制
- 防抖：如表單提交、報表匯入匯出
- 樣式：各種你想得到的 CSS 數值沒設好導致的問題
這些都是集中在展示層（presentational）的功能，
也是最容易改動的，因為不會涉及太多資料管理，
因為好改、立竿見影，可以拿來衝績效（喂
中期
修過專案內的展示層之後能更快辨認 issue 類型是偏向展示層還是邏輯層（container）。
邏輯層就需要介入比較多 API 串接的過程，
必須先梳理好資料流才能進行優化，我在工作上最常遇到的就是：
- 重複打出 API
- 多個頁面依賴同個 API 資料
- 狀態管理器的使用時機不明確，UI 狀態跟資料狀態沒有分離
- 精彩的 legacy
防抖和節流能在短期解決一部分使用者意外操作造成的效能消耗，
這階段會偏向資料流與邏輯邊界的優化但「正確地」梳理資料流不是容易的事，
如果能夠簡單地區分出展示層 / 邏輯層，相信勝過毫無準則地濫用工具。
長期
現職 9 個月以來，我持續在做：
- 補註解：補了一些我覺得很難懂的 side effect 或是 utils 的執行目的，註記各個元件的功能
- 導入 TypeScript：但也就是先導入，畢竟一千多支 js 檔不可能突然改好 XD
- 改善專案架構：原本的架構其實就是 vite 建起來的那樣，很扁平，東西 不會太難找，但就算撇開內聚性，也還是缺乏一些分類準則，目前持續參考 FSD、模組化、原子設計等等的架構，思考破壞性最小的優化
- 導入單元測試：針對一些 formatter 或新加入的函式去測，我也沒有寫測試的經驗，所以後續還要研究元件、狀態管理器的測試
- 可讀性改善：Code Spell Checker 先裝上去再說。我會一行一行讀程式碼，所以看到很多邏輯黏在一起沒有空行，實在蠻痛苦的
接下來也會持續嘗試我在培訓時期還沒有做過的事，
像是整合測試、E2E 測試等等...
升版本要做比較縝密的測試，雖然自己有拷貝一份來升升看，
似乎沒什麼大問題，就是一些寫法已經被標記 deprecated，所以必須換掉，
而不是單純 build 有成功就好，我可以確定一定有蠻多我沒測出來的問題。
因為是商轉中的專案，自己也蠻怕升一升就壞了 XD 不過如果能慢慢把測試補上來，應該就可以考慮升版本了！
祝大家寫 code 快樂 🤣