インターネット開発: 効率的なコードレビューのための 10 の経験

コードレビューは、ソフトウェア開発でよく使用される方法です。QA テストと比較すると、アーキテクチャやタイミングに関連する問題など、見つけにくい問題を見つけやすくなります。また、チームメンバーのプログラミングスキルの向上やプログラミングスタイルの統一にも役立ちます。

1. コードレビューには優れたチーム文化が必要

チームは、コードレビューは個人にチェックポイントを設定するのではなく、チーム全体の能力を向上させることを目的としていることを認識する必要があります。

「A のコードには B によって発見されたバグがあるため、A は能力がなく、B の方が優れています。」このような罠は簡単に広がり、チーム内のコラボレーションに影響を与える可能性があるため、回避する必要があります。

さらに、コードレビュー自体が開発者の能力を向上させ、開発者が自分の間違いから学び、他の人のアイデアから学ぶことを可能にします。開発者がこのプロセスに抵抗したり嫌ったりすると、この目標は達成できません。

2. レビュー中の問題発見率を慎重な評価基準として使用する

コードレビュー中に問題が見つかった場合、その問題を発見した人にとっては良いことであり、奨励されるべきです。しかし、私たちは捕まった者を罰するためにこの方法を使うことを支持しません。ソフトウェア開発ではバグは避けられませんが、過度な要求は逆効果です。さらに悪いことに、コードレビューによって参加者が責任を取ることを恐れ、レビュー中に問題を指摘することを嫌がるようになると、コードレビューには価値も意味もなくなります。

3. レビューするコードの量を制限する

Cisco の SmartBear が実施した調査によると、毎回 200 ～ 400 行のコードをレビューするのが最も効果的です。一度にレビューするコードの量が増えるほど、問題が見つかる可能性は低くなります。具体的な比率は次の図に示されています。

実際には、コードレビューの最適な量は開発プラットフォームと開発言語によって異なることがわかりました。しかし、このプロセスは精神的に非常に負担がかかるため、一度にレビューする数を制限することが重要です。時間が経つにつれて、コードはレビュー担当者の目には論理的なつながりのない単なる文字に見えてくるので、当然、出力は多くなくなります。

4. 質問がある場合はレビューをご覧ください

すべてのコードレビューでは、まずレビュー担当者自身の経験に基づいて起こりうる問題について考え、レビュー作業を通じてそれらの問題が解決されたかどうかを確認するように依頼しています。 1 つのコツは、ユーザーに表示される関数から始めて、より複雑な使用シナリオを想定し、コードを読みながらこの使用シナリオが正しく機能するかどうかを確認することです。

この手法を使用すると、レビュー担当者はコードに関与し、真に没頭していると感じることができ、効率が向上します。武侠小説を読んでいると寝つきにくいのは誰もが知っていますが、専門書を読んでいると寝つきやすいのです。その理由は、武侠小説の方が没入感を作りやすいからです。

いくつかの研究では、単位時間あたりにレビューされるコードの量を制御するために、毎回目標を設定することを提案しています。この方法は、私たちの実践では非常に機械的かつ手続き的であり、上記の方法ほど効果的ではありません。

5. すべての質問と変更は元の著者によって確認される必要があります

レビュー中に問題が見つかった場合は、元の著者が確認する必要があります。

これには 2 つの目的があります。

（１）問題が存在することを確認し、解決する

（２）原作者に自分の問題や欠点を理解してもらい、成長を手助けしてもらう

場合によっては、効率性を追求するために、経験豊富なレビュー担当者がコードを直接変更したり、コード全体をリファクタリングしたりすることを好むことがありますが、これはチームの効率性の向上にはつながらず、リファクタリングによって新しいバグが導入される可能性が高くなります。通常、これは推奨されません。

6. コードレビューを利用して個々の「主体性」を活性化する

プロジェクトのスケジュールが厳しく、完全なコードレビューができない場合でも、少なくとも部分的なコードレビューは行う必要があります。このとき、いくつかの重要な部分をランダムに抽出すると良いでしょう。

この背後にある論理は、ソフトウェア開発は非常に創造的な仕事であり、開発者は強い自己動機と自己実現の要件を持っているということです。開発者に、自分が書いたコードは他の人に読まれ、レビューされる可能性があることを知らせることで、特に品質の低いコードや低レベルのエラーのあるコードをピアレビューに提出することを避けるよう、開発者が集中できるようになります。オープンソースソフトウェアもこの考え方をうまく活用してコードの品質を向上させています。

7. カジュアルでリラックスした雰囲気の中でコードレビューを実施する

前述したように、コードレビューは精神的に負担のかかる作業です。参加者は比較的リラックスした環境でこの作業を行う必要があります。したがって、いくつかのプラクティスで推奨されているような会議形式でのコードレビューは効果的ではないと考えています。会議が長くなると非効率になりやすいだけでなく、会議中に生じる論争や考えが複雑な作業に役立たないからです。

8. コードを提出する前に自己レビューし、コードの説明を追加する

すべてのチームメンバーは、コードを他のメンバーにレビューのために送信する前に、レビューを実施する必要があります。この自己修正レビューでは、コードの正確性をチェックするだけでなく、次のタスクも実行できます。

（1）他の人が確認できるように、変更の理由を説明するコメントをコードに追加します。

（２）コードの読みやすさを向上させるために、コーディングスタイル、特にいくつかの主要なデータ構造とメソッドの命名を修正する。

（３）全体的な視点から設計を見直し、すべてのシナリオが十分に考慮されているかどうかを確認します。実装前の設計に欠陥があった場合は、この段階で修正できます。

実際には、元の作成者だけがコードレビューを実行しても、コードの品質を大幅に向上できることがわかっています。

9. 実装中にメモを取ると、問題検出率が大幅に向上します。

メンバーは、コード内でコメントを使用したり、簡単な個人文書を保存したりするなど、コーディング中にメモを取る必要があります。これにはいくつかの利点があります。

（１）省略を避ける。コーディング中に思い浮かんだ問題はすべて記録され、レビューフェーズで再確認され、解決されたことが確認されました。

（２）研究によれば、誰もが何らかの繰り返しの間違いを犯すことに慣れている。このような問題はコーディング中に記録され、レビュー時の検査の基礎として使用できます。

（３）繰り返しメモを取り、復習中に同様の問題を発見すると、そのような問題の頻度は大幅に減少する。

10. 軽量コードレビューには優れたツールを使用する