接續 Code Review 方法論。你知道怎麼 review 和被 review 了，但如果團隊之前完全沒做過呢？
先講結論
一次到位會讓團隊反感。漸進式導入，讓大家先感受到好處，再加規範。
Code Review 在 CI/CD 的定位
重點是：人類 review 放在 CI 自動檢查之後。
Lint error、format issue、test failure 應該在 CI 就被擋掉。Reviewer 不該花時間告訴你「少一個分號」——那是機器的工作。
| 自動化負責 | 人類負責 |
|---|---|
| Lint / Format / Type check | 架構設計合理性 |
| Unit test / Integration test | 商業邏輯正確性 |
| Security scanning | 更好的設計方案 |
| Coverage threshold | 知識分享與教學 |
CI 過了才開 review，reviewer 拿到的至少是「能跑的 code」。
建議的 GitHub Branch Protection：
- Require 1 approval before merge
- Require CI status checks pass
- Require branches to be up to date
- Dismiss stale reviews when new commits pushed
四階段導入法
Phase 1：建立基礎（第 1-2 週）
開始用 PR，不要直接 push to main。PR 至少要有 description（What / Why / How）。設定 CI：lint + test 過才能 merge。先不強制 review，讓大家習慣流程。
Phase 2：開始 Review（第 3-4 週）
要求至少 1 個 approve。導入 comment 前綴系統（[must] / [nit] / [question] / [nice]）。設定 review SLA：24 小時內要有第一次 review。鼓勵 [nice] comment——review 不只是挑毛病。
Phase 3：優化流程（第 5-8 週）
PR < 400 行規範。設定 PR template 自動帶出 What / Why / How / Test。Review rotation——不要永遠同一個人 review。定期回顧速度、品質、大家的感受。
Phase 4：進階實踐（第 9 週後）
Pair programming 搭配 Code Review。ADR（Architecture Decision Records）。自動化更多檢查。追蹤 review 數據。
常見阻力怎麼處理
你一定會遇到這些：
「我沒時間 review」——Review 就是工作，不是額外的事。把 review 時間排進 sprint。
「Review 太慢影響進度」——設定 SLA。PR 太大就拆小。24 小時內必須第一次 review。
「被 review 很不舒服」——培訓 reviewer 怎麼寫好 comment，先從 [nice] 開始。一個只會挑毛病的 reviewer 會摧毀整個文化。
「PR 放很久沒人看」——Bot 提醒、Slack 通知、standup 追蹤。
「Senior 都不認真 review」——Lead 以身作則。Review 品質也是績效考核的一部分。
Review SLA 建議
| PR 類型 | 首次 Review | 完成 Review |
|---|---|---|
| Hotfix | 2 小時 | 4 小時 |
| 一般 Feature | 24 小時 | 48 小時 |
| Refactoring | 48 小時 | 一週 |
延伸閱讀
- Google Engineering Practices - Code Review — 業界公認最佳參考
- Conventional Comments — Comment 前綴的靈感來源
- How to Make Your Code Reviewer Fall in Love with You — Author 角度的實戰好文
Code Review 做得好，整個團隊的品質和文化都往上。做得不好，浪費時間還傷感情。終極目標不是抓 bug，是讓每個人都寫出更好的 code——這是學習的過程，不是考試。