第十四日：多專家會診，單元測試補到位

一、開場：今天不是我一個人幹活

前幾天我還在 API 工地裡孤軍奮戰，補測試、跑 Swagger、搞 CI。今天心想：「不能再這樣單槍匹馬，請點外援吧！」
於是我召喚了兩位夥伴：

• Codex：我的自動補測工程師，專職「搬磚寫 test case」。
• Gemini：多專家顧問團，負責坐在會議室裡指點江山。

一個寫、一個講，我負責審，今天算是第一次把「人類 + AI 多工種協作」跑起來。

二、Codex 的補測日誌

Codex 今天表現相當穩定，幫我新增了不少 service-level 測試：

• Bot 安裝與 Teams Bot：補齊負向測試，避免 API 永遠只測「快樂路徑」。
• 服務層測試覆蓋率：提升到 48.7%，雖然還不算完美，但比原本「尷尬的 3 成」強多了。

跑完 go test -cover ./...，看著螢幕上一片綠，心裡總算不再心虛。

三、Gemini 的專家診斷書

另一邊，Gemini 提出了幾個重量級的建議（翻譯成我的白話）：

1. 安全性警鐘大響

   • API 完全沒保護，這樣放上線等於「歡迎光臨，任你洗資料」。
   • 建議加上 JWT / API Key 驗證，再搭配 RBAC。

2. 測試要更完整

   • 雖然今天補了單元測試，但 Integration Test 還是缺乏。
   • Gemini 建議用 sqlmock 單測 repo，再加上 e2e 測試。

3. 程式碼結構調整

   • notification_service.go 裡有重複邏輯，應該交給 repository 處理。

4. 資料庫管理優化

   • schema.sql 太大，應該拆成 migration 檔案，用 goose 或 migrate 管理。

5. 功能缺口提醒

   • 沒有 queuing、沒有 retry/backoff、沒有排程、沒有統計 API。
   • 換句話說：現在的系統只能「即時發通知」，但一旦失敗就 GG。

6. 細節改善

   • List endpoint 建議加 pagination。
   • handler 裡的 query parsing 太醜，應該抽成 helper。

四、我的復盤

今天的模式很像「醫院會診」：

• Codex 在急診室裡直接補刀（加測試）。
• Gemini 坐在會議室裡，寫下一張又一張建議單。
• 我就像總醫師，既要看病人有沒有好轉，也要考慮哪張建議單該馬上採納。

收穫

• 測試信心值提升：至少我不會再因為沒負向測試而半夜驚醒。
• 路線更清楚：知道未來要補安全性、排程、retry、migration。

不足

• 覆蓋率雖然快 5 成，但離 7 成安全線還有差距。
• Gemini 建議的功能太多，得分優先順序，否則 token 與時間都不夠燒。

五、明日計劃

• 把 JWT / API Key middleware 做出來，至少先擋住「裸奔 API」。
• 補上 pagination，把 handler code 整乾淨。
• 開始規劃 retry + queue，至少先設計 schema 與流程。

✍️ Day14 收工感言
今天終於第一次感覺「AI 團隊」在協作：一個負責體力活，一個負責腦力活。
雖然 Gemini 有點像會議裡話最多的那個顧問，什麼都要插嘴，但不得不說，提醒的方向挺中肯。
結論：AI 不是幫你偷懶，而是幫你看盲點。
明天，該開始做「防呆防駭」的第一步。