code-review-quality

コードレビューの品質

<default_to_action> コードをレビューするとき、またはレビューの実践方法を定めるときは、次の点に従ってください。

1. フィードバックに優先順位を付けます：🔴 ブロッカー（必ず修正）→ 🟡 重大 → 🟢 軽微 → 💡 提案
2. 注目する点：バグ、セキュリティ、テスト容易性、保守性（スタイルの好みではありません）
3. 指示より質問を優先します：「〜を検討したことはありますか？」＞「これを〜に変更してください」
4. 背景を説明します：変更すべき点だけでなく、なぜ重要なのかを伝えます
5. 範囲を限定します：効果的なレビューのため、一度にレビューするコードは 400 行未満にします

クイックレビューのチェックリスト：

• ロジック：正しく動作しますか？エッジケースに対応していますか？
• セキュリティ：入力検証はありますか？認証チェックはありますか？インジェクションのリスクはありますか？
• テスト容易性：テストできますか？テストされていますか？
• 保守性：名前は分かりやすいですか？単一責任の原則に従っていますか？DRY ですか？
• パフォーマンス：O(n²) のループはありませんか？N+1 クエリはありませんか？メモリリークはありませんか？

成功のための重要な要素：

• 人ではなく、コードをレビューします
• 細かなスタイルの指摘より、バグを見つけることを優先します
• 網羅的なフィードバックより、迅速なフィードバック（24 時間未満）を優先します </default_to_action>

クイックリファレンスカード

使用する場面

• PR のコードレビュー
• ペアプログラミングでのフィードバック
• チームのレビュー基準の策定
• 開発者のメンタリング

フィードバックの優先度

レベル	アイコン	意味	対応
ブロッカー	🔴	バグ／セキュリティ／クラッシュ	マージ前に必ず修正
重大	🟡	ロジックの問題／テストの不足	マージ前に修正することを推奨
軽微	🟢	スタイル／命名	修正すると望ましい
提案	💡	別のアプローチ	今後のために検討

レビュー範囲の上限

変更行数	推奨事項
< 200	1 回のレビューセッションで行う
200-400	分割してレビューする
> 400	PR の分割を依頼する

注目する点

✅ レビューする	❌ 対象外にする
ロジックの正しさ	フォーマット（リンターを使用）
セキュリティリスク	命名の好み
テストカバレッジ	アーキテクチャの議論
パフォーマンスの問題	スタイルに関する意見
エラー処理	些細な変更

---

フィードバックのテンプレート

ブロッカー（必ず修正）

🔴 **BLOCKER: SQL Injection Risk**

This query is vulnerable to SQL injection:
```javascript
db.query(`SELECT * FROM users WHERE id = ${userId}`)

修正方法： パラメーター化クエリを使用します。

db.query('SELECT * FROM users WHERE id = ?', [userId])

理由： ユーザー入力を SQL に直接含めると、攻撃者が任意のクエリを実行できてしまいます。

### Major (Should Fix)
```markdown
🟡 **MAJOR: Missing Error Handling**

What happens if `fetchUser()` throws? The error bubbles up unhandled.

**Suggestion:** Add try/catch with appropriate error response:
```javascript
try {
  const user = await fetchUser(id);
  return user;
} catch (error) {
  logger.error('Failed to fetch user', { id, error });
  throw new NotFoundError('User not found');
}

### Minor (Nice to Fix)
```markdown
🟢 **minor:** Variable name could be clearer

`d` doesn't convey meaning. Consider `daysSinceLastLogin`.

提案（検討）

💡 **suggestion:** Consider extracting this to a helper

This validation logic appears in 3 places. A `validateEmail()` helper would reduce duplication. Not blocking, but might be worth a follow-up PR.

---

レビューで尋ねる質問

ロジック

• X が null／空／負の値の場合、どうなりますか？
• ここで競合状態は発生しませんか？
• API 呼び出しが失敗した場合はどうなりますか？

セキュリティ

• ユーザー入力は検証／サニタイズされていますか？
• 認証チェックは実装されていますか？
• シークレットや PII が漏えいしていませんか？

テスト容易性

• これをどのようにテストしますか？
• 依存関係を注入できますか？
• 正常系のテストはありますか？エッジケースのテストはありますか？

保守性

• 次の開発者にもこれを理解できますか？
• これは多くのことをしすぎていませんか？
• 減らせる重複はありませんか？

最低指摘数の適用

レビューでは、重み付けされた指摘スコアが最低 3.0（CRITICAL=3、HIGH=2、MEDIUM=1、LOW=0.5、INFORMATIONAL=0.25）に達する必要があります。最初のレビューで基準に満たない場合は、メタレビュアーとして qe-devils-advocate エージェントを実行し、追加の指摘事項を見つけてください。すべてのレビューには、対応可能な指摘事項を少なくとも 3 件含めてください。

---

エージェントを活用したレビュー

// Comprehensive code review
await Task("Code Review", {
  prNumber: 123,
  checks: ['security', 'performance', 'testability', 'maintainability'],
  feedbackLevels: ['blocker', 'major', 'minor'],
  autoApprove: { maxBlockers: 0, maxMajor: 2 }
}, "qe-quality-analyzer");

// Security-focused review
await Task("Security Review", {
  prFiles: changedFiles,
  scanTypes: ['injection', 'auth', 'secrets', 'dependencies']
}, "qe-security-scanner");

// Test coverage review
await Task("Coverage Review", {
  prNumber: 123,
  requireNewTests: true,
  minCoverageDelta: 0
}, "qe-coverage-analyzer");

---

エージェント連携のヒント

メモリの名前空間

aqe/code-review/
├── review-history/*     - Past review decisions
├── patterns/*           - Common issues by team/repo
├── feedback-templates/* - Reusable feedback
└── metrics/*            - Review turnaround time

フリートの連携

const reviewFleet = await FleetManager.coordinate({
  strategy: 'code-review',
  agents: [
    'qe-quality-analyzer',    // Logic, maintainability
    'qe-security-scanner',    // Security risks
    'qe-performance-tester',  // Performance issues
    'qe-coverage-analyzer'    // Test coverage
  ],
  topology: 'parallel'
});

---

レビューのエチケット

✅ すること	❌ しないこと
「〜を検討したことはありますか？」	「これは間違っています」
重要な理由を説明する	「これを修正してください」とだけ伝える
良いコードを評価する	否定的な点だけを指摘する
提案し、押し付けない	見下した態度を取る
400 行未満をレビューする	一度に 2000 行をレビューする

---

関連スキル

• agentic-quality-engineering - エージェントの連携
• security-testing - セキュリティレビューの詳細
• refactoring-patterns - 保守性のパターン

---

覚えておくこと

フィードバックの優先順位： 🔴 ブロッカー → 🟡 重大 → 🟢 軽微 → 💡 提案。スタイルではなく、バグやセキュリティに注目してください。命令するのではなく、質問してください。一度にレビューするのは400行未満にしてください。徹底的なレビューより、24時間以内の迅速なフィードバックが重要です。

エージェントを活用する： エージェントはセキュリティ、パフォーマンス、カバレッジのチェックを自動化し、人間のレビュアーがロジックや設計に集中できるようにします。一貫性のある迅速な初回レビューには、エージェントを活用してください。

スキルの組み合わせ

• セキュリティ上の懸念 → セキュリティに重点を置いたレビューを行うため、/security-testing と組み合わせます
• カバレッジの確認 → 変更したファイルに対して /qe-coverage-analysis を実行します
• リリースの判断 → レビュー結果を /qe-quality-assessment に渡します

注意点

• エージェントは一度に400行を超えるレビューを行うと問題を見落とします。レビューは最大200～400行に分割してください
• ロジックのバグを見落としてスタイルを細かく指摘することは、エージェントレビューで最も多い失敗です。フォーマットより正確性を優先してください
• エージェントは、コンパイルできても微妙な競合状態があるコードを承認することがあります。共有状態と非同期処理のパターンを必ず確認してください
• 修正案のないレビューコメントは役に立ちません。必ず代替案を提示してください
• エージェントは、PRがリンク先の課題を実際に解決しているか確認しません。記載された問題が本当に修正されているか検証してください