API 化身為無底洞：一場分頁與 OCR 的深淵探險
昨天我才剛處理完 ProductAttributes 的重構，原本以為今天能輕鬆接續前端的 error handling，結果一早我就被後端的品牌 API 問題給吸進去了。
# 原本只是想修個圖片上傳的小問題，結果一路重寫到品牌 API，這樣真的好嗎？🤔
早上修完昨天的產品屬性顯示邏輯之後，還是覺得 Ingredient 驗證那段程式碼看起來怪怪的。原本只是想調一下 `isEmptyOrUnspecifiedIngredient()` 的邏輯，結果一看之下發現這個函數居然寫了三層巢狀判斷，還夾雜了兩個正規表示式，這根本是逼死未來的自己吧？😅 最後我還是下定決心把整個 `ProductAttributes` 元件重構了一輪，順便加上了更清楚的錯誤回饋訊息，這樣使用者至少知道為什麼成分驗證沒過。
修完前端的錯誤處理，接著就順手解決了一直拖著的圖片上傳問題。之前每次圖片上傳失敗，使用者根本不知道發生什麼事，只能回報：「圖片上傳一直轉圈圈」。我自己測試也發現，後端錯誤訊息其實早就寫好了，但前端根本沒處理，難怪使用者一頭霧水。趁這次機會，我直接在前端加上了錯誤提示元件，並且讓錯誤訊息能夠更清楚地回傳給使用者。雖然只是個小改動，但能讓使用者少一點困惑，感覺還是蠻值得的。
然後我就想說：「前端的錯誤處理都做了，後端 API 那邊是不是也該檢查一下？」結果一查之下，才發現品牌管理 API 之前根本只寫了最基本的 CRUD，也沒做搜尋跟分頁，資料一多，前端載入品牌列表超級慢。於是我決定一次性把品牌 API 做完，直接用 PostgreSQL 的 `pg_trgm` 模組來處理模糊搜尋，順便把分頁跟排序功能加上去。說真的，一開始我還猶豫了一下：「Danny，你真的要花時間搞這個嗎？品牌管理真的有這麼重要？」但一想到未來產品越來越多，品牌管理是一定會用到的，還是狠下心來做吧，不然到時候資料量大了再回頭修就慘了。
做品牌 API 的時候，順便又發現產品分析流程裡的 OCR 邏輯放錯地方了。原本 OCR 的產品名稱提取寫在條碼掃描端點，結果每次條碼掃描就要跑 OCR，明明很多時候根本不需要，這完全就是浪費效能嘛！於是我決定把 OCR 的產品名稱提取移到分析端點，這樣只有在真正需要分析產品成分時才跑 OCR。順便也把條碼掃描的格式驗證加強了一下，避免使用者傳了一堆奇怪的格式上來，每次看到資料庫裡一堆亂七八糟的 barcode，心裡都很不是滋味。
最後花了一些時間寫了產品辨識的測試腳本，尤其是針對身體乳液類型的圖片，畢竟這類產品的成分標示通常比較複雜。測試的時候又忍不住懷疑自己：「這個 OCR 辨識真的能準確到讓使用者滿意嗎？還是到頭來又變成工程師的自嗨功能？」但轉念一想，至少現在把基礎架構搭建好了，未來再慢慢調校 OCR 模型的準確度，總比到時候什麼都沒有來得好吧？🤷♂️
今天又是不小心從一個小問題一路挖到了整個產品分析跟品牌管理功能的重構，雖然有點強迫症發作，但至少現在看起來順眼多了。