コードレビューとは

ピアレビューとも呼ばれるコードレビューは、コードベースの品質保証として機能します。

コードレビューは、コードを体系的に評価し、バグを特定し、コード品質を向上させることを目的とし、開発者がソースコードを理解する支援をします。

ソフトウェア開発者がコーディングを完了した後で行うコードレビューは、解決策や実装を上流側のブランチ (フィーチャーブランチやメインブランチなど) にマージする前に、セカンドオピニオンを得るためにも重要なステップです。バグの特定、ロジックの問題点、例外的なケースなどの問題を特定する第二段階として、レビュアーが機能します。

このプラクティスは、コードの作成者とレビュアーが共にセキュリティの欠陥を見つけ、品質基準に準拠し、プログラミング言語やフレームワークを超えて知識を共有できるようにします。レビュアーは、ドメインの専門家でありさえすれば、どのチームメンバーやグループの人でも構いません。もしコードが複数のドメインにまたがっている場合には、2人の専門家でコードをレビューすべきです。

強力なコードレビュープロセスが構築できれば、継続的な改善の基盤が築け、不安定なコードが顧客に提供されてしまうことを防止できます。コード品質を向上させ、あらゆるコードが別のチームメンバーによって確認済みだと保証するためにも、コードレビューをソフトウェア開発チームのワークフローの一部に組み込むべきです。

コードレビュープロセスは、組織全体で知識を共有するために重要なプロセスです。事実、2022 年度のグローバルDevSecOps レポートにご回答いただいた開発者の76%が、コードレビューを「非常に価値があるもの」だと回答しています。

• 知識の共有：チームメンバーが変更を加えた際に、直ちにソフトウェア開発者がコードをレビューすることで、ソフトウェア開発者はそこから新しいテクニックや解決策を学べます。コードレビューは、開発の初心者が上級メンバーからコーディングを学ぶ上で効果的です。これは、ペアプログラミングによって開発者間で効果的にアイデアやスキルを共有できるのと同様です。組織全体で知識を広めることにより、コードレビューは誰か一人が失敗の原因になることがないようにし、レビューに加わる人なら誰でも、フィードバックを提供できます。チーム全員がトピックについての背景知識を共有できるので、チームメンバーも休暇が取れやすくなります。
• 早期バグ検出：製品のデリバリー後にバグを発見してしまい、パッチリリースに奔走するようなことはなく、開発者は顧客が目にする前に、速やかに問題を検出して修正できます。ソフトウェア開発のライフサイクルの早い段階でユニットテストを通じてレビューを行うと、開発者は最新の知識を取り入れた上でバク修正に当たることができます。レビューをライフサイクルの最後に実施してしまうと、開発者は以前に書いたコードやその時の考えを忘れてしまい、修正が難しくなることがあります。事業や顧客の価値を満たすには、静的解析が安価で、効率的な方法です。
• コンプライアンスの維持：開発者の経験や積んできたトレーニングはさまざまで、そういった要素がコーディングのスタイルに影響します。チーム内で標準的なコーディングスタイルを決めておけば、コードレビューはメンバー全員がその基準を守る助けになります。これは、複数の人ががコードを提供するオープンソースのプロジェクトにおいてとりわけ重要です。ピアレビューは変更をプッシュする前に、コードベースの保守者・管理者を巻き込みコードを評価します。
• セキュリティの強化：コードレビューは、とくにセキュリティ専門家が的を絞ったレビューを行う場合に、高度なセキュリティを実現します。アプリケーションセキュリティはソフトウェア開発の要であり、コードレビューはセキュリティ上の問題の検出や、コンプライアンスの遵守を確実なものにしてくれます。セキュリティチームは、脆弱性のコードレビューを行ない、開発者に脅威を警告できます。コードレビューは、セキュリティの脆弱性を検出する自動スキャンやテストと合わせると、優れた威力を発揮します。
• コラボレーションの強化：チームがひとつの解決策に向かって協力すると、各メンバーはそれぞれの仕事により大きな責任を感じ、強い帰属感を持つようになります。コード作成者やレビュアーは、顧客のニーズに応えられる最も効果的な解決策を探し出すために協力し合います。情報のサイロ化を防止し、チーム間でシームレスなワークフローを維持するためには、ソフトウェア開発ライフサイクル全体でつねに協力体制を強化することが大切です。また、コードレビューを成功させるためには、開発者によるコードレビューのマインドセット（外部サイト）の構築も大切です。なぜなら、これは、共同開発の強靭な基盤となるからです。
• コード品質の向上：コードレビューは、高品質なコードと高品質なソフトウェアをリリースする上で重要な手法です。自動化されたテストでは見逃してしまうコード品質の問題も、コードベースを知る人が見たらそれに気付くことができます。コードを熟知する人ならば、技術的負債の低減も可能です。

• 顧客へのコード提供の遅延：レビュアーがコード作成者と問題について話し合い、協力しなければならないため、レビューにかかる時間が、リリースプロセスを遅延させる場合もあります。またレビュアーの仕事量によっては、コード作成者が望むほど早くレビューを完了することができない場合もあります。しかし、これらの課題は、エラー検出自動化テストを含む、コードレビューツールを使用すれば克服可能です。自動ツールを使用すると、開発者の時間が効果的に有効化できます。開発者は、単純なコードスタイルのミスを修正するかわりに、より重要なソフトウェアエンジニアリングの問題に集中できるからです。
• 他の重要な作業に支障をきたす：開発者は通常多大な仕事量をこなしつつ作業に当たらねばならず、コードレビューは、他の重要なタスクから注意を引き離してしまうことがあります。チームメンバーは、自分のタスクを完了させるか、それともコードレビューを行うために、作業の手を止るか、の決断を迫られることがあります。この場合、どちらを選択しても、組織内のどこかで、作業が遅れてしまいます。こんな頭痛のたねを解消するため、チームメンバーはレビュアールーレットを使用したり、ドメインエキスパートのリストを作って、ひとりの開発者がレビューの大量依頼で圧倒されてしまうことがなくなるようにしたりします。
• 大規模コードのレビューは時間を要する：開発者が大規模な変更点のコードレビューを行なう場合には、コードの確認にかなりの時間を要します。。大規模なコードレビューは評価が難しく、開発者は早く終わらせようと急いでしまうため、フィードバックの品質が低下することがあります。そのため、レビュアーが大規模な変更を一回で確認するのではなく、コードを小さな部分に分けてレビューするインクリメンタルなコード開発を行なうことにより、問題を予防できます。

所属チームに最適なコードレビュー方法を選択できれば、既述のデメリットが最小限に抑えられます。ここでは、一般的なコードレビューの 4 つのアプローチをご説明します。

ペアプログラミング

ペアプログラミングとは、2 名の開発者がリアルタイムで協力し、1人 (ドライバー) がコードを書き、もう1人 (ナビゲーター) がコードをレビューするというものです。ペアリングセッションは開発チームに人気があります。チームメンバーで協力し合うことで、課題に対する最適な解決策を見つけられるからです。メンバー同士で知識を共有し、一緒にアイデアを出し合うことで、迅速に問題を解決できます。

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

• 知識の共有情報サイロ化の防止複雑な問題の解決
• 士気の向上
• より多くのバグ検出
• リモートでも実施可能

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

• 時間がかかる
• 過度に使用される可能性がある
• 効果の測定が難しい

対面での、Over-the-shoulder（肩越し）レビュー

「肩越し」レビューでは、2人の開発者（コード作成者とレビュアー）が対面、またはリモートで画面を共有しながら、コード作成者が変更点を提案し、解決策の理由を説明します。レビュアーは質問したり提案をします。これはペアプログラミングのセッションに似た協力の仕方です。コード作成者はレビュー中に小さな変更を実施し、より大きな修正点は後日用にメモをとります。

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

• 導入と完了が簡単
• リモートでも実施可能
• ペアプログラミングよりも速い

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

• レビュアーがコードを自分で操作・確認する機会が少ないレビュアーとコードとの間に距離ができる
• レビューの進行が作成者のペースに依存
• 客観性の欠如
• 変更が実際に行われたかの確認がない
• 効果の測定が難しい

ツールを利用したレビュー

時間を節約し、最高品質のコードを顧客に提供する目的で、チームでツール使用を決定することもあります。ツールを利用したレビューでは、変更を加えられているファイルを自動的に収集し、その差異を表示を表示したり、コメントを通じてフィードバックや会話をしやすくしたり、静的アプリケーションセキュリティテスト（SAST）を取り入れて脆弱性を特定・修正する手助けをすることができます。

ツールを使ったレビューは、他のレビュー方法を補完するものと考えるのが良いでしょう。自動化ツールはコード標準を遵守し、脆弱性の特定、メトリクスの収集、ファイルの収集などを行なう際に効果的な手段です。しかし、チームメンバーの関与を完全に排除してツールだけに頼るのは危険です。あくまでツールは、コードレビューの延長線上にあり、プロセスを強化させるための補助的な手段と考えるべきです。

ツールを利用したレビューのメリット

• メトリクスの収集が簡単
• 自動化されたツールにより、開発者が他の重要な作業に集中できる

ツールを利用したレビューのデメリット

• 開発者によるツールの維持
• 高価
• チームメイトのレビューも必要

メールの回覧

メールの回覧は、軽微な問題や小さなコードの変更に使われることが多いです。これはメールか、ソースコード管理システムを通じて行われます。メール回覧では、コード作成者はコード変更点を含んだメールをレビュアーに送ります。メール回覧は、容易に導入でき、コード作成者に変更方法を教える難しい学習曲線や指導段階がが不要であるため、対面での「肩越し」レビューに似ています。

メール回覧のメリット

• 導入と完了が簡単
• リモートでの、非同期レビューを容易にする
• SCM を使った自動化レビュー

メール回覧のデメリット

• ファイルの収集に時間がかかる
• 会話を追うのが困難
• レビュー終了期日が決められない
• 変更が実際に行われたかの確認がない
• 効果の測定が難しい

• 効果的なコードレビューセッションを維持するための制限設定：例えば、1時間以内や200行のコードまでなど、チームに合った制限を見極め、その制限を守るように促します。

• プロセスには、新人からベテランまで、チームメンバー全員を関与させる：コードレビューは、チームの新人がコードベースに慣れる素晴らしい方法であり、経験豊富な開発者からコードのレビューを受けたり、自分のコードをレビューしたりすることで学びが得られます。チーム全員がコードレビューのプロセスに参加することで、誰かが休暇に入ったりチームを離れたりしたときにも、プロセスをスムーズに調整しやすくなります。

• プロセスには、新人からベテランまで、チームメンバー全員を関与させる：新メンバーはコードレビューを通じて、チームの上級デベロッパーのコードをレビューできるだけでなく、自分のコードも上級デベロッパーにレビューしてもらえます。そのため、新メンバーがコードベースに迅速に対応できるようになる効果的な方法です。コードレビュープロセスに全員を含めることで、お休み中のメンバーやチームを離れるメンバーが出た場合の調整も容易になります。

• コードレビューのリクエストをチーム内で分散させる：一部の開発者がコードレビューリクエストの大部分を受けがちですが、それはレビューを請け負う開発者や他のメンバー、そして長期的にはコードベースにとっても良いことではありません。この問題を回避するため、専門家リストを作成したり、レビュアールーレットを導入したりするとよいでしょう。

• 質問をし、役立つコンテキストの提供：他人のコードをレビューするときは、レビュープロセスからお互いが学べるように心がけてください。自分だったらこうはしないのに、どうして違う方法を採用したのかわからない、といったことはありませんか？そんなときこそ、質問しましょう。コードを改善する提案がある場合は、その理由もコメントで伝えるようにしましょう。そこからお互いが学べるだけでなく、時間の節約にもつながります。

ソフトウェア開発のプロセスにコードレビューを組み込むことで、組織は厳しい納期に対処しつつも、製品の品質を損なわずに進めることができます。コードの作成者とレビュアーとの「対話」は、開発プロセスの強固な基盤を築き、コード品質の向上につながります。

コードレビューを取り入れ、イノベーション、コラボレーション、そしてセキュリティが導くソフトウェアソリューションの未来への一歩を踏み出しましょう。