圖片輪播的坑：你以為很簡單，結果滿滿都是邊界問題 😑
原本以為這就是個半小時內能搞定的小元件，畢竟圖片輪播這種東西，React 生態圈裡應該早已經成熟到爆炸了吧？結果呢，Danny，你又錯得離譜了。
昨天處理完 `.gitignore` 的玄學後，今天終於回到正事上，先從之前排在待辦清單裡的產品圖片輪播開始著手。原本以為這就是個半小時內能搞定的小元件，畢竟圖片輪播這種東西，React 生態圈裡應該早已經成熟到爆炸了吧？結果呢，Danny，你又錯得離譜了。
一開始只是想加個簡單的圖片 URL 檢查，避免使用者看到一堆破圖。結果寫著寫著才發現，光是圖片載入狀態的管理就讓我頭痛不已。假設使用者網路慢，圖片還沒載好，輪播就開始動了，這樣用戶體驗根本慘到不行。於是我決定加上載入狀態的 placeholder，讓輪播在圖片全部載入完成之前不會亂動。原本以為這樣就解決了，結果又踩到下一個坑：如果圖片載入失敗怎麼辦？
「Danny，你真的要每張圖都加 onError 處理嗎？這樣是不是有點太過麻煩？」我內心無奈地自言自語著。但想想看，如果不處理這個問題，使用者看到破圖就會覺得這個產品不夠專業，品牌形象直接扣分，這我可受不了。最後只能硬著頭皮，每張圖片都加上錯誤處理邏輯，並顯示一個統一的 fallback 圖。寫到這裡，我心裡還是有點懷疑：「這麼多額外的邏輯，真的值得嗎？」
搞定前端這堆小麻煩後，接著回頭處理 API 端的產品分類查詢功能。這個功能看似簡單，就是一個分類查詢 API 嘛，CRUD 的日常而已。但當我開始設計分頁邏輯和子分類的支援時，才意識到問題沒那麼單純。原本的產品模型設計根本沒考慮到多層分類的需求，導致分頁查詢混亂無比。這時候我又開始反問自己：「Danny，當初到底為什麼不一開始就考慮到這個需求呢？」
無奈之下，我只好重構產品資料模型，加上子分類的結構，順便調整了產品分析服務裡的主要功能，確保產品質地描述的提取邏輯能跟著新架構保持一致。架構調整的過程總是有種「動一髮牽全身」的感覺，稍微一不留神就會漏掉什麼地方，然後等到部署上去才發現問題，這種事情我可不想再經歷一次了。
晚上收尾的時候，回頭把 GuestUpgradeForm 的同意條款 Checkbox 給補上，這個功能雖然看似小，但也是之前用戶反饋中常被提到的點。使用者常常抱怨提交升級請求時不夠清楚自己到底同意了什麼，導致後續客服解釋成本變高。加了這個 checkbox 後，我自己也感覺安心不少：「至少現在出問題時，可以理直氣壯地說：你看，你明明就有勾選同意了啊～」
回頭看今天的工作，雖然都是些看似小到不能再小的功能，但每個細節背後都有一堆難以預料的邊界問題。做產品久了，我越來越清楚一件事：真正決定用戶體驗的，往往不是那些華麗酷炫的大功能，而是藏在細節裡的這些小痛點。Danny，記住這個教訓，下次估時的時候別再這麼樂觀了好嗎？ 🤦♂️