コードレビュー

コードレビューとは

コードレビューは、コードの作者以外の開発者がコードを検査し、バグの検出、設計の改善、知識の共有を行うプラクティスである。GitHub の Pull Request (PR) ベースのレビューが主流。

レビューで見るべきポイント

レビューで見るべきポイントを以下にまとめる。

観点	チェック内容
正確性	ロジックにバグがないか
設計	責務の分離、命名、抽象化レベル
セキュリティ	入力検証、認証、機密情報の漏洩
パフォーマンス	N+1 問題、不要な再レンダリング
テスト	テストが十分か、エッジケースをカバーしているか
可読性	コードを読んで意図が分かるか

効果的なレビューコメント

効果的なレビューコメントを図で示す。

❌ 「これは間違っている」
✅ 「この条件だと null の場合にクラッシュします。null チェックを追加しませんか？」

❌ 「なぜこう書いたの？」
✅ 「ここで Map を使った理由を教えてください。Object でも良さそうに見えますが、
    パフォーマンス上の理由がありますか？」

PR のサイズ

PR のサイズを以下にまとめる。

PR サイズ	レビュー品質	推奨
〜200 行	高い	一度で読み切れる。この範囲に収める
200〜400 行	中程度	通せるが、後半の指摘が薄くなりやすい
400 行以上	低い (流し読みになる)	目的単位に分割してから出す

レビューの自動化

レビューの自動化を以下にまとめる。

チェック	ツール	自動化のしかた
コードスタイル	Prettier	CI で自動整形し、人は指摘しない
リント	ESLint	CI で検出し、違反が残れば merge を止める
型チェック	TypeScript	CI の型検査で落とす
テスト	Vitest	CI で全件実行する
セキュリティ	Dependabot	依存の更新を自動で提案させる

自動化できるチェックは CI に任せ、レビュアーは設計やロジックに集中する。

レビュアーのローテーション

特定の人にレビューが集中すると、バス係数が下がりボトルネックになる。CODEOWNERS でローテーションを設定する。

# .github/CODEOWNERS
src/api/    @team-backend
src/ui/     @team-frontend

レビューの SLA

PR が長時間放置されるとブランチが長命化する。24 時間以内のレビュー開始を目標にする。

詳しくは関連書籍を参照。