taste-code-review

taste-code-review

「動作する」は最低条件です。感覚ではなく、順序立ててレビューしましょう。手法なしでレビューするエージェントは、記憶なしでレビューするのと同じです。

1. レビューの順序（この順番で修正し、逆にはしない）

1. 動作 — エッジケース（空の状態、エラー経路、連続クリック、オフライン時など）も含め、期待どおりに動作しますか？正常系だけで動く機能は、機能の格好をしたバグです。
2. 構造 — コードは適切な場所にありますか？（ファイルやコンポーネントの境界、ユニットごとの責務は一つ、400行の関数がないこと、インポートが整理されていること、デッドコードがないこと。）
3. コードのセンス — 命名、重複、コードベースの規約との一貫性です。誰も求めていない詩のようなコードは、バスの時刻表のように読めるコードよりも悪いものです。ただし、停留所名がわかりやすい時刻表が最善です。
4. セキュリティ — インジェクション（HTML／URL／SQL）、コードやログ内のシークレット、すべての変更処理における認可、信頼できない入力との境界です。
5. パフォーマンス — 明らかなアルゴリズム上の無駄、N+1クエリ、レンダリングごとに繰り返される処理、クリティカルパス上の巨大なペイロードです。
6. アクセシビリティ — キーボード操作、フォーカス状態、コントラスト、セマンティクス、スクリーンリーダー向けの名前です（taste-accessibilityのチェックリストはコードにも当てはまります）。

構造上の修正で行単位のレビューが無効になるため、レビューはこの順序で行います。詳細より先に全体の形を確認してください。

2. 指摘事項（重要度順に並べ、対応できる形で記述）

• 指摘事項にはすべて、重要度（blocker／should-fix／nit）、場所（ファイル:行）、問題を一文で説明した内容、修正方法を一文で説明した内容を含めます。場所も修正方法もないレビューは、レビューではなく苦情です。
• Blocker：誤った動作、セキュリティ上の欠陥、データ損失、デザインシステムへの違反（taste-code-craftを参照）。
• Should-fix：重複、デッドコード、命名の不統一、エッジケース処理の不足、パフォーマンス上の重大な問題。
• Nit：フォーマット、命名に関する意見。指摘はしますが、ブロッカーにはしません。
• 指摘に値する差分がそれより少ない場合、指摘を約10件以上に増やさないでください。 すべてがblockerなら、それはレビューをしたのではなく、確認の順序を飛ばしたということです。

3. 差分の規律（レビューはコードを書く前から始まる）

• 最小の論理的な変更をレビューします。名前の変更、機能追加、バグ修正を混ぜたPRは、トレンチコートを着た3つのPRです。まとめ方は差し戻し、コードは残します。
• 変更の流れではなく、差分を一連の判断として読みます。「なぜこれが存在するのか」は「何をしたのか」より重要です。
• 生成コードにも手書きのコードと同じ基準を適用します。エージェントがコードを生成したからといって、レビューを免れるわけではありません。
• テストもレビューします。正常系しか検証しないテストは、テストではなく宣伝資料です。

4. 最後の問い

承認する前に、一つだけ問いかけます。自分で書いたコードだったとしても、これをマージしますか？ 答えが「いいえ」なら、その理由を一文で述べてください。「はい」なら、指摘事項を添えてレビューを通します。すべてが完璧である必要はありませんが、すべてに意図がなければなりません。

5. チェックリスト（次のいずれかに該当したらレビューを不合格にする）

• 指摘事項が重要度順に並んでいない、または場所が記載されていない。
• エッジケース（空／エラー／繰り返し／オフライン）の確認を記録していない。
• 「ただのランディングページだから」という理由でセキュリティ確認を省略した。
• コードがリポジトリの既存の規約に沿っているか確認していない。
• 変更した動作に対するテストがない、または正常系しか確認していない。
• 生成コードの差分を、人が書いたコードより低い基準でレビューした。
• 確認内容を示さずに「問題なさそうです」と述べている。