なぜコードレビューはスムーズに進まないのか？
チーム開発において、コードレビューの重要性はあえて言うまでもないでしょう。不確実なコードがプロダクトに取り込まれるのを防ぐのに役立ち、プログラマーのスキル向上にも役立ちます。熟練のエンジニアであっても、他のエンジニアのチェックが入ることでタイポを発見したり、ロジック上の漏れを発見できる可能性があります。
コードレビューが大事だと分かっていつつも、開発組織内においては課題も散見されます。よく聞かれるのは「コードレビューに時間がかかる」「指摘が曖昧で分かりづらい」「ディスカッションが長引き、コードがマージされない」などです。皆さんの組織でもあるあるではないでしょうか。
本記事では、そうした課題を解決できるようにチェックすべき事項をリストアップします。レビューする側・受ける側ともに事前にチェックしておくことで、コードレビューがスムーズになるはずです。
コードレビュー前の準備
コードレビューを受ける前に、コードレビュアー・レビューイ双方が準備すべきことを解説します。
[開発者向け] レビューしやすいコードを書くためのポイント
開発者が注意すべきポイントは以下の3つです。
コードを適切に分割してプルリクエスト（PR）を作成する
コードの変更量と、コードレビューにかかる時間は比例します。大きなPRはレビュアーにとっても負担になりますので、コードを適切に分割してPRを作成しましょう。1機能ごとに分割する、1ファイルごとに分割する、などの方法があります。
PRの説明文を充実させる（変更点、理由、影響範囲 など）
レビュアーと自分で、同じ業務知識があると考えてはいけません。技術スキルはレビュアーの方が上であったとしても、コードを理解するためにはビジネスドメインの知識が欠かせません。そして、その知識はコードを書いた本人の方が圧倒的に上なのです。
そのため、プルリクエストの説明文は十分にあって然るべきです。コードを読めば分かる、ということはありません。変更点、理由、影響範囲などを記載しましょう。
テストの実行を確認する
書かれているコードがテストに通過していなければなりません。レビューを通ったからと言って、コードが正しくプロダクト内で動作するとは限りません。正しく動作するかどうかを保証するのはテストの役割です。
Linterやユニットテスト、システムテストなどはCI/CDを通してレビュー前に通過しているようにしましょう。特にコーディングスタイルのような組織内での統一されたルールはCI/CDで自動的にチェックすることが重要です。
[レビュアー向け] 事前準備のポイント
レビュアーが注意すべきポイントは以下の3つです。
なるべく早めにレビューを行う
プルリクエストを受け取ったら、なるべく早めにレビューを行いましょう。レビューが遅れると、開発者が次の作業に進めないため、開発全体の進捗が遅れる可能性があります。また、書いたコードに関する知識が新鮮な内にレビューすることで、質問に対しても的確に回答が得られます。2〜3日放置するだけで、プログラマーの記憶は薄れてしまいます。
レビューの目的を明確にする
レビュアーがどういった視点でレビューを行うのか、組織内で統一認識を作っておきましょう。レビュアーによって指摘事項が異なったり、前は言っていなかったことを言われたりすると、開発者は混乱します。レビューの目的を明確にすることで、開発者がどういった視点でコードを書くべきかも明確になります。
コードの背景や目的を把握する
プルリクエストの背景や変更の目的を把握することで、レビューする解像度が向上します。それを曖昧にしたままチェックしても、それはLinterレベルの指摘で終わってしまうかも知れません。特にモジュール・システム間連携など複雑な習性になると、背景を知らないと予想外の不具合発生につながる可能性があります。
そのためには、システムの仕様や要件を把握することが欠かせません。ドキュメント文化やモブプログラミングなど、情報共有の仕組みを整えることが重要です。
コードレビュー中のチェックリスト
では、ここからコードレビューでのチェックリストを紹介します。今回は88つのカテゴリーに分けて紹介します。
-
コードの品質チェック:
- 可読性（変数・関数名が適切か、コメントは適切か）
- 保守性（再利用しやすいコードになっているか）
- 拡張性（新機能の追加がしやすいか）
- シンプルさ（無駄な処理がないか）
-
バグの可能性チェック:
- ビジネスロジックや要件を正しく満たしているか
- エッジケースや例外処理を考慮しているか
- ユニットテスト・E2Eテストがカバーされているか
-
パフォーマンスチェック:
- 不要なループや計算負荷の高い処理がないか
- メモリリークやリソースリークがないか
- 大量データを扱う処理においてボトルネックにならないか
- データベースのクエリが適切か（N+1問題の確認 など）
-
スタイル・規約チェック:
- コーディング規約に沿っているか（lintツールの活用）
- チームのコードスタイルに沿っているか
-
セキュリティチェック:
- クロスサイトスクリプティング（XSS）やSQLインジェクションなどの脆弱性がないか
- バリデーションやサニタイズは行われているか
- ログ出力は適切か
- データベースのアクセス権限は適切か
- セッション管理やパスワード管理、機密情報管理が適切か
-
テストチェック:
- 単体テスト、結合テストなどが書かれているか
- テストケースは網羅的か（正常系・異常系）
- CIによる自動テストが通るか
-
依存関係・ライブラリ:
- 不要なライブラリや依存の追加がないか
- 使用しているライブラリはメンテナンスされているか
- バージョンの互換性は保たれているか
-
ドキュメントチェック:
- コードのコメントが適切か（docstringなど）
- マイグレーション、環境設定ファイルなどが適切に管理されているか
- ドキュメントも更新されているか
もちろん組織によってチェックすべき項目は増減があると思いますので、これをベースにカスタマイズしてもらえればと思います。
レビュー後のTips
最後に、コードレビュー後の対応のコツを紹介します。
指摘に優先順位を設ける
コードレビューで指摘された項目すべてに対応する必要はないかも知れません。指摘の重要度や緊急度に応じて、優先順位をつけて対応しましょう。たとえば、セキュリティホールがある場合はすぐに対応すべきですが、変数名のリファクタリングは後回しでよいかも知れません。
レビューイは、そうした優先度を付けて指摘してあげると良いでしょう。それがないと、開発者は何から手をつければよいのか分からなくなります。
再レビューの際の注意点
再レビューの際には、指摘した課題が修正されているかを確認します。この時、別な指摘事項を発見してしまったら、レビューイに優しく指摘してください。そうしないと、無限にレビューが続くように感じられ、開発者は疲弊してしまいます。
まとめ
今回はコードレビューにおけるチェックリストを紹介しました。あくまでもたたき台ですが、ベースがあれば組織内でのコードレビュールール作成に役立つのではないでしょうか。
私たちの提供するCodeRabbitは、こうしたコードレビューをAIで支援するツールです。Linterレベルはもちろんのこと、より深いコードレビューをAIで自動化します。コードレビューに時間がかかっている、負担が大きいと感じている組織ではぜひCodeRabbitを導入してください。