成分搜尋功能大改造，順便跟自己來場內心戲 🙃

昨天把品牌 API 整個重寫後，今天心裡一直有個聲音在問我：「Danny，你真的覺得這樣做值得嗎？品牌管理功能的優先級真的有高到要花這麼多時間嗎？」但轉念一想，品牌這塊資料遲早會爆炸，現在不花點功夫整理好，未來自己一定會詛咒今天的我吧？😅

既然品牌 API 都整理好了，今天就順勢來處理成分管理這個長期被我視而不見的坑吧。之前成分管理只有超陽春的 CRUD，完全沒有搜尋功能，導致每次前端要找某個成分時，後端都會回傳一大坨資料，然後前端再用 JavaScript 自己過濾，這種效率低到看不下去的事情居然還存在於我的 code 裡這麼久，我自己都覺得丟臉。

於是今天決定認真地實作一下成分關鍵字搜尋，考慮到使用者可能會打錯字或記不清楚成分名稱，我決定用 PostgreSQL 的 `ILIKE` 搭配 `%keyword%` 來做模糊查詢。至於用不用 `pg_trgm`，我猶豫了一下，畢竟成分名稱不像品牌那麼複雜，直接用 `ILIKE` 效能應該還行吧？

下午在測試 API 時，又發現了一個 Windows 環境特有的坑：Python 的 multiprocessing 模組在 Windows 上跑起來怪怪的，每次啟動多進程都會卡住。查了一下才發現，原來 Windows 上預設的進程啟動方式是 spawn，跟 Linux 的 fork 不一樣，難怪每次啟動都卡死在某個奇怪的地方。最後我決定用 if __name__ == "__main__" 包一層，並明確設定 `set_start_method('spawn')`。

搞定後果然並發效能提升不少，測試 API 時的回應速度明顯改善，這種效能提升的小確幸，果然還是很療癒的啊～🤩

順手補了一下品牌表跟產品表的外鍵關聯，之前居然漏了這個，難怪資料庫裡一堆沒有品牌的孤兒產品，這種資料髒亂的情況看了就想吐槽自己：「Danny，你是不是又偷懶了？🤔」這次特地寫了 migration 腳本，保證未來產品跟品牌的關聯性清楚明確。

另外，之前用 SQLAlchemy 的 text 查詢來處理品牌詳情，今天回頭看才發現根本沒必要搞這麼複雜，直接用 Database 工具類的 ORM 方法就能輕鬆搞定，於是又把這段重構了一遍。每次刪掉一堆冗餘程式碼，心裡就有種莫名的愉悅感，這大概就是工程師才懂的樂趣吧🤣

最後在 API 路由這邊也做了一些整理，之前路由的前綴常常重複定義，導致每次新增 API 時，都要再三確認路由是不是對的，這種浪費時間的事情今天終於受不了，乾脆寫了一個路由診斷的 CLI 工具，隨時能快速檢視已註冊的 API 路由，順便也寫了份 API 路由設計最佳實踐文檔，這樣未來自己或其他開發者看到我的 API 時，至少不會滿頭問號吧？（拜託不要再問我為什麼路由這樣設計了🙏）

今天雖然又是一路從成分搜尋挖到資料庫重構，再一路挖到 API 路由規範，但至少這些坑都補起來了。