qe-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 が漏えいしていませんか？

テスト容易性

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

保守性

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

---

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

// 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 時間以内）を優先します。

エージェントを活用する場合： エージェントはセキュリティ、パフォーマンス、カバレッジのチェックを自動化し、人間のレビュアーがロジックと設計に注力できるようにします。一貫性のある迅速な初期レビューには、エージェントを活用します。