API 重構之後的省思：從技術債務到產品決策的自我檢視 🔧🚧

這一週的工作成果，老實說成果很不錯，但內心的感受卻是五味雜陳。這週把 Ingrelens 的 API 架構、環境變數管理、會員系統與帳號刪除功能都做了一次全面的整理與升級。從 HTTP 升級到 HTTPS、統一 API endpoint、Dockerfile 和環境變數自動化腳本的建立，一直到會員驗證流程與帳號刪除功能的完整重構，算是把過去半年累積的技術債務一次性還清了不少。

從技術面來看，這次的整理確實讓整個系統的可維護性和擴充性都有顯著提升。尤其是環境變數的自動化管理腳本，雖然一開始寫起來有點痛苦，但現在看來，這個腳本已經成為我部署流程的最佳幫手，未來再也不用擔心手動改錯環境變數而出錯了。再加上 API 統一管理，前端開發體驗也大幅改善，後端的穩定性和安全性也更高了。這些都是這週值得拍拍自己肩膀的地方。

但回頭看，我也發現自己過去幾個月累積了太多「看起來不急」的問題，才導致這週在整理的時候一次爆發，花了大量的時間與精力。像 API endpoint 不一致、URL 寫死在各個 component 裡、會員系統設計初期考慮不夠周全等等，這些技術債務累積下來的成本，其實比想像中更高。這也提醒我，未來在每次開發新功能時，務必要更有紀律地評估與處理技術債務，避免再次陷入這種一次性清理的困境。

這週另一個重要的省思點，是在產品決策的戰略思考上。回想起來，最初設計 Ingrelens 時，我沒有預期會員功能會變得如此複雜，導致後續擴充時頻頻撞牆。這其實是對產品發展路徑的戰略判斷不足所造成的問題。雖然 MVP 階段追求速度沒錯，但在核心功能（像會員系統這種未來勢必會擴充的模組）上，必須更早投入更多心力去規劃彈性架構，否則之後會付出更大的代價。這次的經驗提醒我，未來在做功能優先級排序時，除了考量短期效益，也必須把長期產品願景與架構彈性納入決策。

這一週整體進度雖然符合預期，但內心深處還是覺得稍微慢了一點，尤其是帳號刪除功能和會員系統的重構，比原本預估的時間多花了一些。不過，這些額外的時間投入都是值得的，因為現在的架構已經更穩固，未來再擴充功能時，速度一定能更快。

展望下一週（2025-04-07 到 2025-04-13）的規劃：

1. **產品端**：

- 開始進行 Ingrelens 的使用者訪談，收集第一手回饋，尤其針對會員系統與成分搜尋功能的使用體驗，這能幫助我更準確地抓住下一階段產品迭代的重點。

2. **技術端**：

- 進一步觀察成分搜尋功能的效能表現，以決定是否要導入 PostgreSQL 的 pg_trgm extension，避免在使用者量增加後搜尋效能瓶頸爆炸。

- 重新評估一下 GA 蒐集到的數據，確認目前的使用者行為分析是否足以幫助產品決策，並考慮是否需要加入其他分析工具或事件追蹤。

3. **技術債務管理**：

- 徹底檢視一次目前的 codebase，建立一份更完整的技術債務清單，並將其納入未來每週固定處理的例行任務，避免再次出現技術債務堆積爆炸的情況。

下週可能面臨的挑戰，主要還是在使用者訪談與數據分析的結果上。訪談結果可能與我原本的假設有落差，這時候要如何快速調整產品方向與優先級，將會是我必須面對的課題。應對策略上，我會提前準備好幾個可能的調整方案，並在訪談過程中隨時保持開放態度，避免自己陷入單一假設的盲點裡。

整體而言，這一週雖然很累，但也很紮實，算是為 Ingrelens 的下一階段發展打下了更穩固的基礎。接下來的一週，讓我們帶著更清晰的戰略視野與更扎實的技術基礎，繼續往前衝吧！💪🚀