code-review-pro

code-review-pro

熱門

全面的程式碼審查,涵蓋安全漏洞、效能瓶頸、最佳實務與重構機會。當使用者要求程式碼審查、安全稽核或效能分析時使用。

234星標
38分支
更新於 2026/7/15
SKILL.md
唯讀
名稱
code-review-pro
描述

全面的程式碼審查,涵蓋安全漏洞、效能瓶頸、最佳實務與重構機會。當使用者要求程式碼審查、安全稽核或效能分析時使用。

Code Review Pro

深入的程式碼分析,涵蓋安全性、效能、可維護性與最佳實務。

何時使用此技能

當使用者有以下需求時啟用:

  • 要求程式碼審查
  • 想要安全漏洞掃描
  • 需要效能分析
  • 要求「審查這段程式碼」或「稽核這段程式碼」
  • 提到尋找錯誤或改進
  • 想要重構建議
  • 要求驗證最佳實務

指示

  1. 安全性分析(最高優先)

    • SQL 注入漏洞
    • XSS(跨站腳本)風險
    • 驗證/授權問題
    • 程式碼中的機密或憑證
    • 不安全的反序列化
    • 路徑遍歷漏洞
    • CSRF 防護
    • 輸入驗證缺口
    • 不安全的加密
    • 依賴套件漏洞
  2. 效能分析

    • N+1 查詢問題
    • 低效率演算法(檢查 Big O 複雜度)
    • 記憶體洩漏
    • 不必要的重新渲染(React/Vue)
    • 缺少索引(資料庫查詢)
    • 阻塞操作
    • 資源清理(檔案控制代碼、連線)
    • 快取機會
    • 過多的網路呼叫
    • 過大的套件大小
  3. 程式碼品質與可維護性

    • 程式碼重複(違反 DRY 原則)
    • 函式/方法長度(應小於 50 行)
    • 循環複雜度
    • 命名不清楚
    • 缺少錯誤處理
    • 風格不一致
    • 缺少文件
    • 應為常數的硬編碼值
    • 上帝類別/函式
    • 緊密耦合
  4. 最佳實務

    • 語言特定慣用法
    • 框架慣例
    • SOLID 原則
    • 設計模式的使用
    • 測試方法
    • 日誌與監控
    • 無障礙性(針對 UI 程式碼)
    • 型別安全
    • Null/undefined 處理
  5. 錯誤與邊界情況

    • 邏輯錯誤
    • 差一錯誤
    • 競爭條件
    • 空指標例外
    • 未處理的邊界情況
    • 時區問題
    • 編碼問題
    • 浮點數精確度
  6. 提供可操作的修正

    • 顯示具體的程式碼變更
    • 解釋為何需要變更
    • 包含前後範例
    • 依嚴重性排序

輸出格式

# 程式碼審查報告

## 嚴重問題(立即修正)
### 1. SQL 注入漏洞(第 X 行)
**嚴重性**:嚴重
**問題**:使用者輸入直接串接到 SQL 查詢中
**影響**:資料庫受損、資料竊取

**目前程式碼:**
```javascript
const query = `SELECT * FROM users WHERE email = '${userEmail}'`;

修正後程式碼:

const query = 'SELECT * FROM users WHERE email = ?';
db.query(query, [userEmail]);

說明:務必使用參數化查詢以防止 SQL 注入。

高優先問題

2. 效能:N+1 查詢問題(第 Y 行)

[詳細內容...]

中優先問題

3. 程式碼品質:函式過長(第 Z 行)

[詳細內容...]

低優先 / 建議事項

4. 考慮使用 const 而非 let

[詳細內容...]

總結

  • 問題總數:12
    • 嚴重:2
    • 高:4
    • 中:4
    • 低:2

快速勝利

高影響力且低努力度的變更:

  1. [修正 1]
  2. [修正 2]

優點

  • 在 X 處有良好的錯誤處理
  • 命名慣例清楚
  • 模組結構良好

重構機會

  1. 提取方法:第 X-Y 行可提取為 calculateDiscount()
  2. 移除重複:[特定程式碼區塊]

資源


### 範例

**使用者**:「審查這段驗證程式碼」
**回應**:分析驗證邏輯 → 找出安全性問題(弱密碼雜湊、無速率限制)→ 檢查 token 處理 → 指出缺少 CSRF 防護 → 提供具體修正與程式碼範例 → 依嚴重性排序

**使用者**:「你能找出這個 React 元件的效能問題嗎?」
**回應**:分析元件 → 找出不必要的重新渲染 → 發現缺少 useMemo/useCallback → 指出大型狀態物件 → 檢查 render 中的昂貴操作 → 提供最佳化版本並附說明

**使用者**:「審查這個 API 端點」
**回應**:檢查輸入驗證 → 分析錯誤處理 → 測試 SQL 注入 → 審查驗證 → 檢查速率限制 → 檢查回應結構 → 建議改進並附程式碼範例

### 最佳實務

- 務必優先處理安全性問題
- 提供問題的具體行號
- 包含前後程式碼範例
- 解釋*為什麼*某個問題是問題
- 考量語言/框架脈絡
- 不要只批評——也要肯定好的程式碼
- 對於大型重構,建議漸進式改進
- 提供文件連結以支援建議
- 考量專案限制(舊程式碼、截止日期)
- 在完美主義與務實之間取得平衡
- 專注於有影響力的變更
- 將相似問題分組
- 讓建議可執行