効果的なコードレビューのための 10 のレッスン

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

1. コードレビューには良い文化が必要です

チームは、コードレビューはチーム全体の能力を向上させるためのものであり、個人に設定された「ゲート」をチェックするためのものではないことを認識する必要があります。

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

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

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

コードレビュー中に問題が発見された場合、これは問題を発見した人にとって良いことであり、奨励されるべきです。しかし、私たちはこの方法を使って発見者を処罰することを主張しません。ソフトウェア開発ではバグは避けられず、過度に要求することは直観に反します。さらに悪いことに、参加者が責任を取ることを恐れ、レビュー中に問題点を指摘することに消極的であれば、コードレビューには何の価値も意味もありません。

3. 各レビューのコード数を制御します

Cisco の Smartbear が実施した調査によると、コードを 200 ～ 400 行ずつレビューするのが最も効果的です。コードを見直しすぎると、問題を発見する能力が低下します。具体的な比例関係は次の図のようになります。

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

4. レビューに質問を提出します

各コードレビューでは、レビューワに自らの経験に基づいて、まず遭遇する可能性のある問題を考え、その問題が解決されたかどうかをレビュー作業を通じて検証してもらいます。 1 つのコツは、ユーザーに表示される関数から始めて、より複雑な使用シナリオを想定し、コードを読みながらこの使用シナリオが正しく機能するかどうかを検証することです。

この手法を使用すると、レビュー担当者がコードに没頭しているように感じられ、効率が向上します。武侠小説を読むと寝つきが悪いのは誰でも知っていますが、専門書を読むと寝つきやすいのは、武侠小説のほうが没入感が生まれやすいからです。

一部の研究では、単位時間あたりにレビューされるコードの数を制御するために毎回目標を設定することを提案しています。私たちの実践では、この方法は非常に機械的でプロセスベースであるように見え、上記の方法ほど効果的ではありません。

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

レビュー中に問題が発見された場合は、必ず原作者に確認してください。

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

(1) 問題が存在することを確認し、問題が解決されたことを確認します

(2) 原作者に問題点や欠点を理解してもらい、成長を助けてもらう

経験豊富なレビュー担当者は、効率を追求するために、コードを直接変更したり、すべてのコードをリファクタリングしたりすることを好む場合がありますが、これはチームの効率向上には役立たないため、リファクタリングによって新しいバグが発生する可能性が高くなります。それを奨励します。

6. コードレビューを使用して個々の「エージェンシー」をアクティブ化します

プロジェクトのスケジュールが厳しく、完全なコード レビューを行うことができない場合でも、この時点でコードの少なくとも一部をレビューする必要があります。重要な部分をいくつか抽出することをお勧めします。

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

7. 非公式でリラックスした環境でコードレビューを実施します

前述したように、コードレビューは精神的に集中する仕事です。参加者は比較的リラックスした環境でこの作業を行う必要があります。したがって、一部の実践例で提案されているように、会議の形でコードレビューを行うことは効果的ではないと考えています。長時間にわたる会議は非効率につながりやすいだけでなく、会議で生じる可能性のある議論や考え方が適切に処理されないためです。そのような複雑な作業を助長します。

8. コードを送信する前にセルフレビューを行い、コードの説明を追加します

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

(1) 他の人によるレビューを容易にするために、この変更の背後にある理由を説明するコメントをコードに追加します。

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

(3) グローバルな観点から設計を見て、すべてのシナリオが完全に考慮されているかどうかを確認します。実装前に行われた設計が十分に考慮されていない場合、この段階でそれを修正する良い方法になる可能性があります。

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

9. 実装中にメモを記録すると、問題の発見率が大幅に向上します

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

(1) 記載漏れを避ける。コーディング中に考慮された問題はすべて記録され、レビュー段階で再度チェックされて、問題が解決されたことを確認します。

(2) 研究によると、誰もがある程度の間違いを繰り返すことに慣れています。このような問題はコーディング中に記録され、レビュー時の検査の基礎として使用できます。

(3) 繰り返しメモを取り、復習中に同様の問題を発見すると、そのような問題の発生率は大幅に減少します

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

「労働者が仕事をうまくやりたいなら、まず道具を研ぐ必要があります。」 bitbucket が提供するコード ホスティング サービスを使用します。

各チーム メンバーは個別に機能を開発し、プル リクエストの形式でコードをレビュー担当者に送信します。レビュー担当者は、Web ページ上でコードを簡単に読んだり、コメントを追加したりすることができます。その後、元の作成者は、レビュー コメントについて議論するための電子メール リマインダーを自動的に受け取ります。

チーム メンバーが広範囲に分散している場合でも、bitbucket が提供するツールを使用してコード レビューを非常に効率よく行うことができます。

元のリンク: http://www.html5cn.org/article-4001-1.html