週檢討：從混亂中找平衡的技術拉鋸戰

# 當你以為踩完了坑，回頭卻發現已經挖出一片戰場😅 — Ingrelens 週檢討：2025-03-30

這一週真的是讓我大開眼界，原本以為只是單純做些功能調整和優化，沒想到一個坑接著一個坑，最後竟然發現自己站在一座技術債的金字塔上。從產品管理 API 的哲學辯論，到條碼掃描功能的坑，再到前端 Emotion 重構、圖片上傳流程優化，甚至產品分析邏輯的重寫，這一週真的是把 Ingrelens 從前端到後端都好好地整理了一番。

說真的，這週最大的收穫並不是完成了多少功能，而是我更清楚地意識到，「產品設計」和「技術決策」之間的連動影響比我之前想像的要大上許多。之前總覺得只要功能能跑，使用者用起來順暢就好，但當我開始認真去思考未來的擴展性和產品的策略定位時，才發現許多技術決策背後都需要更深入的產品思維。

例如產品管理 API 的結構，原本只是 CRUD 功能，但當我考慮到未來可能串接第三方資料庫、成分分析和推薦系統時，API 的設計就必須更具彈性，才能避免未來重構的痛苦。這次的哲學辯論雖然讓我多花了一些時間，但事後回頭看，這個決定絕對是正確的。至少現在的 API 結構能讓未來的擴展更順暢，也能減少系統整體的複雜性。

不過，我也必須承認，這週有些決策的確還是有點過度工程化。像是條碼掃描的唯一性檢查，雖然我加了雙重保險，但仔細想想，或許 API 層的檢查已經足夠，資料庫的 unique constraint 是不是有點多餘呢？這點未來還要再觀察一下，看看實際使用情形再做調整。

Emotion CacheProvider 的重構也是類似的情況。雖然 SSR 樣式閃爍問題的確解決了，效能也提升了，但當初評估時我應該再更仔細衡量一下實際使用者的感受，而不是單純為了追求技術上的完美。畢竟，技術的理想狀態和使用者真正的需求之間，有時候還是會有落差，這點值得我繼續反思。

另外一個重複出現的問題就是「小優化變成大重構」。這週我最常問自己的問題就是：「Danny，你這樣做真的有必要嗎？」很多時候只是想稍微調整一下邏輯或是元件結構，結果就一路挖到最底層，發現之前趕進度留下的技術債。這讓我意識到，未來的開發過程中，我必須更嚴格地控制自己對重構的衝動，否則很容易陷入無止盡的技術債清理，影響到產品真正重要的功能開發。

整體而言，這週的進度其實還算符合預期，雖然多花了一些時間在重構和技術債清理上，但整個產品的基礎架構和可維護性都有了明顯的提升，這對 Ingrelens 的長期發展絕對是正面的。

下週（2025-03-31 到 2025-04-06）我的重點工作會更聚焦在以下幾個方面：

1. **品牌與產品資訊 API 的整合與優化**：這週因為圖片上傳問題而重寫了品牌 API，這是個好機會，順便把產品資訊和品牌資訊的 API 整合起來，降低前端的負擔，也讓資料結構更清晰。

2. **產品分析結果視覺化與使用者體驗提升**：雖然這週已經重構了分析邏輯，但視覺化和使用者互動上還有很大的優化空間。下週的目標是透過 framer-motion 和 intersection observer 等工具，讓分析結果更直覺、更具互動性，提升使用者的體驗價值。

3. **技術債的有系統管理**：這週讓我意識到，技術債的清理不能只是隨機發生，必須要有一個更清晰的策略和優先順序。下週我會建立一個更完整的技術債管理清單，將問題優先級明確列出，未來更有系統地處理。

當然，下週預期還是會遇到一些挑戰，特別是在 API 整合與資料結構的設計上，可能會再次陷入「哲學辯論」。

為了避免這種情況，我會提前與團隊討論，收集更多外部意見，避免自己陷入無止盡的自我懷疑。同時在視覺化的優化上，也要注意不要過度追求動畫效果，而忽略了實際使用者需求，這點我必須隨時提醒自己：「Danny，別再手癢了，使用者體驗才是真正的王道啦！」

總之，下週的 Ingrelens 還有很多值得期待的進展，繼續加油吧！