コードレビューの作法
ストーリー
チームメンバーの山田さんからPRのレビュー依頼が来た。
「レビューって、何を見ればいいんですか？」
佐藤先輩が答える。
「レビューは"ダメ出し"じゃない。"一緒にコードを良くする"作業だ。 技術的な正しさだけでなく、読みやすさや保守性も見る。 そして何より、相手へのリスペクトを忘れるな」
コードレビューの目的
| 目的 | 説明 |
|---|---|
| バグの早期発見 | 動かす前に問題を見つける |
| コード品質の向上 | 読みやすさ、保守性、パフォーマンス |
| 知識の共有 | チーム全体のスキルアップ |
| 設計の一貫性 | プロジェクト全体のスタイル統一 |
| セキュリティ | 脆弱性や機密情報の混入防止 |
レビューの観点
1. 機能面
- 要件を満たしているか
- エッジケースが考慮されているか
- エラーハンドリングは適切か
2. コード品質
- 命名は分かりやすいか
- 関数やクラスの責務は適切か
- 重複コードはないか
- 複雑すぎる処理はないか
3. セキュリティ
- SQLインジェクションの危険はないか
- XSS攻撃の可能性はないか
- 機密情報がハードコードされていないか
- 入力値の検証は十分か
4. パフォーマンス
- 不要なループやクエリはないか
- N+1問題はないか
- メモリリークの可能性はないか
5. テスト
- テストカバレッジは十分か
- 正常系だけでなく異常系もテストしているか
- テストは理解しやすいか
レビューの進め方
GitHub上でのレビュー
bash
# PR一覧を確認
gh pr list
# 特定のPRの詳細を確認
gh pr view 42
# PRの差分を確認
gh pr diff 42
# レビューを開始
gh pr review 42レビューの3つのアクション
| アクション | 意味 | 使う場面 |
|---|---|---|
| Approve | 承認 | 問題なし、マージOK |
| Request Changes | 変更を要求 | 修正が必要な問題がある |
| Comment | コメント | 質問や提案のみ（承認/却下しない） |
良いレビューコメントの書き方
基本ルール
- 具体的に: 「ここが良くない」ではなく「こうした方が良い理由は...」
- 提案型で: 「ダメ」ではなく「こうしたらどうでしょう？」
- 根拠を示す: 「この書き方はXXの理由でバグになる可能性があります」
- 良い点も褒める: 「この設計は分かりやすいですね」
コメントの接頭辞
チームでよく使われる接頭辞の規約です。
| 接頭辞 | 意味 | 対応が必要か |
|---|---|---|
[must] | 修正必須 | はい |
[should] | 修正推奨 | できれば |
[nit] | 些細な指摘 | どちらでも |
[question] | 質問 | 回答が必要 |
[praise] | 褒め | 不要 |
[suggestion] | 提案 | 検討をお願い |
コメント例
[must] ここでユーザー入力を直接SQLに組み込んでいます。
SQLインジェクションの脆弱性があるため、プレースホルダーを使用してください。
修正案:
const result = await db.query('SELECT * FROM users WHERE id = ?', [userId]);
[nit] 変数名 `d` が何を表しているか分かりにくいです。
`data` や `userData` などの説明的な名前はいかがでしょうか？
[praise] このエラーハンドリングの設計はきれいですね。
リトライ機能の実装が参考になり ます。
レビューを受ける側の心得
基本姿勢
- 感情的にならない: コードへの指摘であり、人格への攻撃ではない
- 素直に受け止める: 指摘は改善のチャンス
- 分からなければ質問する: 理解せずに修正しても意味がない
- 感謝を伝える: レビューは時間を使って行ってくれている
レスポンスの例
指摘ありがとうございます。確かにSQLインジェクションの危険がありますね。
プレースホルダーに修正しました。（コミット: abc1234）
なるほど、N+1問題のリスクがあるのですね。
JOINクエリに変更する方向で修正します。
レビューのワークフロー
1. PR作成
↓
2. レビュアーを指名（Reviewers に追加）
↓
3. レビュアーがコードを確認
↓
4. コメント・変更要求・承認のいずれかを実行
↓
5. [変更要求の場合] 作者が修正してプッシュ
↓
6. 再レビュー
↓
7. 承認 → マージ
レビューの目安時間
| PRのサイズ | 変更行数 | レビュー時間目安 |
|---|---|---|
| S | ~50行 | 15分 |
| M | 50~200行 | 30分 |
| L | 200~500行 | 1時間 |
| XL | 500行以上 | PRを分割すべき |
推奨: PRは小さく保ちましょう。200行以下が理想です。
まとめ
| ポイント | 内容 |
|---|---|
| レビューの目的 | バグ発見、品質向上、知識共有 |
| レビュー観点 | 機能、品質、セキュリティ、パフォーマンス、テスト |
| コメント | 具体的に、提案型で、根拠を示す |
| 接頭辞 | [must], [should], [nit], [question], [praise] |
| PR サイズ | 200行以下を目指す |
チェックリスト
- レビューの5つの観点を把握した
- コメント接頭辞の使い分けを理解した
- 良いレビューコメントの書き方を知った
- レビューを受ける側の心得を理解した
次のステップへ
コードレビューの作法を学びました。
次のセクションでは、PR・レビューを含むチーム開発のワークフロー全体を学びます。 ブランチ保護、CODEOWNERS、CIチェックなど、チーム運用の仕組みです。
推定読了時間: 30分