コードレビューは、システムの品質向上やバグの早期発見に効果的な手法です。しかし、レビューアーの負担が大きく、常に高品質なレビューを行うのは体験だという意見も聞かれます。その結果、盲目的にレビューを通してしまったりすると、品質向上に対する効果が薄れてしまいます。
今回はコードレビューの品質を向上させるために注意したいポイントを、3つのカテゴリーに分けて紹介します。
- プロセスの改善
- レビュアー & レビューイーのスキル向上
- ツールの活用
プロセスの改善
コードレビュープロセス全体を見直し、プロジェクトメンバー全体の負担を軽減しましょう。
コードレビューの目的を明確化する
コードレビューが単なる「バグの発見」だけであれば、それは十分なテストスクリプトによってカバーされます。コードレビューでは、他にも可読性や設計の適切さにも注目しましょう。
可読性
コードを書いている本人だけでなく、他のプロジェクトメンバーがメンテナンスしやすいか、後からアサインされた新規メンバーが理解しやすいかを確認しましょう。
企業として何らかのコーディング規約を持っている場合、それはLinterなどでチェックすれば良いでしょう。とはいえ、Linterで定義したルールが窮屈すぎる場合、それを逸脱した書き方が出てしまう場合もあります。Linterに沿っていればバグが出ない、という訳ではないのでバランスが大事です。もしLinterに沿っていない場合には、なぜ従っていないのかを確認しましょう。
設計の適切さ
クラスやメソッドの独立性や、コンポーネントの設計の正しさを確認します。クラス設計が正しく行われていないと、再利用性が下がり、メンテナンス性が悪くなります。
RESTful APIであれば、その原則に正しく従っているかどうかを確認します。同様にルーティングのファイルが正しい位置に配置されているかなども確認します。
小さなプルリクエスト（PR）を心がける
レビューを受ける側としては、小さなプルリクエストを心がけましょう。大きな変更を一度に行うと、レビュアーの負担が大きくなり、見落としが発生しやすくなります。できるだけ1つのPRを「1つの目的」に絞り、多くても100〜300行程度に収めるのが理想です。
プルリクエストの説明文においては、その実装内容と齟齬がないようにしましょう。明記されていない機能が実装されていたり、逆に明記されている機能が実装されていない場合、レビューアーは混乱してしまいます。
IssueとPRをリンクさせているプロジェクトは多いですが、Issueの段階では実装量が見えていません。そのため、変更量も自然と大きくなります。Issueから見積もりを行い、機能を分割した上で実装を進めることで、PRのサイズを小さく保てるでしょう。
レビューのタイミングを適切にする
レビュアーが実装も行っている場合、細切れに送られてくるPRによって、自分の作業が中断させられます。集中力が途切れると、開発生産性が下がってしまい、結果的にプロジェクト全体の進捗が遅れることになります。また、他のメンバーが書いたコードを理解するのにも時間がかかり、大きなストレスになります。
レビューは夕方に行うなど、まとまった時間を確保すると良いでしょう。スキマ時間でのレビューは、見落としが発生しやすくなります。
レビューがボトルネックになって開発進捗が悪くなってしまう場合、ペアプログラミングやモブレビュー（Mob Review）を活用すると良いでしょう。PRを送る前に実施して、リアルタイムでフィードバックを得れば、PR時には見落としが少なくなります。
フィードバックの質を向上させる
プルリクエストに対するフィードバックとして良くないのは、抽象的な指摘です。レビューの多くはレビュアーよりも技術的知見が不足しており、指摘事項を正しく解釈できない場合があります。その結果、間違った修正を行ってしまい、コミュニケーション回数が増えてしまいます。これは双方にとって負担でしょう。
指摘はできるだけ具体的に、かつ改善方法を提示します。たとえば「 userList という変数名は activeUsers という名前の方が意図が明確です」といった具合です。また、攻撃的な表現を避けることも重要です。例えば「間違っている」という表現よりも、「こうすればもっと良くなるかも？」という表現の方が、相手にとって受け入れやすいでしょう。
多くの場合、良かれと思ったフィードバックであっても、受け手にとってはストレスです。面白いのは、こうしたフィードバックは人から行われるよりも、システムから行われた方がストレスが小さいということです。
レビュアーとレビューイーのスキル向上
2つ目のカテゴリーとして、スキル向上を挙げます。これはレビュアー（レビューする人）とレビューイー（レビューされる人）の双方に関わるポイントです。
レビューガイドラインを作成し、統一する
前回はスルーしたのに今回は指摘された、といった経験はないでしょうか。人によってレビューの厳密さが違ったり、その日の気分によって指摘が変わると、レビューを受ける側は混乱してしまいます。また、レビュー全体の対する信頼性が損なわれるでしょう。
例： コードレビューの基準 | google-eng-practices-ja
また、レビュアーが複数いる場合、人によって指摘が異なったり、真逆のことを指摘する場合もあります。これもレビューを受ける側にとっては混乱の元です。
そうした混乱を防止するために、レビューガイドラインを作成しましょう。例えば、変数名、関数の責務、エラーハンドリング、パフォーマンス、セキュリティなど、何をどうチェックするかを明文化し、チームで共有します。
良いレビューと悪いレビューの事例を共有する
過去に行ったレビューをチームで共有し、それを評価します。良いレビューの例と悪いレビューの例を比較し、改善点を見つけましょう。いわばレビューのレビューです。この時に大事なのは、レビューと人格を切り離して考えることです。
何が分かりやすかったのか（逆に分かりづらかったのか）をフィードバックすることで、レビュアーの改善につながります。
コードレビューのワークショップを開催
チーム内で、コードレビューに関するワークショップを開催しましょう。既存のプロジェクトに関するプルリクエストを利用して、どこをどう指摘するかを議論します。そうすることで、レビュアーとレビューイー、それぞれの視点に立って考えられるようになります。
オンライン上での対話の場合、その思考プロセスまでは可視化されません。そのため、フィードバックのコメントだけでは全体像が掴めなかったり、全体として冷たいイメージになってしまいます。ワークショップを通じて、お互いの考え方を理解し合いましょう。
ツールの活用
最後のカテゴリーとして、ツールの活用を挙げます。
静的解析ツールを活用する
静的解析ツールは、クライアントサイド・サーバーサイドの両面で導入できます。例えば、ESLintやPylintなどがあります。これらのツールを導入することで、コーディング規約に従っているかどうかを自動的にチェックできます。
また、サーバーサイドでのビルド前にチェックしたり、プルリクエストをレビューする前段階でチェックを行うこともできます。たとえばSonarQubeやCodacyなどがあります。これらのツールをGitHub ActionsやCI/CDと連携させ、自動実行することも可能です。
こうした静的解析ツールは、ルールに沿ってプロジェクトのコードを解析してくれます。便利ではあるのですが、あまり厳密に行うと、逆に可読性が落ちたり、その指摘事項の修正に時間を取られてしまうケースもあります。特に、プロジェクトの途中からの導入時には注意が必要です。
AIコードレビューツールを導入する
AIコードレビューツールは、静的コード解析ツールに似ていますが、AIによってより深いインサイトを得るのが特徴です。AIがコードを解析し、潜在的な問題点を指摘してくれます。AIは、大量のコードを学習しているため、人間が見逃すような問題点も見つけてくれるでしょう。
私たちが提供するCodeRabbitも、そんなAIコードレビューツールの一つです。GitHubやGitLab、BitBucketなどのリポジトリと連携し、PRに対してコードレビューを自動実行します。また、AIが提案する修正内容を適用することも可能です。
なお、AIコードレビューツールは、人によるレビューを完全に置き換えるものでは ありません 。一次レビューとして実行し、不備があれば修正を行います。この時点でルーチン的な指摘は自動化でき、人によるコードレビューを負担なく、スムーズに実行できます。
まとめ
本記事では、コードレビューの品質を向上させるために「プロセスの改善」「レビュアー & レビューイーのスキル向上」「ツールの活用」の3つのカテゴリーに分けてポイントを紹介しました。
コードレビューはシステム開発を滞りなく進めるための大事なステップですが、課題も多いです。そうした課題を解決し、効果的なコードレビューを行うために、ぜひ本記事を参考にしてみてください。
Discussion