アジャイルチームは、全体的にスキルのある自律編成型のチームです。ある程度のコードレビューも行います。コードレビューをすることで、開発者はコードベース、新しいテクノロジー、新しいテクニックを学べるため、スキルを伸ばすことに繋がります。
では、コードレビューとは一体何？
ひとりの開発者が課題での作業を終えると、他の開発者はコードに目を通し、以下のような疑問を考察できます：
- コードに明らかなロジックエラーがないか？
- 要件の観点から、すべてのケースが完全に実装されているか？
- 新しい自動化テストは新しいコードに対し十分か？既存の自動化テストをコードの変更に合わせて書き直す必要はないか？
- 新しいコードは既存のスタイルガイドラインに則っているか？
コードレビューはチームの現在のプロセスと統合すべきです。たとえば、チームでタスクブランチングワークフローを使用している場合、すべてのコードを書き終え、自動化テストを実行したあとにコードレビューを開始します。ただし、コードをアップストリームにマージする前です。これにより、レビュアーはマシンでは見つからなかったミスの確認に時間を割くことができ、貧弱なコードで開発のメインラインを汚染することも回避できます。
アジャイルチームにとっての利点
開発の手法に関わりなく、どんなチームでもコード・レビューの恩恵を受けられます。特に、作業がチーム全体に分散しているアジャイル・チームは、大きな利点に気が付くでしょう。コード・ベースの特定の部分を 1 人だけしか理解していない、ということを避け、コード・レビューにより、コード全体、チーム全体でのナレッジの共有を促進できます。
コードレビューでナレッジを共有
すべてのアジャイル・チームにおいて本質となるものは、強力な柔軟性です。チームのメンバー全員が、バックログから作業を切り離し、実行する能力を有しています。その結果、誰も「クリティカル・パス」とならないため、チームは新しい仕事にさらに打ち込むことが可能になります。フル・スタック・エンジニアがフロントエンドの作業とサーバー側の仕事に取り組めます。
コードレビューがより的確な見積もりを可能にする
見積もりセクションを思い出してください。見積もりはチーム作業であり、製品に関するナレッジがチーム全体に広がるにつれ、より正確な見積もりが可能になります。既存のコードに新機能が追加されたら、元の開発者は的確なフィードバックと見積もりを提供できます。さらに、コード・レビュアーにはそのコード・ベースで見られる複雑さ、既知の問題、懸念が開示されます。次に、コード・レビュアーとそのコード・ベースの元の開発者がナレッジを共有します。これを実践することで、複数のインプットを作成でき、これを最終見積もりに使用することで、より正確で信頼性の高い見積もりを作成できます。
コードレビューで休暇を取れる
誰もコードの特定部分について、唯一の接点にはなりたくないでしょう。同様に、他人が書いたコードのクリティカルな部分に深入りしたくないはずです。 特に緊急事態が発生したときは。コードレビュ―を行えばチーム全体でナレッジを共有できるため、チームの誰であっても統制をとり、引き続き舵を取ることができます。（Atlassian はメタファーが大好きです）ここでのポイント：クリティカルパスな開発者がいないということ、これは、チームの誰もが必要に応じて休みを取れるということです。バージョン管理システムに縛られているとしたら、コードレビューは自由を得るための最高の手段です。休暇のための自由、製品の他の分野での作業に時間を費やせる自由です。
コードレビューは新人エンジニアの良き
アドバイザー
アジャイルの特殊な一面は、新しいメンバーがチームに加わったとき、より熟練したエンジニアが新しいメンバーにアドバイスする点です。コードレビューはコードベースについて説明する際の良い教材になります。チームは往々にして、コードレビュー中に表示されるコードの隠れたナレッジを開示しないでいます。新鮮な目線の新しいメンバーは、新しい見解が必要な、危険で時間のかかる部分をコードベースから発見するものです。つまり、コードベースは新しい洞察と既存のナレッジをうまく調和する役割を果たします。
コードレビューとは、決して先輩のチームメンバーが若手のメンバーのコードをレビューするということではありません。コードレビューはさまざまな方向から実施するべきです。ナレッジに限界はありません! もちろんコードレビューは新しいエンジニアにとって役に立つものですが、かといって教育のためだけに行うものでもありません。
だが、コードレビューには時間がかかる！
もちろん、時間はかかります。ですが、時間を無駄にしているわけではありません。
最適化するための 3 つの方法を紹介します。
負担を共有
Atlassian では、多くのチームがコードベースへ投入する前にすべてのコードを 2 回レビューしています。オーバーヘッドだと思いますか？そんなことはありません。ひとりの作成者がレビュアーを選択するとき、チーム全体から幅広く人選します。どのエンジニアでも、2 人をインプットできます。プロセスが分散されるため、誰もボトルネックになることなく、チーム全体でコードレビューを順調に処理することができます。
マージ前にレビュー
アップストリームへのマージ前にコードレビューを必要とすることで、レビューされていないコードがマージされてしまうことを防ぎます。つまり、 午前 2 時になされたアーキテクチャーの疑わしい決定と、見習いが不正に使用したファクトリパターンを、継続的（かつ残念な）影響をアプリケーションに与える前に防ぐことができます。
仲間同士のプレッシャーをうまく利用する
チームメートからレビューされるとなると、開発者は確実にテストをパスする、優れた設計によるコードを作成しようとさらに努力するため、レビューもスムーズに進みます。このような心意気がコーディングプロセスをよりスムーズにし、最終的に速くなる傾向へとつながります。
開発サイクルのもっと早い段階でフィードバックが必要な場合は、コードレビューを待つべきではありません。早い時期の頻繁なフィードバックはより優れたコードの作成に役立つものなので、いつ何時でも他のメンバーを巻き込むことを躊躇してはいけません。作業をより確実に行えるだけでなく、チームメートのコードレビューもより良好になります。そうすれば、好循環が続くわけです！
