Requesting Code Review Skill
Requesting Code Review 是 Superpowers 中的重要協作型 skills，專注於有效地請求程式碼審查，確保程式碼品質並促進團隊知識分享。
何時使用
在以下情況中使用 Requesting Code Review skill：
✅ 必須使用的情境：
- 完成一個功能或重構後
- 準備合併程式碼到主分支前
- 需要第二意見確認設計決策
- 不確定實作方式是否最佳
- 想要分享知識和經驗
❌ 不適合的情境：
- 只是修正明顯的 typo
- 純粹的配置檔案調整
- 緊急的 hotfix（可先合併再事後審查）
- 還在開發中的功能
程式碼審查的價值
1. 品質保證
提升程式碼品質：
- 發現潛在的 bug 和問題
- 確保符合專案標準
- 改善程式碼可讀性
- 提升測試覆蓋率
2. 知識分享
促進團隊學習：
- 分享最佳實踐
- 學習新的技術和技巧
- 建立共同的程式碼語言
- 降低巴士係數
3. 設討驗證
驗證技術決策：
- 確認設計方向的合理性
- 探索更好的解決方案
- 識別潛在的技術債務
- 平衡各種技術考量
如何有效請求審查
第 1 步：自我審查
在請求他人審查前先自我審查：
自我審查清單：
✓ 程式碼符合專案規範
✓ 已經過基本測試
✓ 沒有除錯用的 console.log
✓ 沒有註解掉的程式碼
✓ 檔案和函式命名清楚
✓ 複雜邏輯有註解說明
✓ 已經過 formatting（linting 通過）第 2 步：撰寫清楚的 PR 描述
好的 PR 描述能幫助審查者快速理解：
## 概述
實作使用者註冊功能，支援 email 註冊和密碼驗證。
## 變更內容
- 新增 User model 和資料庫 schema
- 實作 POST /api/auth/register 端點
- 建立註冊表單 UI 組件
- 加入表單驗證和錯誤處理
## 測試
- [x] 單元測試通過
- [x] 手動測試註冊流程
- [x] 測試錯誤情況（email 重複、密碼太短）
## 截圖
（附上 UI 截圖）
## 問題
- 密碼複雜度要求是否需要更嚴格？
- 是否需要 email 驗證機制？
## 相關 Issue
Closes #123第 3 步：選擇合適的審查者
選擇適合的審查者：
選擇標準：
✓ 熟悉相關程式碼領域
✓ 有時間進行審查
✓ 能提供有價值的回饋
✓ 考慮時區因素
人數建議：
- 小型變更：1-2 人
- 中型變更：2-3 人
- 大型變更：3-5 人第 4 步：提供審查指引
清楚地告訴審查者關注什麼：
## 審查重點
請特別關注：
1. 認證邏輯的正確性
2. 密碼安全性實作
3. API 設計是否合理
已知問題：
- 表單樣式還需要調整（在下個 PR 處理）
技術決策：
- 使用 bcrypt 而非 Argon2（因為團隊較熟悉）實際範例
範例 1：新功能 PR
場景：實作購物車功能
好的 PR 描述：
## 實作購物車功能
### 變更摘要
這個 PR 實作完整的購物車功能，讓使用者可以新增、移除和修改商品數量。
### 技術實作
- **狀態管理**：使用 React Context API
- **持久化**：localStorage + 備份到伺服器
- **效能優化**：使用 React.memo 減染優化
### 主要檔案
- `src/components/Cart.tsx` - 購物車組件
- `src/contexts/CartContext.tsx` - 狀態管理
- `src/api/cart.ts` - API 呼叫
### 測試
- 新增商品到購物車 ✓
- 調整商品數量 ✓
- 移除商品 ✓
- 計算總價 ✓
- 持久化功能 ✓
### 問題討論
1. 是否需要支援多種貨幣？
2. 購物車是否需要過期機制？
### Demo
（附上操作影片或 GIF）範例 2：重構 PR
場景：重構服務層架構
好的 PR 描述：
## 重構：提取使用者服務層
### 重構目標
將使用者相關的邏輯從控制器提取到獨立的服務層，提升可測試性和可維護性。
### 重構步驟
1. 建立 UserService 類別
2. 移動認證邏輯到服務層
3. 更新控制器依賴注入
4. 加入單元測試
### 架構改變
**之前**：Controller → 直接操作 Model
**之後**：Controller → Service → Model
### 好處
- ✓ 職責分離更清楚
- ✓ 測試更容易（不需要 mock Controller）
- ✓ 邏輯可被複用
### 測試
- 所有既有測試通過
- 新增服務層單元測試
- 整合測試驗證
### 影響範圍
- 使用者登入/註冊功能
- 使用者資料管理
- 不影響前端（API 保持相容）審查者的期望
作為審查者，你應該：
-
提供具體回饋
❌ 「這裡有問題」 ✅ 「第 45 行的驗證邏輯可能會在 X 情況下失敗，建議加入 Y 檢查」 -
說明原因
❌ 「改用這個方式」 ✅ 「建議用 map 替代 forEach，因為這樣更函數式，且更容易測試」 -
認可好的部分
✓ 「這個抽象設計很好！」 ✓ 「測試覆蓋很完整」 -
區分必須和建議
**必須修正**：安全問題 **建議改進**：效能優化 **可選**：命名風格
回應審查意見
接受建議
感謝建議！我已經修正：
- 使用 map 替代 forEach
- 加入錯誤處理
- 更新測試
請再次審查。討論不同意見
關於使用 Argon2 的建議：
我考慮過這個選項，但選擇 bcrypt 是因為：
1. 團隊較熟悉 bcrypt
2. 目前效能已足夠
3. bcrypt 的安全性對我們的使用案例來說已經足夠
不過我同意在未來可以考慮遷移到 Argon2。
你的看法呢？解釋技術決策
為什麼使用 Context 而非 Redux：
這個功能相對簡單，Context 已經足夠：
- 狀態結構簡單
- 不需要複雜的狀態管理
- 減少依賴和複雜度
未來如果需要更複雜的管理，我們可以考慮遷移到 Zustand 或 Redux。程式碼審查最佳實踐
1. 適時的 PR 大小
✓ 好的 PR：
- 200-400 行程式碼變更
- 單一功能或重構
- 審查時間 15-30 分鐘
✗ 不好的 PR：
- 1000+ 行程式碼變更
- 多個不相關的變更
- 審查時間超過 1 小時2. 清楚的提交訊息
# 好的提交訊息
git commit -m "feat(auth): add user registration with email verification"
# 不好的提交訊息
git commit -m "update"
git commit -m "fix stuff"3. 及時的審查
目標回應時間：
- 緊急：2 小時內
- 高優先：24 小時內
- 中優先：3 天內
- 低優先：1 週內
如果無法及時審查：
- 通知 PR 作者
- 建議其他審查者
- 預估審查時間4. 建設性的討論
原則：
- 對事不對人
- 提供具體建議
- 解釋技術理由
- 尊重不同意見
避免：
- 「這很爛」
- 「為什麼這樣寫？」
- 「重寫」常見問題
Q1：PR 太大怎麼辦？
A：拆分為多個小的 PR：
第 1 個 PR：資料庫 schema 和 model
第 2 個 PR：API 端點
第 3 個 PR：前端 UI
第 4 個 PR：測試和文件Q2：沒有人審查我的 PR 怎麼辦？
A：
- 在團隊頻道提醒
- 直接 tag 相關成員
- 詢問是否有時間
- 考慮調整審查者
Q3：審查者意見不合怎麼辦？
A：
- 先理解對方的觀點
- 解釋你的技術決策
- 提供具體的利弊分析
- 必要時請第三者意見
- 記錄決策理由
與其他 Skills 組合
推薦組合
Verification + Requesting Code Review
verification-before-completion → requesting-code-review完成後驗證，再請求審查
Requesting + Receiving Code Review
requesting-code-review → receiving-code-review請求審查，然後處理回饋
程式碼審查檢查清單
功能性
- 功能符合需求
- 邊界條件處理
- 錯誤處理完整
品質
- 程式碼可讀
- 命名清楚
- 邏輯簡潔
- 沒有重複程式碼
測試
- 有足夠的測試
- 測試覆蓋主要情境
- 測試可讀且可維護
安全
- 輸入驗證
- 輸出轉義
- 認證授權正確
- 沒有暴露敏感資訊
效能
- 沒有明顯的效能問題
- 查詢效率合理
- 沒有不必要的重渲染
Requesting Code Review 是確保程式碼品質和促進團隊成長的關鍵 skill，善用它來建立高品質的程式碼文化！