ソフトウェア開発では、複数のチームで共同作業をする場面がよくあります。チーム構成人数が 1 人、2 人、それ以上へと増えるにつれ、問題が生じて創造的なワークフロー体系に支障が出始めます。そして多様な人々からなるチームにおいて、カルチャーを維持することが難しくなります。コードは日常的に組織全体の多くの人々の間で共有されるため、コードを扱うエンジニアグループは特にその問題の影響を受けやすい傾向があります。コードレビューを行うことは、コード関連のナレッジとベストプラクティスをチーム全体に普及させるのに役立ちます。この記事では、コードレビューが重要な理由と、コードレビューの実践を最適化する方法について説明します。

コードレビューとは？

ソフトウェア開発は、個々人の作品をコラボレーションという 1 枚のキャンバスの上にまとめたアート作品のようなものです。各開発者は、コードがキーボードを通じてあふれ出るようなフロー状態を実現するため、コードと 1 対 1 で取り組める邪魔されない時間を確保する必要があります。一方、チームが一丸となって作業するには、チーム内でのコラボレーションとナレッジ共有が非常に重要となります。コードレビューは、チーム全体を連動させるための基礎的な手段です。

コードレビューは、チーム全体を確実にコードと同調させるのに役立ち、この業界における重要なプラクティスとなっています。チーム形態には、データベース、サーバー、UI コードなど複数に渡って作業をするチームと、製品のフィーチャー領域ごとに作業するチームがあります。コードレビューは両方の形態のチームに役立ち、コードベース全体で会話や学習を促進します。

なぜコードレビューをする価値があるの？

1. エンジニアの休暇が可能に (休暇を取るべき) – 休暇は生産性を向上すると私は堅く信じています。ある領域のコードを所有しているエンジニアが 1 人だけの場合、その責任は就業時間外までつきまといます。チームメンバーの 1 人がクリティカルパスとなる場合、チームは脆弱化します。コードレビューはチーム全体にナレッジを分配します。

重要なサーバーを 1 台のハードドライブに構築することがありえますか? RAID システムでは、1 台のハードドライブが落ちた場合に備え、複数のハードドライブにデータを分散します。チームも同じように構築すべきではないでしょうか?

2. 新メンバーの生産性を即向上 – チームに新しいメンバーを採用する際、新メンバーがすぐにフルスピードで働けるように最大限の支援をすることが重要です。コードレビューは、仕事場でごく自然な形でコード構成、スタイル、アーキテクチャに関する会話を促進します。

新しいチームメンバーは、チームカルチャーに自然に効率良く溶け込むことができ、チーム参入コストを最小限に押さえます。

3. バグを発見 – コードレビューは、エンジニアとレビューアーがバグを発見するすばらしい手段です。扱いにくいコード領域の検証では、両者はロジックのフローを理解し、ソリューションを検証する必要があります。

4. チームカルチャーの改善 – 変化のないチームはありません。チームが製品に精力を注ぎ込むほど、より優れたエンジニアパラダイムが開発されます。コードレビューは、チームメンバー全員のエンゲージメントを高め、チーム全体から学んだベストプラクティスを広めるのに役立ちます。より有意義なテクニカルレベルでエンジニアは交流ができ、より優れた製品を生み出します。

コードにバグがないことが一番ですが、コードレビューを行えば新しい視点からロジックの欠陥を露呈し、コードを作成したエンジニアが把握していなかった事柄を見つけ出すことがよくあります。また、テストチームのメンバーは、コードベース内での課題発見に経験を持つ優秀なコードレビューアーです。

お勧めアドバイス

コードレビューを行う時は、レビューアーに集中させることが鍵です。大規模なコードベースの当たり障りのないレビューよりも、慎重を要するコード領域に集中してレビューする方がはるかに上手くいきます。言い換えると、

コードレビューは高くつくのでは？

(そんなことはありません… 以下をお読みください)

私はこれまで数多くのチームに所属してきました。必然的に、「コードレビューはチームを阻害する」というフィードバックが浮上します。実際、コードレビューは時間がかかります。しかし、その時間はチームとコードベースへの投資です。ここで重要なのは、コードレビューがチームを阻害するのではなく、チームを強化するようにすることです。

1. コードレビューの非同期実行をスケジュール化 – 中断は生産性を奪います。開発者の集中が途切れれば、完全な「フロー状態」に戻るのに少なくとも 15 分はかかります。中断を最小限に押さえるツールを使用しましょう。Git でプルリクエストを使えば、エンジニアは非同期でレビューをリクエストできます。レビューアーが自然な中断状態にある時に、より効果的なフィードバックを提供しやすくなります。

2. コードレビューのインライン表示 – 考えてみれば当たり前ですが、フィードバックは、問題のあるコード部分の近くに表示させるのが一番分かりやすいです。インライン コードレビューに対応したツールを使うと、レビューアーはレビューが実行されているコードに集中できます。さらに、コードを書いた開発者が、問題のあるコード部分でコメントを見ることができます。

3. 効果的なコードレビューのため全情報をひとまとめに – コードレビューはコードをレビューするだけではありません。効果的なコードレビューのためにレビューアーはオリジナルの課題、開発中に行われた関連する会話、フィーチャー ブランチのステータス、テスト結果、以前に実行されたコードレビューのメモにアクセスする必要があります。JIRA の新しい開発パネルは、コードレビューアーが必要な情報すべてをひとまとめにし、レビューを最適化します。

4. コードレビューを課題ワークフローに取り込む – チームによっては、課題ワークフローの一部としてコードレビューを強制的に実行したい場合もあります。Stash では、リポジトリのオーナーがマージ前に最低 1 回の承認を要求できます。JIRA では、課題ワークフロー内で Crucible を使用してコードレビューを要求できます。コードレビューが実行されていない場合、エンジニアは課題を解決済みにトランジションできません。

5. ステータスの可視化 – チームの生産性を妨害する最大の要因のひとつに、ステータスの問い合わせがあります。JIRA の新しいワークフローデザイナーにおける変更により、新規から完了までの作業のフローが見やすくなりました。新規ステータスは青、作業中のステータスは黄色、クローズステータスは緑で表示されます。

コードレビューはコード開発と大きく異なる作業です。コードレビューを管理している JIRA にステータスが表示されない場合、エンジニアリングチームのリードマネージャーといった関係者は、課題の作業進行状況を把握することが難しくなります。ここで、2 つのアジャイルボードを見てみましょう。

エンジニアチームがアクティブに実行中の作業がすべて表示されています。2 つ目のボードを見てみましょう。

ここでは、アクティブに開発中の課題と、レビュー待ちの課題を見分けることができます。最初のボードよりも 2 番目のボードの方が、プロジェクトマネージャーと開発マネージャーは開発ステータスに関してより多くのことが把握できます。解決方法が提案されている状態では、開発中の課題よりもレビュー中の課題の方がプログラムへのリスクがはるかに小さいです。

お勧めアドバイス

kick-ass development culture (キック・アスな開発カルチャー) の醸成についてアトラシアンの専門家から学びましょう!

まだ確信が持てないのですが、、、

それではアジャイルなアプローチを取りましょう。1、2 か月公平な目で試してみましょう。JIRA Agile で累積フローダイアグラムを使えば、コードレビューが実際にチームの足を引っ張っているものなのか簡単に分かります。とはいうものの、チームが新しいプロセスを学ぶのに少し時間がかかるでしょう。チームがある程度慣れたら、コードレビューについて振り返って検討してみましょう。費用が価値を上回るものであったとしても、それはそれで意味のある知識を得られることになります。

優れたツールはエンジニアの作業プロセスにコードレビューを自然に一体化させます。早速、JIRA または Git Essentials の無料トライアルに登録しましょう!

本稿は、Atlassian Blogs 日本語版の転載です。本文中の日時などはAtlassian Blogs 英語版での投稿当時のものですのでご了承ください。