軟刪除這件小事，沒想到牽扯出這麼多細節 🤔

週末花了一整天搞定圖片輪播的邊界問題後，本以為今天的 API 調整應該算是輕鬆場，沒想到又低估了自己的強迫症程度。一開始只是想補個產品刪除的 API，畢竟總不能讓使用者上傳的產品永遠卡在系統裡吧？

但刪除這件事情，你真的想清楚了嗎？直接硬刪除當然簡單又俐落，但如果使用者後悔了怎麼辦？客服又要來敲門抱怨了吧：「Danny，客戶說他手滑刪掉的產品能不能幫忙救回來一下？」想到這裡，只好決定做軟刪除，給產品加上 `deletedAt` 欄位，這樣至少還能有反悔的空間。

原本覺得這樣應該差不多搞定了吧，卻又馬上想到一個問題：產品查詢邏輯現在得考慮這個「軟刪除」狀態了。沒錯，Danny，你現在每一個產品相關的查詢都得加上 `WHERE deletedAt IS NULL`，否則 API 就會開天窗給你看。於是又花了不少時間調整產品服務層的邏輯，順便更新 API 文件，確保前端同事看到文件後不會一臉茫然：「Danny，為什麼這個 API 回傳的產品數量怪怪的？」

處理完刪除功能後，回頭繼續昨天沒完成的分類查詢 API。昨天晚上睡前還在想：「分類過濾這個功能真的有價值嗎？使用者真的會點進去嗎？」但想想看，首頁如果只是單純顯示最近分析的產品，好像也沒什麼意義。於是早上起來果斷把首頁改成了分類商品區塊，順便把產品頁面的分類過濾功能也給補上。React 那邊的邏輯倒是沒什麼大問題，畢竟只是個簡單的篩選狀態。但後端 API 的分類過濾就沒想像中單純了。

一開始直接在產品服務裡用個 if 判斷分類 ID 存不存在，然後簡單過濾一下資料庫查詢就好。結果寫到一半才發現分類還有子分類結構，原本的邏輯根本沒考慮到這一層，寫完後自己都覺得不滿意：「Danny，你確定這樣的 API 是你想要的嗎？」於是只好重新調整產品服務的邏輯，改用遞迴查詢把子分類的產品也撈進來，順便更新了一波測試案例，免得之後又被 QA 同事吐槽：「Danny，你的 API 又漏考慮邊界情境了啦！」

忙了一整天下來，雖然只是兩個 API 的調整，但背後牽涉的細節遠比想像中複雜。特別是軟刪除這個功能，明明看起來簡單到不行，但一旦開始動手，卻發現要考慮的角度超乎預期。以後再碰到這種 CRUD 功能，還是乖乖多想個十分鐘再動手吧，不然又要多花半天補坑了 🤦‍♂️