170 lines
6.1 KiB
Markdown
170 lines
6.1 KiB
Markdown
# PRレビュー - 包括的なコードレビュー実行
|
||
|
||
指定されたPull Requestを詳細にレビューし、改善提案を行います。
|
||
|
||
## 使用方法
|
||
`/pr-review <PR番号またはURL>`
|
||
|
||
例:
|
||
- `/pr-review 123`
|
||
- `/pr-review https://github.com/owner/repo/pull/123`
|
||
|
||
## 実行手順
|
||
|
||
### 1. PR情報の取得と検証
|
||
- `gh pr view <PR番号> --json` でPR詳細情報を取得
|
||
- タイトル、説明、作成者、ステータスを確認
|
||
- ターゲットブランチとソースブランチの確認
|
||
- 認証エラー時はフォールバック処理を実行
|
||
|
||
### 2. 変更内容の分析
|
||
- `gh pr diff <PR番号>` で差分を取得
|
||
- 変更されたファイル一覧を取得 (`gh pr view --json files`)
|
||
- 追加・削除された行数の統計情報を収集
|
||
- コミット履歴の確認 (`gh pr view --json commits`)
|
||
|
||
### 3. コードレビューの実施
|
||
|
||
#### 3.1 自動チェック項目
|
||
|
||
- **セキュリティ（最重要・厚めにチェック）**
|
||
- **認証・認可**
|
||
- ハードコードされた認証情報（API key, password, token等）
|
||
- 認証トークンの安全な保管方法
|
||
- 認可チェックの実装（権限検証の欠落）
|
||
- セッション管理の安全性
|
||
- **インジェクション攻撃**
|
||
- SQLインジェクション脆弱性
|
||
- NoSQLインジェクション
|
||
- コマンドインジェクション
|
||
- XSS（Stored/Reflected/DOM-based）
|
||
- LDAP/XMLインジェクション
|
||
- **入力検証とサニタイゼーション**
|
||
- ユーザー入力の検証不足
|
||
- ファイルアップロードの検証
|
||
- Content-Type検証
|
||
- サイズ制限の実装
|
||
- ホワイトリスト方式の採用
|
||
- **データ保護**
|
||
- 機密情報のログ出力
|
||
- 暗号化の適切な実装
|
||
- 安全でない乱数生成
|
||
- パスワードのハッシュ化（bcrypt、Argon2等）
|
||
- **API/ネットワークセキュリティ**
|
||
- CORS設定の安全性
|
||
- CSRF対策の実装
|
||
- Rate limiting の実装
|
||
- HTTPSの強制
|
||
- **依存関係のセキュリティ**
|
||
- 既知の脆弱性を持つライブラリ
|
||
- 最新版への更新の必要性
|
||
- **その他のセキュリティ**
|
||
- パストラバーサル脆弱性
|
||
- XXE（XML External Entity）攻撃
|
||
- サーバーサイドリクエストフォージェリ（SSRF）
|
||
- 安全でないデシリアライゼーション
|
||
|
||
- **テストケース（重要・厚めにチェック）**
|
||
- **テストカバレッジ**
|
||
- 新規機能に対するテストの有無
|
||
- 既存機能への影響範囲のテスト
|
||
- エッジケースのカバー状況
|
||
- エラーケースのテスト
|
||
- **テストの種類と品質**
|
||
- 単体テスト（Unit Test）の適切性
|
||
- 統合テスト（Integration Test）の必要性
|
||
- E2Eテストの必要性
|
||
- テストの可読性と保守性
|
||
- **テストケースの十分性**
|
||
- 正常系のテスト
|
||
- 異常系のテスト（バリデーションエラー、ネットワークエラー等）
|
||
- 境界値テスト
|
||
- 並行処理のテスト（該当する場合）
|
||
- **セキュリティテスト**
|
||
- 認証・認可のテスト
|
||
- 入力検証のテスト
|
||
- エラーハンドリングのテスト
|
||
- **モックとテストデータ**
|
||
- 外部依存のモック化
|
||
- テストデータの適切性
|
||
- テスト環境の分離
|
||
- **パフォーマンステスト**
|
||
- 負荷テストの必要性評価
|
||
- レスポンスタイムの検証
|
||
- **過剰なテストの検出**
|
||
- 実装の詳細に依存しすぎたテスト（脆弱なテスト）
|
||
- 重複したテストケース
|
||
- 価値の低いテスト（自明な処理のテスト）
|
||
- メンテナンスコストが高すぎるテスト
|
||
- 不要にモックが多すぎるテスト
|
||
|
||
- **コード品質**
|
||
- 命名規則の一貫性
|
||
- 重複コードの検出
|
||
- 複雑度の評価
|
||
- デッドコードの検出
|
||
|
||
- **パフォーマンス**
|
||
- N+1クエリの検出
|
||
- 非効率なループ処理
|
||
- 不要な再レンダリング（フロントエンド）
|
||
- メモリリークの可能性
|
||
|
||
- **保守性**
|
||
- 適切なコメントの有無
|
||
- エラーハンドリングの実装
|
||
- ログ出力の適切性
|
||
- ドキュメントの更新
|
||
|
||
#### 3.2 プロジェクト固有のチェック
|
||
- プロジェクトのコーディング規約への準拠
|
||
- 既存のアーキテクチャとの整合性
|
||
- 依存関係の適切な管理
|
||
|
||
### 4. レビュー結果のフォーマット
|
||
|
||
#### 4.1 サマリー
|
||
- 全体的な評価（Approve/Request Changes/Comment）
|
||
- 主要な問題点の要約
|
||
- 良い点の強調
|
||
|
||
#### 4.2 詳細フィードバック
|
||
各ファイルごとに：
|
||
- 問題点の指摘（行番号付き）
|
||
- 改善提案と具体的なコード例
|
||
- 参考となるドキュメントやベストプラクティスへのリンク
|
||
|
||
#### 4.3 アクションアイテム
|
||
- 必須の修正項目（ブロッカー）
|
||
- 推奨される改善項目
|
||
- 将来的な改善提案
|
||
|
||
### 5. GitHub上でのコメント投稿（オプション）
|
||
- `gh pr comment` を使用してレビューコメントを投稿
|
||
- 行単位のインラインコメント
|
||
- 全体的なレビューコメント
|
||
|
||
## エラーハンドリング
|
||
|
||
### GitHub CLI認証エラー
|
||
プライベートリポジトリで認証エラーが発生した場合：
|
||
1. エラーメッセージを表示
|
||
2. 手動でPRを確認するためのURLを提供
|
||
3. 認証の再設定方法を案内：
|
||
- `gh auth refresh -s repo,read:org`
|
||
- GITHUB_TOKEN環境変数の確認
|
||
|
||
### API制限
|
||
- レート制限に達した場合の待機処理
|
||
- 部分的な結果での続行オプション
|
||
|
||
## 設定オプション
|
||
- `--format`: 出力形式（markdown/json/html）
|
||
- `--severity`: レビューの厳密さ（strict/normal/lenient）
|
||
- `--focus`: 特定の観点に絞る（security/performance/style）
|
||
- `--no-comment`: GitHubへのコメント投稿をスキップ
|
||
|
||
## 前提条件
|
||
- GitHub CLIがインストールされ認証済みであること
|
||
- 対象リポジトリへの読み取りアクセス権限
|
||
- PR番号またはURLが有効であること |