Code Review 與 Ship：從偏執審查到一鍵交付

程式碼 review 有一個通病：做的人都覺得自己做得很認真，但實際上大家在看的是同一批問題。

命名是否清楚？邏輯有沒有明顯錯誤？有沒有少處理 edge case？這些都是好問題，但它們都是表面的——真正讓 production 出問題的，通常是那些更底層的東西：

N+1 query。
Race condition。
Trust boundary violation。
Missing index 讓 query 在高流量下慢成 timeout。
Retry logic 沒有 idempotency，出錯重試之後狀態錯亂。

這類問題，你的同事 review 的時候不一定會抓到——因為人腦不是為了同時跑五個 failure scenario 而設計的。

Gstack 的 /review 就是在做這件事：系統性地、不漏地掃那些高風險點。

/review：偏執型資深工程師的審查清單

/review 不是「幫我看看程式碼」。它背後有一份結構化的審查框架，每次都會覆蓋這幾個維度：

效能與資料庫

• N+1 query 有沒有？迴圈裡有沒有觸發資料庫請求？
• 新增的 query 有沒有對應的 index？高頻查詢在資料量成長後會不會慢？

併發與狀態

• 有沒有不安全的 race condition？
• 跨請求的共享狀態有沒有適當保護？

信任邊界

• 外部輸入有沒有被驗證？
• 用戶輸入有沒有可能帶著惡意 payload 繞過邏輯？

錯誤處理

• Retry logic 有沒有 idempotency 保護？
• 外部 API 呼叫失敗了，系統狀態還是一致的嗎？
• 有沒有可能 partial failure——有些東西寫進去了，有些沒有？

資源管理

• 連線、檔案、記憶體有沒有在用完之後確實釋放？
• 有沒有 orphaned upload 或資料孤立的問題？

跑完之後，/review 會把問題分類成「Critical」、「High」、「Medium」，並且給出每個問題的具體位置和修正建議——不是「這裡可能有問題」，是「第 47 行的這個 query 在用戶量超過 10K 後會開始變慢，原因是缺少 index，建議加 user_id 的 composite index」。

Greptile 整合：雙層 Review 都不漏

如果你的 repo 有接 Greptile（自動化 PR review 工具），/review 會多一個步驟：讀取 Greptile 的 comment，分類處理：

• 有效問題：加進 critical findings，在修完之前不放行
• 已修問題：自動回覆確認
• 誤報（false positive）：自動推回並附上解釋

這個設計的意義是：Greptile 掃 pattern，Gstack 做判斷——兩層過濾，缺失率更低。而且 Gstack 還會記錄確認的誤報，未來碰到同樣 pattern 自動略過——越用越聰明，不是每次都重新解釋一遍。

/ship：Release Engineer 的 SOP

/ship 不是「幫我 push 程式碼」。它是一個完整的 release checklist 的自動化版：

1. Sync main — 確認你的 branch 跟 main 同步，避免 merge conflict
2. Run tests — 跑所有 tests，確認沒有 regression
3. Resolve Greptile issues — 處理 Greptile 標記的 open issues
4. Push branch — push 到 remote
5. Open PR — 建立 pull request，附上清楚的描述

六個步驟，一個指令。

這聽起來不複雜，但你有沒有發生過這種狀況：寫完程式很興奮，直接 push，然後發現 tests 沒跑、branch 沒 sync、PR 描述是空的——然後被 reviewer 打回來，花了比寫功能更多的時間收尾。

/ship 的存在就是讓這個「機械式的正確流程」不依賴你的狀態——你是否在深夜趕 deadline、是否剛被 slack 打斷——都不影響 release checklist 的執行品質。

/review 和 /ship 的正確搭配順序

一定要先 /review，再 /ship——不要同時跑，也不要跳過 review 直接 ship。

理由很直接：/ship 只確認流程正確，不確認程式碼品質。它不管你有沒有 N+1 query，它只關心 branch 有沒有 sync、tests 有沒有過。

正確流程：

實作完成
    ↓
/review  ← 找問題，修問題
    ↓
問題修完，確認 critical findings 都處理了
    ↓
/ship  ← 跑 release checklist，推上去

有時候你很有把握「這次改動很小，不需要 review」——可以跳過，沒人攔你。但如果出問題，回頭看你會後悔沒跑。

一個值得知道的細節

/review 在跑的時候，會讀你的 git diff——它看的是這次有改到的程式碼，不是整個 codebase。

這很重要，因為它代表兩件事：

1. 它不會因為你的 codebase 很大就跑很慢——它只看改動的範圍
2. 它找的問題是「這次改動引入的問題」，不是「整個 codebase 的所有問題」

所以如果你有一個大型 legacy codebase，不用擔心跑 /review 會輸出幾百個舊問題——它只關注這次你動了什麼。

---

程式碼品質確認了，交付流程自動化了——接下來是 Gstack 最獨特的部分：給 AI 一雙真實的眼睛，讓它看到你的 app。

→ QA 與 Browse：給 AI 一雙眼睛，讓它真的「看到」你的 app

---

回到系列總覽

這篇是 Gstack 系列的第四站，聚焦 /review 與 /ship。完整閱讀路線與其他篇主題，請回到 Gstack 入門課。