コードレビュー
他の開発者がコードを検査し、品質向上と知識共有を行うプラクティス
開発プラクティス品質
コードレビューとは
コードレビューは、コードの作者以外の開発者がコードを検査し、バグの検出、設計の改善、知識の共有を行うプラクティスである。GitHub の Pull Request (PR) ベースのレビューが主流。
レビューで見るべきポイント
| 観点 | チェック内容 |
|---|---|
| 正確性 | ロジックにバグがないか |
| 設計 | 責務の分離、命名、抽象化レベル |
| セキュリティ | 入力検証、認証、機密情報の漏洩 |
| パフォーマンス | N+1 問題、不要な再レンダリング |
| テスト | テストが十分か、エッジケースをカバーしているか |
| 可読性 | コードを読んで意図が分かるか |
効果的なレビューコメント
❌ 「これは間違っている」
✅ 「この条件だと null の場合にクラッシュします。null チェックを追加しませんか？」
❌ 「なぜこう書いたの？」
✅ 「ここで Map を使った理由を教えてください。Object でも良さそうに見えますが、
パフォーマンス上の理由がありますか？」
PR のサイズ
| PR サイズ | レビュー品質 | 推奨 |
|---|---|---|
| 〜200 行 | 高い | ✅ |
| 200〜400 行 | 中程度 | △ |
| 400 行以上 | 低い (流し読み) | ❌ 分割する |
レビューの自動化
| チェック | ツール | 自動化 |
|---|---|---|
| コードスタイル | Prettier | ✅ (CI で自動修正) |
| リント | ESLint | ✅ (CI で自動チェック) |
| 型チェック | TypeScript | ✅ |
| テスト | Vitest | ✅ |
| セキュリティ | Dependabot | ✅ |
自動化できるチェックは CI に任せ、レビュアーは設計やロジックに集中する。
レビュアーのローテーション
特定の人にレビューが集中すると、バス係数が下がりボトルネックになる。CODEOWNERS でローテーションを設定する。
# .github/CODEOWNERS
src/api/ @team-backend
src/ui/ @team-frontend
レビューの SLA
PR が長時間放置されるとブランチが長命化する。24 時間以内のレビュー開始を目標にする。
詳しくは関連書籍を参照。