June 4, 2020

コードレビューの実施方法

By Johan Karlsson

*本記事はPerforce Software社の以下のブログ記事(2020年6月4日時点)の参考訳です。
 How to Do Code Reviews
*ブログの内容は更新されている可能性があります。また、記事内のリンク先は別途記載がない限りは英語ページになります。

コードレビューは、簡単でシンプルな作業であると考えられがちです。しかし、必ずしもそうではありません。本ブログでは、コードレビューとは何か、そして実施する際にどのような課題があるのかを概説します。また、大規模な開発においてコードレビューを行うためのヒントもご紹介します。

コードレビューとは

コードレビューとは、開発チームのひとりまたは複数人によって行われる、プログラムを構成するソースコードの確認作業のことを言います。新しいコードや変更されたコードはすべて、レビューの対象となるのが一般的です。

問題点をできる限り早期に発見し修正することでコードの品質を向上させる。そのために、コードレビューは重要な役割を果たします。そして、開発中のソフトウェアの一貫性と信頼性を確保するうえでも役立ちます。

コードレビューは、生産性の向上にも貢献します。問題を早期に発見することで修正にかかるコストを削減できますし、開発チームメンバーは互いの書いたコードをチェックすることで自分の担当範囲外のスキルや知識を得て、どのように製品ができているのかを共有できるようになります。

コードレビューがDevOpsにとって重要な理由

コードレビューは、コードの質と開発スピードを両立させ、製品価値の向上を助けることができるという点で、DevOpsにとって重要な作業になります。

コードレビューには様々な実施方法があります。DevOps開発で実施する際にも、製品ライフサイクルのどのタイミングで行われるかによって、実施方法は変わってきます。

コミット前のコードレビューであれば、例えば以下の様な流れになると考えられます。

  1. コーディング
  2. レビュー
  3. コミット
  4. 完了

そして、コミット後のコードレビューであれば、その流れは以下の様になります。

  1. コーディング
  2. コミット
  3. レビュー
  4. 完了

つまり、コードレビューはコードを共有リポジトリにコミットする前に行うこともできれば、コミットした後に行うこともできるし、前後の両方で行うこともできるのです。製品の開発フェーズに「ビルド」がある場合は、そのビルドの前でコードレビューを行うか、それとも後で行うかも検討する必要があります。

コードレビューの主な課題

コードレビューの難しい点と言えば、最適な実施方法の選択がありますが、それ以外にも多くの課題があります。特に、大規模な組織におけるコードレビューでは多くの課題に直面することになると思います。このような課題を解決するために作られているのが、コードレビューツールです。

【動画】How to Do Code Reviews at Massive Scale for DevOps

開発規模

少人数の開発チームやプロジェクトにおけるコードレビューはシンプルな作業かもしれません。例えば、自分が書いたものを同僚に見てもらい、口頭でコメントをもらうだけで済む場合もあります。

しかし、チーム、プロジェクト、ブランチ、パスが増え、大規模な開発環境になると、コードの品質や一貫性、開発スピードのバランスを取りながら“良い”コードレビューを実施するのが難しくなってきます。ここで言う開発規模とは、開発に関わっている人の数だけではなく、下の表にあるように、プロジェクト、ブランチ、パスの数も合わせて考える必要があります。あなたの携わっている開発規模はどの程度でしょうか?

コードレビューの規模を決める要素

チームメンバーの分散

開発チームのメンバーが離れた場所に分散している場合のコードレビューも難しいものです。そのような状況では、何がレビュー済みかを把握することはかなり困難となるでしょう。コードレビューに適したツールの力を借りない限り、コードレビューのプロセスにおいて多くの無駄な作業が発生することになりかねません。

ミスによって生じる損害

コードレビューの難しさは、何を開発しているかによっても変わってきます。例えば、チップを設計している場合、テープアウト期間(設計ライフサイクルの最終段階)でのミスは非常に高くつくため、絶対に避けなければなりません。

派生の管理

大規模な開発環境でのコードレビューをより複雑にするもう一つの要素は“派生”です。製品の派生が多ければ多いほどに、コードレビューのプロセスで発生するリスクも複雑なものになります。大規模な開発環境で、これら全てを考慮して作業することは簡単ではありません。

トレーサビリティ

トレーサビリティの確立も、コードレビューの課題です。何がレビュー済みなのか、誰によってレビューされたのか、そして、どのような議論を経て解決に至ったのかを、どのようにして証明するか。この点は、規制の厳しい業界で特許権が議論になる際、非常に重要になってきます。また、新たな問題の発生源を特定するうえでも重要です。

法規制

自動車業界のように規制の厳しい業界では、コードレビューをどのように行うべきかが既になんらかの規格で定められているかもしれません。この場合、そのルールに従わないという選択肢はありません。しかし、より効率的なコードレビュープロセスを実施することで、競合他社よりも効率的に準拠する方法を見つけられる可能性はあります。

アジリティ

開発に限らず、何かを大規模に実施するなかで、変化に素早く適応できる柔軟性(アジリティ)を保ち続けることは簡単ではありません。コードレビューのプロセスは、開発の足を引っ張るものではなく、"スピードを上げるもの"になるようにしなくてはなりません。

小さなネズミを恐れるゾウという例えで考えてみましょう。変化の激しい業界において、大企業(ゾウ)は動きの素早い小規模な競合他社(ネズミ)とどのように競えばいいのでしょうか?大規模な開発をしながらも、小さなライバル達と同じくらい速くそして柔軟に変化に対応するにはどうすればいいのでしょうか?

[関連ブログ記事:Code Review Best Practices]

DevOps実現に向けた大規模開発でのコードレビュー実践方法

ここでは、その方法をご紹介します。

1. 最適なツールを選ぶ

開発チームに適したコードレビューツールを選ぶことが重要です。

最適なツールとは:

  • 待ち時間を発生させない
  • 現状を可視化できる
  • ワークフローを用いた自動化やそのほかのDevOpsツール(バージョン管理ツールやビルド自動化ツールなど)との連携ができる
  • フィードバック機能と自動通知機能が備わっている

どれも、大規模な開発環境でコードレビューを実施するうえでの課題を克服するには不可欠です。

例えば、Perforce Software社の「Helix Swarm」は、同社のバージョン管理ツール「Helix Core」用のコードレビューツールです。このツールは、上記の最適なツールに求められる条件すべてを満たしており、開発チームの作業効率の最大化に役立ちます。

2. コードレビューはスキルであると認識する

コードレビューには、コミュニケーションが大切です。製品の全体的な品質を向上させるためには、コードレビューにおいて明確なフィードバックをすることが重要になってきます。

コードレビューのプロセスを通して、開発チームのメンバーが常に必要な情報を共有し、何が起こっているか分かるようにしておくことも重要です。しかし、これに関しては、タイムゾーンが異なる場所で働いているメンバーがいる場合は難しくなります。チームの全員がオフィス外で仕事をしている場合などは特にです。フィードバックを分かりやすく伝えられるかどうかが、効率的なコードレビューの鍵となります。

コードレビューはスキルの一つと捉えるべきです。得意な開発チームもあれば、苦手なチームもあるでしょう。フィードバックとレビューのスキル向上のためのトレーニングには、ぜひ投資しておきましょう。

Helix Swarmを使用すれば、開発チームのメンバーが全員、異なる場所で働いていたとしても、チームのコミュニケーションやコラボレーションを改善し、コードレビューのスキルを向上させることができます。

3. Single Source of Truthを確保する

バージョン管理において"Single Source of Truth"(信頼できる唯一の情報源)の確保は重要ですが、それはコードレビューでも変わりません。

必要なのは、開発規模に応じて柔軟に拡張可能で、チームの全員が常に最新バージョンのコードで作業できるようにする、グローバルなレビューシステムです。このようなシステム無しで開発プロジェクトの全体像を把握することは、困難を極めるでしょう。特に100人、1000人規模のチームで作業している場合はなおさらです。変更の準備が整った際には、できるだけ早くその変更を反映させてビルドしたいものです。そのためには、ビルド環境をしっかりと整備しておくことが重要です。

Helix Swarmを使えば、小規模な開発環境でのコードレビューを効率化し、さらにはより大規模な環境にも柔軟に対応できるようになります。また、各チームメンバーが今、何をしているのか、これから何をしようとしているのかを可視化し、変更を迅速にコミットできるようになります。

4. ツールを連携させる

DevOpsな大規模環境でコードレビューを行うのであれば、複数のツールの連携が不可欠になります。コードレビューツールとバージョン管理ツールだけ使えば済むということはありません。

例えば、Jenkinsを利用して、ビルドの自動化をしている場合もあります。JenkinsをHelix SwarmやHelix Coreと連携させることで、CI/CDの効率的なワークフローを実現できます。

各チームメンバーがレビューを受ける必要のあるコードをサブミットする。Jenkinsからビルドの成功とテスト合格の報告を受けると、Swarmがレビューと承認待ちの変更がある旨を通知する。変更が承認されると、コードが自動的にデプロイされる、といった流れになります。

Helix Swarmで実現する、より良いコードレビュー

Helix Swarmを使用することで、コードレビューをさらに良いものにすることができます。

以下のようなコードレビューの課題をHelix Swarmは解決します。

  • 開発規模
  • 分散開発
  • ミスによって生じる損害
  • 派生の管理
  • トレーサビリティ
  • 法規制
  • アジリティ

チームのコミュニケーションを今以上に円滑にし、"Single Source of Truth"を手に入れることができます。また、Helix Swarmは、Helix Coreのために用意されたコードレビューツールであり、JenkinsJiraをはじめとする様々なツールとも連携させることもできるため、コードレビューのワークフローをスムーズなものにします。

コードをレビューして、コラボレーションを加速させ、さらには、ワークフローの自動化から進捗のモニタリングまで。実現してみようという気になりましたでしょうか。もしそうであれば、ぜひ今日からでも、Helix Swarmを使ってみてください。

すでにHelix Coreをお使いですか?

Helix Swarmは無料でダウンロードして、ご利用いただけます。

Helix Swarmをダウンロード

Helix Coreをまだお使いではありませんか?

Helix CoreとHelix Swarmは、5ユーザー、20ワークスペースまで無料でお試しいただけます。

Helix Core + Helix Swarmを使ってみる