Dev

API 重構後的幾點實話：技術債、產品判斷與下一步

這週把 Ingrelens 的幾個老問題一次整起來：API 架構統一、環境變數管理自動化、會員系統與帳號刪除流程重構，還把 HTTP 全面升級到 HTTPS。Dockerfile 重新整理、部署腳本補上該有的保險，過去半年累積的技術債至少清了一大段。

從工程面看，收益很明確。環境變數的自動化腳本雖然寫起來不輕鬆，但部署的穩定度立刻提升，手動改錯的風險幾乎清零；API endpoint 統一後，前端開發少了不少「猜測」與重複修正，後端安全性也更乾淨。這些是值得記上一筆的地方。

但回過頭來，技術債的代價比想像中高。像 endpoint 不一致、URL 寫死在 component、會員系統初期規劃不足，當下看都不急，累積到這週就一次爆掉，時間與心力都被吃掉。結論很直接：之後每次上新功能，都要把「技術債清單」列入例行工作，而不是等到事情變大再處理。

另一個收穫是在產品決策。當初設計 Ingrelens 時，沒預期會員模組會一路變複雜，後面要擴充時就不停撞牆。MVP 求快沒錯，但對於必然會延展的核心模組（像會員與權限），需要更早投資彈性設計，不然後段的代價只會更高。未來做優先級排序時，短期效益與長期架構彈性要一起放進決策，而不是分開看。

進度方面，這週達標，但比原估慢了一些，主要卡在帳號刪除與會員流程重構。不過這段額外時間是值得的：底盤打穩，後續迭代會快很多。

下週（2025/04/07–2025/04/13）計畫：

產品：開始使用者訪談，重點放在會員流程與成分搜尋的使用體驗，讓下一階段的迭代方向更準確。
技術：觀察成分搜尋效能，必要時導入 PostgreSQL 的 pg_trgm 延伸套件，避免未來使用者量起來時搜尋卡頓。同步檢查 GA 的數據是否足夠支撐產品決策，評估是否補其他分析工具或事件追蹤。
技術債務管理：全面檢視 codebase，整理一份可維護的技術債清單，列為每週固定項目，避免再出現集中爆炸。

可能的挑戰在於：訪談結果可能與目前假設有落差。面對這件事，需要準備好幾套調整方案，並且在過程中維持開放，不把自己鎖在單一路徑。

總結：這週累但紮實，底層結構更穩，之後的節奏能加快。下一週帶著更清楚的產品路徑與更乾淨的技術基礎，往前推。