Diary

原本只是想稍微整理一下產品圖片的顯示，結果越看越覺得之前的顯示邏輯有點陽春，只有單一圖片顯示，缺乏錯誤處理，用戶體驗實在有點差。畢竟我們的用戶大多是品牌商，他們上傳的產品圖片往往不止一張，光是一張圖真的夠嗎？

今天的重點全都集中在產品分類的 AI 自動化功能上。原本以為只是單純把 OpenAI API 接上去就搞定了，結果一開始測試就發現分類的準確度根本沒達到預期。

這禮拜回頭看來，我彷彿又掉進了自己最熟悉的「重構深淵」：從 API 架構、頭像 URL 快取問題，到訪客帳號的同步邏輯，甚至 FindSkin™ 的命名與使用流程，幾乎每個看似小的任務都牽扯出更大的架構調整。老實說，這種狀況對我來說並不陌生，但每次碰到，心裡還是忍不住吐槽自己：「你真的又在自找麻煩了啦！」😅 但仔細回想，這些重構背後，我其實是在解決一些根本的產品邏輯問題。像是頭像 URL 的 timestamp 參數，原本是為了解決快取，但卻產生了副作用；訪客帳號的暱稱同步，原本只是想快速實作，卻發現會影響整體用戶體驗；FindSkin™ 的命名看似簡單，實際上卻牽涉到 API、資料表與 UX 的一致性。這些問題的根源其實都在於我早期設計時沒有完整考量到未來的使用情境，導致現在要花更多時間修補。這種技術債務，短期內看似沒差，但長期累積下來確實會拖慢產品的發展速度。 這週最大的成就，應該是 FindSkin™ 流程的整理與問卷輸入驗證的強化。雖然一開始有點懷疑 FindSkin™

昨天晚上睡前還在想，FindSkin™ 的介紹區塊到底改得有沒有意義，今天早上起來又是一個新的疑惑：「用戶填問卷的時候，真的會亂填到超出範圍嗎？」雖然內心有個聲音告訴我：「Danny，你是不是又想太多了？」但設計產品時總會忍不住想得更周全一點。

昨天花了一整天整理 FindSkin™ 的命名和流程之後，今天我決定再多花點時間把首頁跟膚質檢測問卷的介紹區塊做得更清楚一點。畢竟昨天睡前我還一直在想：

今天整天都在執著於膚質分析這個功能的命名跟使用體驗，全部統一改成了「FindSkin」。

原本以為新增訪客帳號功能只是「順手」的事，結果今天花了整個上午在 AuthProvider 的邏輯裡來回糾結。昨天還很天真地覺得只要用 localStorage 存個訪客暱稱就好，但一實作才發現，光是處理「訪客帳號是否轉正式帳號」、「訪客暱稱的同步」跟「初始化狀態的顯示」就快把我逼瘋了。

今天原本打算輕鬆一點，先把產品頁面改成 client-side component，畢竟之前 SSR 時效能跟 UX 都有點卡卡的。

這一週的工作成果，老實說成果很不錯，但內心的感受卻是五味雜陳。這週把 Ingrelens 的 API 架構、環境變數管理、會員系統與帳號刪除功能都做了一次全面的整理與升級。從 HTTP 升級到 HTTPS、統一 API endpoint、Dockerfile 和環境變數自動化腳本的建立，一直到會員驗證流程與帳號刪除功能的完整重構，算是把過去半年累積的技術債務一次性還清了不少。 從技術面來看，這次的整理確實讓整個系統的可維護性和擴充性都有顯著提升。尤其是環境變數的自動化管理腳本，雖然一開始寫起來有點痛苦，但現在看來，這個腳本已經成為我部署流程的最佳幫手，未來再也不用擔心手動改錯環境變數而出錯了。再加上 API 統一管理，前端開發體驗也大幅改善，後端的穩定性和安全性也更高了。這些都是這週值得拍拍自己肩膀的地方。 但回頭看，我也發現自己過去幾個月累積了太多「看起來不急」的問題，才導致這週在整理的時候一次爆發，花了大量的時間與精力。像 API endpoint 不一致、URL 寫死在各個 component 裡、會員系統設計初期考慮不夠周全等等，這些技術債務累積下來的成本，

今天一整天幾乎都跟會員系統槓上了。說真的，當初設計 Ingrelens 時，沒想到會員功能會變得這麼複雜。從一開始只是想讓使用者簡單註冊登入，到現在竟然得處理會員資料更新、密碼修改，甚至還要支援 guest 帳號升級成正式會員，整個邏輯複雜度直線飆升。