軟體架構的腐壞，從來不是一天造成的，而是無數個隨便放行的 LGTM 累積出來的技術債。

阿姨年輕的時候待過一家公司，某天某個 Team 發生了一起嚴重的效能災難。一個新人發了一個 PR，裡面藏著一個極度經典的 N+1 Query 問題，在一個迴圈裡面對 Database 下了上千次 Select 查詢。

負責 Review 的是一位準備要下班去接小孩的資深工程師。他嫌這個 PR 改的檔案太多（超過 800 行程式碼），根本懶得 checkout 下來跑跑看。他只在網頁上隨便滑了幾下，看了看變數命名沒太大問題，就留下了一句「LGTM」，按下 Approve。

隔天，這包 Code 部署到 Production 環境。遇到晚上的流量尖峰，Database 的 Connection Pool 瞬間被抽乾，伺服器 CPU 飆到 100%，整個服務直接噴 502 Bad Gateway 躺平。

事後檢討會議上，新人委屈地說：「可是前輩有 Approve 我的 PR 啊。」結果那位資深工程師馬上變臉甩鍋：「Code Review 只是幫你檢查有沒有語法錯誤跟 Coding Style，商業邏輯跟效能瓶頸本來就是 Author 自己要負責測試的啊！」

這就是軟體業最噁心的推諉。平常稱兄道弟，出事了就說 Code Review 不保證品質。把審查機制當成橡皮圖章，是對軟體工程最嚴重的褻瀆。

Code Review 絕對不是社交活動，它是系統上線前的最後一道人為防火牆。要防止這種「假 Review，真甩鍋」的爛事，我們必須從開發流程與系統限制上下手。

1. 嚴格限制 PR 的爆炸半徑（Blast Radius）
   人類大腦的極限，一次最多只能有效審查 400 行以內的程式碼。在 CI/CD 工具（如 Danger.js 或是 GitHub Actions）裡直接設定限制：只要一個 PR 的變動超過 500 行（不含自動生成的檔案），CI 直接 Fail，並留下註解：「PR 體積過大，請拆分成多個小 PR 再來發送。」逼迫開發者學會原子化提交（Atomic Commits）。

2. 引進 Checklist 與 Explicit Approval
   不要讓 LGTM 變成廉價的過場動畫。在 Repo 裡強制設定 PR Template，Reviewer 在按下 Approve 前，必須勾選確認清單：

[ ] 我已確認此改動不會引發 N+1 Query 效能問題。

[ ] 我已確認此 API 的 Error Handling 都有正確記錄 Log。

[ ] 若此 PR 導致 Production 發生 P0 事故，我願意與 Author 共同承擔修復責任。
把責任白紙黑字寫出來，你看還有哪個資深工程師敢三分鐘秒按 Approve。

3. 靜態分析先行，人眼退居二線
   那些排版、變數命名、有沒有寫註解的蠢事，全部交給 SonarQube、ESLint、Ruff 這些自動化分析工具去吵。只要 Linter 沒過，PR 連指派給 Reviewer 的資格都沒有。人類工程師的 Review，只能專注在「架構設計」、「邊界條件」與「商業邏輯」上