重構永遠不是「只是改一下」的事 🤦‍♂️

今天原本打算輕鬆一點，先把產品頁面改成 client-side component，畢竟之前 SSR 時效能跟 UX 都有點卡卡的。但我果然又低估了自己的龜毛程度。當我開始處理 loading state 跟 error handling 時，發現原本的 API 設計根本沒考慮到這些場景。結果呢？整個 API 又被我重整了一輪。你一定會想問：「Danny，真的有必要連 API 都動到嗎？用戶真的會 care 嗎？」但我心裡很清楚，這種小地方不處理乾淨，之後一定會回頭咬我一口。

最痛苦的是，我明明前幾天才整理完頭像的 URL 邏輯，今天居然又發現了之前為了避免快取問題加的 timestamp 參數，其實根本是個坑。原本以為 timestamp 能解決快取，但實際上卻讓圖片 URL 每次都不一樣，反而破壞了瀏覽器快取的好處。最後我索性直接移除這個參數，改成上傳或刪除頭像時主動重置預覽 URL，這樣用戶看到的頭像更新就會更即時、更順暢。順手還把顏色生成函數給優化了一下，避免一些顏色組合看起來太詭異（之前測試時碰到一個奇葩的橘綠色組合，我差點吐血 🤢）。

下午實作產品評分與評論功能時，又碰到了一個讓我猶豫不決的點：到底要不要讓訪客也能留下評論？一開始直覺覺得應該開放給所有人，能增加互動，但思考了一下後端的 spam 處理機制跟用戶認證的複雜性，又猶豫了起來。最後決定先保守一點，暫時只讓已登入的會員留下評論，未來視情況再調整。這種決定總是讓我自我懷疑：「Danny，你這樣是不是錯失了用戶互動的機會？」但目前來說，先把 spam 跟認證邏輯穩住應該比較重要吧。

順便提一下，今天在 profile 頁面新增了 secondaryTypographyProps 來調整字體顯示效果，原本只是個小小的 UI 調整，結果又被我一路改到 AuthProvider 的 useMemo 去了。你一定會問：「Danny，這兩件事到底有什麼關聯？你這樣是不是強迫症發作？」其實也不是啦，只是發現 contextValue 每次 render 都重建一次，效能上不太理想，順手就包了一下 useMemo，算是個小優化吧。

今天還做了一件很療癒的小功能：裁剪頭像時新增了原始圖片預覽狀態。之前用戶裁剪完圖片就沒辦法回到最初的狀態，這點一直讓我很在意。今天終於抽空把這個功能補上，順便把裁剪、縮放、旋轉狀態也重置了，這樣用戶就能隨時回到原點重新裁剪。測試時自己玩得很開心，甚至一度忘記了自己是在 debug 😂

最後，今天也狠心刪了一堆過時的文件跟 API 文檔。這種清理過程總是很掙扎，畢竟每份文件都是自己曾經花了不少時間寫出來的。但想想這些文件放著不更新，只會增加未來維護的負擔，還是決定果斷一點。果然，刪完之後文件結構變得清爽多了，心情也跟著輕鬆不少。

雖然今天又在各種細節裡糾結不斷，但回頭看這些決定跟重構，應該還是值得的吧？至少下次再回頭看這段程式碼時，不會忍不住吐槽自己：「Danny，你當初到底在想什麼？」😅