コードレビューから学んだ 5 つの教訓

チームメンバーがこう言うのをよく聞きます:

「このプロジェクトのコードレビューは時間の無駄です。」

「コードレビューをする時間がありません。」

「意地悪な同僚のせいで立ち上げが遅れました。」私のコードはまだ審査されていません。」

「同僚が私にコードを変更するように頼んだことを信じられますか?なぜ、このようなエレガントで完璧なコードを変更する必要があるのですか?」

検閲?

プロのソフトウェア開発者にとって最も重要な目標の 1 つは、仕事の品質を継続的に向上させることです。しかし、チームワークを通じてのみ、努力を 1 か所に集中してソフトウェアの品質を向上させることができます。コード レビューは、この目標を達成するための最も重要な方法の 1 つです。特に、コード レビューでは次のことが可能になります。

別の観点から欠陥とより良い解決策を発見します。

あなたのコードに詳しい人が少なくとも 1 人いることを確認してください。

上級開発者のコ​​ードを参照して、新入社員のトレーニングを支援します。

知識の共有を促進します。

レビュー中に他の人に発見されるのを避けるために、開発者がより良いコードを書いてコード内の問題を解決するよう動機づけます。

コードレビューは徹底しなければなりません

しかし、実際にコードレビューを徹底して時間とエネルギーを費やすことができなければ、上記の目標を達成することは困難です。

私の意見は、元の開発時間の約 25% をコード レビューに費やす必要があるということです。たとえば、開発者がプロ​​グラムの実装に 2 日かかる場合、レビューには約 4 時間かかるはずです。

もちろん時間は最も重要なことではありません。重要なのは、コードを正しくレビューできるかどうかです。レビューしているコードを理解する必要があります。これは、構文を知る必要があるだけでなく、コードがどのようにアプリケーションのコンテキストに適合し、コンポーネントまたはライブラリの一部になるのかも理解する必要があることを意味します。コードの各行の意味を理解できない場合、レビューは十分ではなく、あまり価値がありません。これが、適切に実行されたコード レビューを迅速に完了することがほとんど不可能である理由です。サードパーティ API が正しく使用されていることを確認するために、特定の関数をトリガーするさまざまなコードを調査する時間が必要になるためです。

レビューするときは、コードの欠陥やその他の問題を探すことに加えて、次のことも確認する必要があります:

必要なテストをすべて含める。

適切な設計ドキュメントが作成されています。

テストやドキュメントを書くのが得意な開発者でも、コードを変更するときにコードを更新することを忘れてしまいます。コードレビューでは、この情報が時間の経過とともに無駄にならないようにする必要があります。

過度のコードレビューを避けてください

開発者は、レビュータスクのバックログを解消するために懸命に取り組む必要があります。これを行う 1 つの方法は、午前中にコード レビューを行い、独自の開発作業を開始する前にレビューを完了させることです。もちろん、昼食の前後や一日の終わりにコードをレビューすることもできます。全体として、コードを重荷としてではなく、日常業務の一部として扱う必要があるため、次のようなことは避けるべきです。

レビュー タスクのバックログに対処する時間がない。

レビューが不完全なためリリースが遅れました。

無関係なコードを愚かにもレビューしましたが、渡された後、認識できないほど変更されていました。

時間の関係で急いで手続きを進めました。

レビュー可能なコードを書く

コードのバックログが制御不能になったとき、責任を負う必要があるのはレビュー担当者だけではありません。たとえば、同僚が大規模なプログラムに乱雑なコードを追加するのに 1 週​​間を費やした場合、リリースされたパッチのレビューは困難になり、内容が多すぎて理解したり掘り下げたりすることができなくなります。コードの目的や基本構造さえも不明瞭です。これはコードを書くことではありません。

レビュー可能なコードを書く前に、いくつかの準備をする必要があります。アーキテクチャに関して難しい決定を下す必要がある場合は、まずレビュー担当者と話し合うのが最善です。これにより、コードは、何を達成したいのか、どのようにそれを達成する計画があるのか​​を事前に知っているため、コードのレビューと理解が容易になります。これにより、後でレビュー担当者がまったく異なるより良いアプローチを思いついた場合に、コードの大部分を書き直す必要がなくなります。

プロジェクトのアーキテクチャは設計書に詳しく記載する必要があります。これは、新しいプロジェクト スタッフが既存のコード ベースをより迅速に理解できるようになり、レビュー担当者の仕事をより適切に行うのにも役立つため、重要です。さらに、単体テストにより、レビュー担当者は個々のコンポーネントの使用法をより深く理解できるようになります。

パッチにサードパーティのコードも含まれている場合は、別途提出してください。想像してみてください。9,000 行の jQuery がコードの途中に挿入された場合、レビューの難易度は大幅に増加しますか?

レビュー可能なコードを作成する際の最も重要な手順の 1 つは、コードレビューに注釈を付けることです。これには、自分自身で事前にレビューし、レビュー担当者の理解に役立つと思われる箇所にコメントを追加する必要があります。コメント後のコードレビューには比較的時間がかからないことがわかりました (通常はわずか数分)。もちろん、必要に応じてコード コメントを使用する必要があります。さらに、調査によると、開発者自身がコードにコメントするときに多くの既存の欠陥を発見することがわかっています。

コードのリファクタリング

場合によっては、コードベースをリファクタリングする必要があります。大規模なアプリケーションに遭遇した場合、数日 (またはそれ以上) かかり、多数のパッチが生成される可能性があります。この場合、コードレビューの標準プロセスを実装するのは非現実的である可能性があります。

最善の解決策は、コードを段階的にリファクタリングすることです。まず適切な範囲を与え、対応するコードベースを決定し、次に目標方向に修正と再構築を行います。最初の部分が完了したら、レビューして公開し、その後、すべてが完了するまで 2 番目の部分をリファクタリングします。この段階的なアプローチは常に可能であるとは限りませんが、考えたり計画したりするときにこのアプローチを使用すると、リファクタリング時に大規模なモノリシック パッチを回避できます。もちろん、このアプローチではより多くのリファクタリング時間が必要になる可能性がありますが、より高品質のコードが生成され、レビュープロセスが容易になります。

コードの増分リファクタリングがまだ実現できない場合、別の解決策はペアプログラミングです。

紛争解決

チームのメンバー全員が才能があることに疑いの余地はありませんが、特定のコーディングの問題に直面した場合、簡単に意見の相違が生じる可能性もあります。開発者として、私たちは広い心を持ち、レビュアーからのさまざまな意見を喜んで受け入れる必要があります。

評者としては、機転を利かせて語らなければなりません。提案をする前に、自分の意見が本当に優れているのか、それとも単なる好みの問題なのかを検討してください。本当に改善が必要なコード領域を選択すると、説得力のあるプロセス全体がはるかに簡単になります。そしてその言葉は、「私が目を閉じて書いたアルゴリズムはあなたのアルゴリズムよりも効率的である可能性があります。」ではなく、「ここで検討する価値はあります...」、「誰かが提案しました...」のように言うべきです。