當重構像多米諾骨牌：從小修到整體優化的一週
延續昨天的 AI 整合反思，我原本只想讓產品分析結果更好讀。沒想到下去動了一個顯示細節，整個渲染邏輯就像多米諾骨牌一樣一路倒下：從前端元件、狀態流到資料處理方式，都被迫重新梳理。雖然頭疼，但結果讓我滿意。
先從「觀察互動」著手。我加了一個專門顯示成分的區塊，原本擔心資訊太細，使用者不一定在意，但測試下來，這一層補充反而讓分析更完整、點擊更少。順勢把整頁重構一輪，告別以前那種直接堆原始 JSON 的做法，資料管線變得順暢許多。commit 的時候我自嘲：「Danny，你以為加個屬性顯示就好？結果還是得把渲染邏輯全部理一遍，免得狀態打結。」好在錯誤率降了 25%，至少沒有再重演昨天的 CORS 驚魂。
後端我延續安全檢查的思路，改了 API 和資料庫的幾個環節。新增了不帶參數的產品建立與清單路由，讓系統自動處理預設值，不必每次請求都塞一堆冗餘資料。這個改動讓錯誤請求少了約三成，也減輕前端在弱網環境下的負擔。同時加上重複產品檢查與原始 SN 的取得邏輯，解掉之前條碼重複的麻煩。過程中我也踩到坑：一開始忽略資料庫遷移的相容性，熱門度追蹤加進去後舊資料出現異常，只好回頭調整遷移策略。整理完，安全檢查多了成分評估的步驟，AI 的建議更可靠，效能也跟著提了上來。
前端錯誤體驗這塊，我把「圖片上傳一直轉圈圈」的問題徹底解決。原本後端錯誤訊息都有，但前端沒接，使用者只能乾等。如今加了明確的錯誤提示元件，失敗時能清楚告知原因，這種小改動帶來的體感提升其實很直接。
品牌管理 API 是另一個深水區。本來只有基本 CRUD，資料一多，前端載入就拖泥帶水。我索性補上搜尋、分頁與排序，並用 PostgreSQL 的 pg_trgm 做模糊搜尋。做的時候我也自問：「品牌管理值得花這麼多時間嗎？」想想未來品項與資料源會擴張，這層彈性遲早要有，趁現在整理比事後救火好。
重構過程順便發現 OCR 放錯地方。產品名稱的 OCR 一直掛在條碼掃描端點，導致每次掃碼都跑 OCR，明明多數情況不需要。我把它移到分析端點，只有在需要分析成分時才啟動；掃碼端點則加強格式驗證，避免資料庫被奇怪的 barcode 汙染。為了驗證成效，我寫了針對身體乳液類型圖片的測試腳本，畢竟這類產品的成分標示通常比較複雜。準確度的提升得靠後續校正，但基礎骨架先打好，未來才好迭代。
如果把這週拉成一條時間線，大概可以叫做：從混亂中找平衡的技術拉鋸戰。幾個感觸：
- 產品設計與技術決策的連動比想像中大。API 的結構不只為 CRUD，而是要預留第三方資料、成分分析、推薦系統的串接空間，才能減少未來重構的痛。這次的取捨雖花時間，但回頭看是值得的。
- 有些地方的確有過度工程化的影子。像條碼唯一性的雙重保險（API 層檢查加上資料庫 unique constraint），或許只留一層就夠，這部分會再觀察真實使用再決定該不該下修。
- Emotion 的 CacheProvider 重構解了 SSR 樣式閃爍、效能也更好，但我也學到不能只盯著技術理想，還是要回到使用者體感。技術完美和實際需求之間，永遠要留一條線。
- 「小優化變成大重構」是這週的常態。我問自己最多的一句話是：「這樣做真的有必要嗎？」很多時候沿著小問題往下挖，就會翻到過去趕進度留下的技術債。下次要更有節制，別把時間全花在債務清理，忘了產品真正需要的功能。
整體來說，這週的進度符合預期。雖然重構佔了不少時間，但基礎架構、可維護性與體驗都有明顯提升，對 IngreLens 的長期發展是正面投入。
下週（2025/03/31–2025/04/06）我打算聚焦三件事：
- 品牌與產品資訊 API 的整合與優化：趁著品牌 API 已經整理，進一步把產品資訊整合進來，降低前端負擔，讓資料結構更清晰。
- 產品分析結果的視覺化與互動：在分析邏輯已重構的基礎上，透過 framer-motion、intersection observer 等工具，讓呈現更直覺，互動更自然。
- 技術債的系統化管理：建立清單，明確優先順序與評估標準，避免隨機清債，讓每次投入都對產品價值有貢獻。
避免再陷入哲學辯論，我會提前與團隊對齊，收集外部意見；在視覺化上，也提醒自己別為了炫技堆動畫，最終指標還是使用者是否看懂、是否願意用。簡單說：手癢可以，但要癢在該癢的地方。
這一週的起伏讓我更踏實。從猶豫到成就感，中間靠的是一次次把細節對齊的耐心。IngreLens 又往前走了一步，接下來繼續把「價值」放在前面，技術跟在後面。
