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