コードレビュー

コードレビューは形式的な手続きではありません。正確性のための機械です。

パート1：レビューのリクエスト

レビューをリクエストする前に準備すること

コードレビューをリクエストする前に、3つのことを把握しておく必要があります：

WHAT： このコードは何をするのか？

機能の1〜2文の説明
これが触れるシステムの部分
このコードで意図的に行われた設計上の決定

PLAN： これはどのようにレビューされるべきか？

このコードの品質を検証するために実行すべきテスト
レビュアーが特に注意を払うべき領域
既知の制限または考慮事項

BASE_SHA → HEAD_SHA： 何が変わったのか？

レビュアーが変更を正確に見ることができるgit範囲
git log --oneline BASE_SHA..HEAD_SHAで変更の概要を確認できる

レビュアーsubagentのdispatchテンプレート

コードレビューをリクエストします。

**変更の説明：**
[このコードが何をするかの1〜2文の説明]

**変更されたファイル：**
- `src/path/to/file.ts` — [このファイルで変更されたもの]
- `src/path/to/other.ts` — [このファイルで変更されたもの]

**Git範囲：**
BASE_SHA: [ベースcommit hash]
HEAD_SHA: [headcommit hash]

**実行するテスト：**
```bash
npm test -- --testPathPattern=[関連パターン]

特に確認してほしい点：

[特定の懸念点1]
[特定の懸念点2]


### レビューの厳格さ

すべての問題が同じ重要度ではありません。Superpowersのレビューは問題を3つのカテゴリに分類します：

| 厳格度 | 意味 | 例 |
|---|---|---|
| **Critical** | コードがmergeできない — 正確性、セキュリティ、またはデータの問題 | SQL injection、認証のバイパス、データ損失のバグ |
| **Important** | mergeをブロックすべき — 設計、保守性、または通過するが誤ったテスト | 高い結合度、貧弱なエラーハンドリング、弱いテスト |
| **Minor** | 改善をお勧めする — スタイル、読みやすさ、または好み | 命名の改善、コメントの追加、コードの整理 |

Criticalの問題はmergeをブロックします。Importantの問題は通常mergeをブロックします—コードの作成者が対処しないことを正当化しない限り。Minorの問題はコードの作成者の判断に委ねられます。

---

## パート2：レビューを受ける

### パフォーマンス的な同意の問題

コードレビューには共通の失敗パターンがあります：レビュアーが問題を指摘し、コードの作成者が「対処します」と言い、何も変わらない。

これは**パフォーマンス的な同意**と呼ばれ、コードレビューを役に立たなくします。実際にコードを改善するのではなく、改善のように見えるために言葉を使います。

Superpowersのレビューはパフォーマンス的な同意を機能させません。なぜなら、すべての懸念事項は検証可能な結果で対処する必要があるからです—同意を述べるだけでは不十分です。

### 禁止フレーズ

これらのフレーズはパフォーマンス的な同意を示します。コードレビューへの返答でこれらを使わないでください：

| 禁止フレーズ | なぜ機能しないか |
|---|---|
| 「おっしゃる通りです、修正します」 | 実際の変更なしには意味がない |
| 「良い指摘です」 | 変更なしに変更を約束する |
| 「それは意図的です」 | 文脈なしには検証できない |
| 「後で対処します」 | 「後で」がくることは稀 |
| 「問題だとは思いません」 | 理由のない却下 |

### READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT

コードレビューを受けるとき、このプロセスに従ってください：

**READ：** フィードバックを完全に読んでください。すべての問題を。先にスキップしないでください。

**UNDERSTAND：** 各問題について：
- レビュアーが見ていると思うものを正確に特定する
- その懸念を自分の言葉で言い直す
- わからない場合は、推測する前に明確化を求める

**VERIFY：** コードを確認してください：
- 問題は実際に存在するか？
- コードの中で問題を正確に特定できるか？

**EVALUATE：** 問題に対するあなたの立場を決定してください：
- 同意：問題は有効で修正されるべき
- 不同意：問題は有効でないか、YAGNIの理由から対処しない（以下参照）
- 不明：問題をよりよく理解するために明確化が必要

**RESPOND：** あなたの立場を伝えてください—同意、不同意、または不明—理由を添えて。

**IMPLEMENT：** 同意した変更については、変更を行い、テストを実行し、変更が問題を修正したことを確認してください。

### YAGNIチェック

フィードバックを受けるとき、各提案を承認済みの仕様に照らし合わせてください。提案が以下のものである場合：

- 今日実装する必要のない将来の要件に対応するもの
- 現在の問題を修正するために必要のない抽象化
- 「あったら良い」機能で仕様に含まれていないもの

...その場合、YAGNIによって丁重に断ることができます：「これは[承認された仕様]には含まれておらず、このイテレーションには必要ありません。後続の計画で対処することをご提案します。」

### 有効なプッシュバックのシナリオ

すべてのレビューフィードバックに従う必要はありません。プッシュバックが適切な場合：

1. **スコープの問題：** フィードバックが現在の計画の外のことを要求している
2. **設計上の不同意：** 提案が動作するが、別の有効なトレードオフがある
3. **提案に欠陥がある：** 提案された修正が問題を解決しないか、新しい問題を導入する
4. **情報の不足：** レビュアーが見ていないコンテキストがある

有効なプッシュバックは理由を提供します。「私はあなたに同意しません」は有効なプッシュバックではありません。

### プッシュバックテンプレート

```markdown
[ファイル、行番号] についてのご指摘を理解しています。

私が見ていること：[レビュアーが見ている問題を自分の言葉で言い直す]

私がプッシュバックする理由：[具体的な理由—スコープ、設計上のトレードオフ、情報の不足など]

代替提案：[別のアプローチまたはこの問題を処理するタイミング]

これが間違っている場合は教えてください。

コードレビューの目的は正しいコードを作ることです。 それには本物の関与が必要です—言葉だけの同意ではなく、懸念の本物の理解と同意した変更の本物の実装です。