コードレビューとは

コードレビューとは、開発者がコードをマージしてリリースする前に、コードの品質を保証したり改善したりするために行う、コードの相互レビューを指します。

コードレビューとその仕組み

コードレビューはピアレビューとも呼ばれ、コードベースの品質管理の役割を果たします。

コードレビューは、バグを特定し、コードの品質を向上させ、開発者のソースコード学習を支援するために設計された、コードの体系的な評価です。

ソフトウェア開発者がコーディングを完了した後に行われるコードレビューはソフトウェア開発プロセスにおいて重要なステップであり、フィーチャーブランチやmainブランチなどのupstreamブランチにマージされる前に、ソリューションと実装に関するセカンドオピニオンを得るために行われます。レビュアーは、バグやロジックの問題、未発見のエッジケース、その他の問題を特定する役割も果たします。

これにより、コード作成者とレビュアーの両者がセキュリティ上の欠陥を特定して品質基準を遵守し、プログラミング言語やフレームワークの垣根を越えて知識を共有し合うことができるようになります。レビュアーは、ドメインの専門家であれば、どのチームやグループに所属していてもかまいません。コード行が複数のドメインにまたがる場合は、2人の専門家がそのコードをレビューする必要があります。

コードレビューが重要な理由

堅牢なコードレビュープロセスを開発することで、継続的な改善の基盤ができ、不安定なコードが顧客にリリースされるのを防ぐことができます。コードレビューをソフトウェア開発チームのワークフローの一部とし、コードの品質を向上させ、すべてのコードが他のチームメンバーに確認されるようにしましょう。

コードレビューのプロセスは、組織全体に知識を広める上でも重要な役割を果たします。2022年グローバルDevSecOps調査に参加した開発者の76%は、こうした理由も含めて、コードレビューは「非常に価値がある」と回答しています。

コードレビューのメリット

知識の共有：ソフトウェアデベロッパーは、チームメンバーが変更したコードをすぐにレビューすることで、新しいテクニックや解決策を学ぶことができます。コードレビューは、ペアプログラミングがデベロッパーのスキルやアイデアの共有に効果的であるのと同じように、若手のデベロッパーが経験豊富なチームメンバーから知識を得る上でも重要な役割を担います。コードレビューにより、知識を組織全体に広めることで、誰かが障害の原因になることを防ぎます。全員がレビューし、フィードバックを提供できます。また、知識を共有することでチーム全員がそのトピックに関する背景知識を得られるため、誰かが休暇を取っても現場が困ることはありません。
バグの早期発見：機能がリリースされた後にバグを発見してパッチのリリースに取りかかる代わりに、デベロッパーは顧客が目にする前に問題を即座に発見して修正することができます。ユニットテストを通じてソフトウェア開発ライフサイクルの早い段階にレビュープロセスを移行することで、デベロッパーは知識が新鮮な状態で修正に取り組むことができます。ライフサイクルの最後までレビューが行われない場合、多くのデベロッパーはコードやソリューションを思い出すのに苦戦することになります。静的な解析は、ビジネスと顧客に価値を提供できる安価かつ効率的な方法です。
コンプライアンスの保持：デベロッパーはさまざまな背景を持ち、これまで受けたトレーニングも異なり、それが各自のコード作成方法に影響を及ぼします。チームにおいて標準的なコード作成方法の使用を望む場合、コードレビューを行えば、全員が同じ標準を遵守するように促進できます。これは、コードのコントリビューターが複数人いるオープンソースプロジェクトでは特に重要です。ピアレビューでは、変更をプッシュする前にメンテナーがコードを評価します。
セキュリティの強化：コードレビューは、特にセキュリティ専門家がターゲットを絞ったレビューを行う場合、高いレベルのセキュリティを実現します。アプリケーションセキュリティはソフトウェア開発に不可欠であり、コードレビューはセキュリティの問題を検出してコンプライアンスを確保するのに役立ちます。セキュリティチームのメンバーは、コードの脆弱性をレビューして開発者に脅威を警告できます。コードレビューは、セキュリティの脆弱性を検出する自動スキャンとテストを補完するのに理想的な方法です。
コラボレーションの向上：チームメンバーが協力してソリューションを作成すると、仕事に対する責任感と帰属意識が高まります。作成者とレビュアーは、協力し合いながら顧客のニーズを満たす最も効果的なソリューションを模索できます。情報のサイロ化を防ぎ、チーム間のスムーズなワークフローを保持するには、ソフトウェア開発ライフサイクル全体でコラボレーションを強化することが重要です。コードレビューを成功させるには、共同開発において強力な基盤となるコードレビューの意識をデベロッパーが構築し、共有することが重要です。
コード品質の向上：コードレビューは、高品質のコードとソフトウェアを確実に作り上げる上で欠かせません。コードベースに精通している人なら、自動テストで見逃す可能性のあるコード品質の問題に気づく可能性があります。これは、技術的負債を減らす上でも役立ちます。

コードレビューのデメリットとは？

出荷までの時間が増加：レビューにかかる時間は、リリースプロセスを遅延させてしまうことがあります。これは、レビュアーが作成者と協力して問題について話し合う必要があるためです。レビュアーの作業量によっては、作成者が希望する速度でレビューを完了できない場合があります。この問題は、自動テストを含むコードレビューツールを使用してエラーを検出することで解決できます。自動化されたツールは、単純なミスに煩わされることなく、より大きなソフトウェアエンジニアリングの問題に集中できるようにする効果的な方法であり、デベロッパーにより多くの余裕が生まれます。
他のタスクを一旦停止：デベロッパーは多くの場合、膨大な仕事量を抱えており、コードレビューを行うことで優先度の高い他のタスクに時間を割けなくなります。コードレビューを行って現在の作業を停止するか、まずは今の仕事を完了させるのか、二択を迫られる状況も珍しくありません。どの選択をするにせよ、組織内の何らかの仕事で遅延が発生します。この課題を軽減するには、レビュアールーレットや該当分野の専門家のリストを作成して、1人のデベロッパーのみにレビューリクエストの負担がかからないようにします。
大規模なレビューの場合、レビュー時間も長期化：大規模な変更のコードレビューを行う必要がある場合、デベロッパーはコードの調査に多大な時間を費やさなければならない可能性があります。大規模なコードレビューは評価が難しく、デベロッパーは早く完了させようと作業を迅速に進めるため、フィードバックの質が低下する可能性があります。インクリメンタルコード開発ではレビュアーが一度に大きな変更を行う代わりに小規模なコードの断片を複数回に分けて見ることができるため、こうした課題を防げます。

コードレビューの4つのアプローチ

こうしたデメリットの一部は、チームが最適なコードレビュー方法を選択することで最小限に抑えられます。コードレビューの一般的なアプローチには次の4つの方法があります。

ペアプログラミング

ペアプログラミングでは、コードの作成者（ドライバー）とコードのレビュー担当者（ナビゲーター）の2人の開発者がリアルタイムで協力します。ペアリングセッションはチームメンバーが協力しあいながら問題の最も効果的な解決策を特定できるため、開発チームに人気があります。チームメンバー同士で知識を共有し、アイデアを出しあいながら専門知識を活用することで困難な状況もすばやく克服できます。

ペアプログラミングのメリット

知識の伝達
情報のサイロ化の防止
複雑な問題の解決
士気の高まり
より多くのバグ検出
リモートで実行可能

ペアプログラミングのデメリット

時間がかかる
過剰に使用されるリスク
測定が困難

肩越しレビュー

肩越しレビューでは、作成者とレビュアーの2人の開発者が対面またはリモートでチームを組んで画面を共有し、作成者が完了した変更提案を説明して、そのソリューションを選択した理由を説明します。レビュアーは、ペアリングセッション中のチームメンバー同士のコラボレーション方法と同様、質問や提案を行います。作成者はレビュー中に小さな変更を加え、大きな修正の場合はメモを取り後から行えます。

肩越しレビューのメリット

簡単に実行・完了可能
リモートで対応可能
ペアプログラミングよりも高速

肩越しレビューのデメリット

レビュアーがコードから切り離されている
作成者のペースでレビューが進められる
客観性の欠如
変更が行われたかを確認できない
測定が困難

ツールアシストレビュー

チームは、時間を節約して最高品質のコードを確実に出荷できるようにツールを使用できます。ツールアシストレビューでは、変更されたファイルを自動的に収集して差異を表示したり、フィードバックを提供したり、コメントを介して会話を行ったり、静的アプリケーションセキュリティテスト（SAST）などの機能で脆弱性の特定・修復をしたりできます。

ツールアシストレビューは、他の種類のレビューの補助として考えるようにしましょう。自動化ツールは、コード標準を適用して脆弱性を特定し、メトリクスを収集してファイルを収集するのに効果的な方法ですが、一部のチームではツールに完全に依存し、チームメンバーを関与させずにコードレビューを完了させたくなるかもしれません。ツールはあくまでもコードレビューの延長であり、プロセスの補完的存在以上のものではありません。

ツールアシストレビューのメリット

メトリクスの収集が容易
自動化されたツールによりデベロッパーの負担を軽減

ツールアシストレビューのデメリット

ツールのメンテナンスが必要
高コスト
チームメンバーによるレビューが必要

メール回送

メール回送は、多くの場合小規模な問題やコードで使用されます。これはメールやソースコード管理システムを介して実行できます。メール回送では、作成者がコード変更を含むメールをレビュアーに送信します。デベロッパーの肩越しに行うレビューと同様、メール回送は簡単に実装でき、作成者に変更方法を教えるための長時間の学習や指導は必要ありません。

メール回送のメリット

簡単な実装と完了
リモートで非同期のレビューを実行
SCMを介した自動レビュー

メール回送のデメリット

ファイルの収集に時間がかかる
会話を追いかけるのが大変
レビューの終了日が明確でない
変更が実装されたかを確認できない
測定が困難

コードレビューのベストプラクティス

**生産性が妨げられないようコードレビュー量に制限を設ける。**レビュー時間を1時間以内としたり、レビューするコードを200行以内に収めるなど、チームに適した制限を設定し、それを守るよう奨励します。
チームの新メンバーや上級メンバーを含む全員をレビュープロセスに含める新メンバーはコードレビューを通じて、チームの上級デベロッパーのコードをレビューできるだけでなく、自分のコードも上級デベロッパーにレビューしてもらえます。そのため、新メンバーがコードベースに迅速に対応できるようになる効果的な方法です。コードレビュープロセスに全員を含めることで、お休み中のメンバーやチームを離れるメンバーが出た場合の調整も容易になります。
**コードレビューのリクエストをチームに配布する。**少数のデベロッパーにコードレビューリクエストの大部分がまわされるというのはよく発生しがちな状況ですが、これはデベロッパーにとっても、チームの他のメンバーにとっても、コードベースにとっても、長期的に見て良い結果をもたらしません。該当分野の専門家のリストや、レビュアールーレットを作成すると、このような状態を回避できます。
**質問をして、役に立つ情報を提供する。**ほかの人のコードをレビューするときは、お互いに学びを得られるよう最善を尽くしましょう。なぜ相手は、あなたのいつものやり方と違う方法を選んだのでしょうか？率直に質問しましょう。コード改善のために提案したい事柄がありますか？コメントで、その提案をした理由を忘れずに伝えましょう。コメントは両者の学びに役立つだけでなく、時間の節約にもなります。