コードレビューが重要な理由 (時間の節約にもなります!)

結論: アーキテクチャに関する決定は適切であるべきで、「クリティカルパス」な開発者になりたくないと考えているならば、きっとコードレビューを気に入るはずです。

Dan Radigan Dan Radigan
トピック一覧

アジャイルチームは、全体的にスキルのある自律編成型のチームです。ある程度のコードレビューも行います。コードレビューを行うことで、開発者はコードベース、新しいテクノロジー、新しいテクニックを学べるため、スキルを伸ばすことにつながります。

では、コードレビューとは一体何?

1 人の開発者が課題における作業を終えると、他の開発者はコードに目を通し、以下のような疑問を検討します。

  • コードに明らかなロジックエラーが存在するか?
  • すべてのケースが完全に要件を実装しているか?
  • 新しいコードのための新しい自動化テストは十分か? コード変更を考慮し、既存の自動化テストを書き換える必要があるか?
  • 新しいコードは既存のスタイルガイドラインに準拠しているか?

コードレビューはチームの現在のプロセスと統合すべきです。たとえば、チームでタスクブランチングワークフローを使用している場合、すべてのコードを書き終え、自動化テストを実行したあとにコードレビューを開始します。ただし、コードをアップストリームにマージする前です。これにより、レビュアーはマシンでは見つからなかったミスの確認に時間を割くことができ、貧弱なコードで開発のメインラインを汚染することも回避できます。

アジャイルチームにとっての利点

開発の方法論にかかわらず、どんなチームでもコードレビューの恩恵を受けることができます。しかし、作業がチーム全体に分散しているアジャイルチームは、大きなメリットに気が付くでしょう。コードベースの特定の部分を 1 人だけしか理解していないということが避けられます。つまり、コードレビューにより、コード全体、チーム全体でのナレッジの共有を促進できるのです。

コードレビューでナレッジを共有

すべてのアジャイルチームにおいて、本質となるものは強力な柔軟性です。チームのメンバー全員が、バックログから作業を切り離し、実行する能力を有しています。結果、誰も「クリティカルパス」とならないため、チームは新しい仕事にさらに打ち込むことが可能になります。フルスタックエンジニアがフロントエンドの作業とサーバーサイドの仕事に取り組めます。

コードレビューがより的確な見積もりを可能にする

見積もりセクションを思い出してください。見積もりはチーム作業であり、製品に関する知識がチーム全体に広がるにつれ、より正確な見積もりが可能になります。既存のコードに新しいフィーチャーが追加されたら、元の開発者は的確なフィードバックと見積もりを提供することができます。さらに、コードレビュアーがそのコードベースで見られる複雑さ、既知の問題、懸念を開示します。次に、コードレビュアーとそのコードベースの元の開発者がナレッジを共有します。これを実践することで、複数のインプットを作成でき、これを最終見積もりに使用することで、より正確で信頼性の高い見積もりを作成できます。

コードレビューで休暇を取れる

誰もコードの特定部分について、唯一の責任者にはなりたくないでしょう。同様に、他人が書いたコードのクリティカルな部分に深入りもしたくないはずです。特に緊急事態が発生したときは。コードレビューを行えばチーム全体でナレッジを共有できるため、チームの誰であっても統制をとり、舵を取り続けることが可能です。ここでのポイント: クリティカルパスとなる開発者が存在しないということは、チーム全員が必要に応じて休みを取れるということです。バージョン管理システムに縛られているとしたら、コードレビューは自由を得るための最高の手段です。休暇のための自由、製品の他の分野での作業に時間を費やせる自由です。

コードレビューは新人エンジニアの良き
アドバイザー

アジャイルの特殊な一面は、新しいメンバーがチームに加わったとき、より熟練したエンジニアが新しいメンバーにアドバイスするという点です。コードレビューはコードベースについて説明する際の良い教材になります。チームは往々にして、コードレビュー中に表示されるコードの隠れたナレッジを開示しないでいます。新鮮な観点を持つ新しいメンバーは、新しい見解が必要な、危険で時間のかかる部分をコードベースから発見するものです。つまり、コードベースは新しい洞察と既存の知識をうまく調和する役割を果たします。

プロからのヒント:

コードレビューとは、決して先輩のチームメンバーが若手のメンバーのコードをレビューするということではありません。コードレビューはさまざまな方向から実施するべきです。ナレッジに限界はありません! もちろんコードレビューは新しいエンジニアにとって役に立つものですが、かといって教育のためだけに行うものでもありません。

だが、コードレビューには時間がかかる!

もちろん、時間はかかります。ですが、その時間は決して無駄にはなりません。

最適化するための 3 つの方法を紹介します。

負担を共有

アトラシアンでは、多くのチームがコードベースへ投入する前にすべてのコードを 2 回レビューしています。オーバーヘッドだと思いますか? そんなことはありません。作成者はレビュアーを選択するとき、チーム全体から幅広く人選します。どのエンジニアでも、2 人をインプットできます。プロセスが分散されるため、誰かがボトルネックになることなく、チーム全体でコードレビューを順調に処理できます。

マージ前にレビュー

アップストリームへのマージ前にコードレビューを必要とすることで、レビューされていないコードがマージされてしまうことを防ぎます。つまり、午前 2 時になされたアーキテクチャの疑わしい決定と、見習いが不正に使用したファクトリパターンを、継続的 (かつ残念な) 影響をアプリケーションに与える前に防ぐことができます。

仲間同士のプレッシャーをうまく利用する

チームメートからレビューされるとなると、開発者は確実にテストをパスする、優れた設計によるコードを作成しようとさらに努力するため、レビューもスムーズに進みます。このような心意気がコーディングプロセスをよりスムーズにし、最終的に速くなる傾向へとつながります。

開発サイクルのもっと早い段階でフィードバックが必要な場合は、コードレビューを待つべきではありません。早い時期の頻繁なフィードバックはより優れたコードの作成に役立つものなので、いつ何時でも他のメンバーを巻き込むことを躊躇してはいけません。作業をより確実に行えるだけでなく、チームメートのコードレビューもより良好になります。そうすれば、好循環が続きます。

次の記事
Release