小白接手前端專案
轉眼間轉職也快滿一年了，想分享一下這一年來維護舊專案的心得！
軟體工程師一定會碰到沒有文件或註解的專案，如果商業邏輯繁重、過多的 workaround、沒有測試等等 ，蠻有可能一改就爆炸。
這時需要先分析現況，擬定短、中、長期的解決方案，但是否有時間分析，也會受限於公司給你多少時間處理手上的問題！短期盡量先以熟悉專案為主，之後再處理效能、架構的改善或是複雜議題。
短期
以前端來說，我認為短期可以聚焦在使用者操作直接相關的部分，包含：
- 操作回饋：給予使用者操作成功或失敗的提示
- 等待回饋：進度條、讀取動畫、按鈕禁用
- 頁面跳轉：閃爍、路由守衛、錯誤頁面、重載機制
- 點擊防禦：針對負載較重的功能設計防抖、節流、狀態鎖
- 樣式：如果有設計系統，通常不用去動它，主要處理一些樣式不一致的問題
這些功能都集中在展示層 (presentational)，也是最容易改動的，不涉及太多資料管理，好改就會立竿見影。
中期
處理過展示層後就能更快辨認 issue 類型是偏向展示層還是邏輯層 (container)。
邏輯層通常涉及比較多外部資料的整合，必須先梳理好資料流才能進行改善，例如我在工作上常遇到的案例有：
- 重複打出 API
- 多個頁面依賴同個 API 資料
- 狀態管理器將 UI 狀態跟資料狀態包在一起
這階段偏向資料流與邏輯邊界的重構，搭配防抖和節流，可以預防很多效能問題。
但「正確地」梳理不是簡單的事，如果能夠初步區分出展示層與邏輯層，相信勝過毫無準則地濫用工具。
資訊
展示層與邏輯層的概念可以參考：Container/Presentational Pattern
長期
現職 9 個月以來，我持續在做：
- 寫註解：補了一些比較難懂的 side effect，註記各個元件的功能
- 導入 TypeScript：但也就是先導入，至少讓新功能可以跟進 TS
- 改善專案架構：東西雖然不是非常難找，但缺乏一些分類準則，目前持續參考 FSD、原子設計等等的架構，用破壞性最小的方式慢慢改善`
- 導入單元測試： 針對資料重組或新加入的函式去測，我也沒有寫測試的經驗，所以後續還要研究元件的測試
- 可讀性改善：Code Spell Checker 先裝上去再說 XD 我會一塊一塊讀程式碼，所以看到很多黏在一起沒有空行，實在蠻痛苦的
接下來也預計嘗試我在培訓時期還沒有做過的事，像是整合測試、E2E 測試等等。
升版本要做比較縝密的手動測試，雖然專案可以 build 成功，但不能保證完全沒有地方壞掉！所以還是要好好評估升級後有多少餘力可以馬上處理掉沒測到的問題。
祝大家寫 code 快樂 🤣