この記事では、コードレビューを行う際に気をつけるべきポイントやプロセス、さらに「将来的な問題」にも目を向ける方法について詳しくまとめます。
また、参考にした記事として わからないところは聞く - Qiita の要点も含めています。
1. コードレビューの基本方針
目的は品質向上とナレッジ共有
コードレビューは単にバグを見つけるだけの作業ではありません。以下の観点でレビューを進めると良いでしょう。
-
品質向上
コードのバグ・パフォーマンス問題を見つけ、より良い実装に改善する -
可読性・保守性の向上
チームで長期的にメンテナンスしやすいコードになっているか -
ナレッジ共有・教育
コードレビューを通じてチームメンバーのスキル向上や情報共有を図る
2. コードレビューでのチェックポイント
2.1 diffとして見えている部分
PR（Pull Request）や差分（diff）として見えている箇所は、以下を重点的に確認します。
✅ スペルミスがないか
- 変数名、コメント、ドキュメント、APIエンドポイント名などにスペルミスがないか
✅ コーディング規約に従っているか
- チームのスタイルガイドや言語特有のベストプラクティスに沿っているか
- インデント、改行、変数命名規則、関数の長さなど
✅ if文の条件が正確か
- 条件式の比較演算子や論理演算子が意図通りになっているか
- 条件の順序や括弧が適切か
✅ エラー処理が適切か
- 例外やエラーが正しくハンドリングされているか
✅ パフォーマンスやスケーラビリティに問題がないか
- 無駄なループや重複コードはないか
- 必要に応じてキャッシュや最適化がされているか
2.2 diffとして見えていない部分
見えていない部分にも目を向けるのが重要です。
例えば、PRには一部の変更だけが見えていることが多いため、以下のような問題が潜んでいないかを意識します。
✅ 空間的な問題
- 他のモジュールやライブラリとの依存関係は問題ないか
- 共通処理の一貫性が保たれているか
- 同じロジックが複数箇所に分散していないか
✅ 時間的な問題（将来の変更による問題）
- 今後の要件変更で壊れやすい部分がないか
- 将来の拡張やバグ修正が困難にならないか
- 直近の別PRや別タスクで競合が起きないか
3. テストの必要性を判断する
レビューしながら「テストを書くべきかどうか」も見極める必要があります。
以下の視点でテストの追加・修正が必要かを判断しましょう。
- 新機能追加やバグ修正に伴うテストが含まれているか
- リグレッション（既存機能の破壊）防止のテストがあるか
- テストデータやモックが適切に準備されているか
- テストカバレッジが重要な箇所を網羅しているか
もしテストが十分でないと感じたら、追加を依頼したり、どういうテストが必要かを指摘します。
4. コードレビュー時に心がけること
📝 わからないところは遠慮せずに質問する
- どんなに経験を積んでも、実装者の意図が見えない部分は必ず出てきます。
- そのままレビューを進めると誤解が生まれやすいので、早めに質問するのが大切です。
例：
「この条件式はこういう意図で書かれているのでしょうか？」
「このAPIは外部仕様上こう動く認識で合ってますか？」
🤝 コミュニケーションを大切にする
- レビューコメントは「指摘」より「対話」を意識します。
- 「こうしたらどうですか？」と提案形式にするだけでも、相手の受け取りやすさが変わります。
5. まとめ
コードレビューは「コードを良くする」だけでなく、「チームを強くする」重要な活動です。
今回の記事でまとめたポイントを意識しながら、ぜひ日々のレビューに役立ててみてください！