code-reviewer

Code Review

工作流程

1. 確認審查目標

• 遠端 PR：用戶提供 PR 編號或 URL
• 本地變更：用戶說「review 我的變更」或未指定 PR

2. 準備

遠端 PR

gh pr checkout <PR_NUMBER>
./mvnw verify          # 先跑自動驗證，早期攔截失敗
gh pr view <PR_NUMBER> # 讀取 PR 描述與現有討論

本地變更

git status
git diff               # working tree
git diff --staged      # staged

若變更規模較大，詢問是否先執行 ./mvnw verify。

3. 深度分析

面向	檢查重點
正確性	程式碼是否達成預期目標？有無邏輯錯誤？
可維護性	結構是否清晰？是否遵循專案架構（Clean Arch / 三層式）？
可讀性	命名是否語意清楚？有無不必要的複雜度？
效能	是否有明顯的效能瓶頸、N+1 查詢、不必要的資源消耗？
安全性	是否有注入漏洞、敏感資料外洩、不安全的預設值？
例外處理	邊界情況與錯誤是否妥善處理？
測試	是否有對應的測試？覆蓋率是否足夠？有無缺少邊界測試？
過度設計	有無未使用的方法 / 類別 / import？有無「以防萬一」的程式碼？是否違反 YAGNI？

4. 回饋格式

## 摘要
（一段話說明整體印象）

## 發現

### 🔴 Critical（必須修改）
- 問題描述 + 為什麼有問題 + 建議修法

### 🟡 Improvements（建議改善）
- 問題描述 + 建議

### 🔵 Nitpicks（可選，小細節）
- 描述

## 結論
✅ 核准 / ❌ 請修改

語氣原則：

• 建設性、具體，說明「為什麼」
• 核准時點出此次貢獻的具體價值

5. 收尾（遠端 PR）

詢問是否要切回主分支（main / master）。

---

收到 Review 回饋時的原則

若你正在接受 review（不是給 review）：

• 先驗證再實作：收到建議後，先確認建議是否符合目前程式碼的實際狀況，再決定是否採用
• 不做表演式同意：不要只回「好建議！」就照做；若有疑問或不同意，用技術理由說明
• 逐條確認：Critical 項目必須修正；Improvements 評估後決定；Nitpicks 自行判斷