コードレビューは、ソフトウェアのトラブルシューティングに最も効果的な方法の1つです。 調査は人間によって行われるため、検出が困難なエラーや自動手段では検出できないエラーなど、幅広い種類のエラーを見つけることができます。 もちろん、コードレビューは、コードアナライザーや単体テストなどの他のエラー検出技術の使用を無効にするものではありません。 残念ながら、すべてのプログラムの欠陥を確実に検出する方法はありません（研究では、コードレビューの有効性は通常、アプリケーションで見つかったエラーの30〜50％と推定されます）。
バグの発見は、コードレビューの唯一のタスクではありません。 さらに、コードの概要には、さらにいくつかのプラスの機能があります。
- 少なくとも2人がシステムの各部分を考え抜いたという事実により、アプリケーションアーキテクチャは改善されています。
- プログラマーは、最初は、表示されることを認識して、より良いコードを作成するように動機付けられます。
- プロジェクトに関する知識はチーム全体に広がっています。
- プログラミング経験の交換があります。
- チームでは統一されたコーディングスタイルが開発されています。
これらすべてのために、コーディングに費やすことができる時間を支払う必要があります。 それにもかかわらず、少なくともある程度の観点で設計されたプロジェクトでは、後に痙攣する「dopila」ではなく、最初に高品質の製品が作成されるため、将来に費やす時間は100倍になります。
次のタイプのコードレビューを区別できます。
- 正式なコード検査。
- 非公式のコード検査（別の名前はコード分析です）。
- コードを読む。
- ペアプログラミング。
各オプションを個別に検討します。
正式なコード検査
正式なコード検査は、その名前が示すように、正式なコードレビュー手順です。 マッコネルによると、彼女は次のように見えます。
検査コーディネーターは、検査会議の日付と検査者を設定します。検査者は、会議の前に検査済みのコードフラグメントを個別に検査する必要があります。 指定された時間に、検査コーディネーター、秘書、コード作成者、検査官が集まります。 検査官またはリーダーの誰かがコードを1行ずつ読み始めます（便宜上、事前に行番号と一緒に印刷することをお勧めします）。 インスペクターは発見した問題を示し、コードの作成者はインスペクターの質問に答えます。エラーが実際に存在することに全員が同意した場合、秘書はそれを書き留めます。 検査コーディネーターは、たとえば、1つのエラーに関する議論が遅れないように、プロセス全体を監督します。 検査の終了時に、結果を含むレポートが作成されます。
正式な検査のより詳細な例については、 こちらをご覧ください 。
利点：
- 非常に高い効率。
- エラーのコンパイルされたリストのおかげで、それらの除去を簡単に検証できます。
- 検査レポートは、将来的に、たとえば特性の問題を分析するために使用できます。
短所：
- 時間がかかる複雑な正式な手順。
- メインの仕事から少なくとも3人（コーディネーター、コードの作成者、インスペクター）の注意散漫。
- コードの作者に対する大きな心理的プレッシャー。
非公式のコード検査
非公式の検査には、正式な検査とは異なり、明確なルールがありません。 たとえば、これは次のように発生する可能性があります。コードの作成者は、コードを公開する前に、最初の開発者をコンピューターに呼び出し、そこで自分が書いたものを見せて伝えます。 審査官は文章を掘り下げて質問し、自分の考えを表現しようとします。 もちろん、この方法では、効率はそれほど高くありませんが、そのような検査にはほとんど時間がかかりません。
利点：
- 低時間消費。
- 正式な手順を必要としない単純なプロセス。
短所：
- 検証者がコードを表面的に知っているため、効率が低い。
- 確認するには、メインの作業から誰かの注意をそらさなければなりません。
- 作成者は、コードに対する批判を、合理的に（たとえば、検査官の些細な口論のために）、不当に（たとえば、著者が自分の間違いを認めるのが難しい）認識しにくい場合があります。
コードを読む
コードを読むことは、著者の存在なしに、他の誰かのコードの開発者による独立した研究です。 この方法は、ここで説明するものの中で最も単純で最も一般的なものです。開発者は、とにかく誰かのコードを読む必要があったと思います。 オープンソースの世界は言うまでもなく、多くの場合それが唯一の利用可能なコードレビュー方法です。
利点：
- シンプル。
- 高可用性-時間とスペースの同期は不要です。
短所：
- フィードバックが遅い-コードに追加のコメントが必要な場合がありますが、すぐに取得することはできず、作成者に通知するよりも自分で欠陥を修正する方が速い場合もあります。
ペアプログラミング
ペアプログラミングは、コードレビューの極端な方法です。レビューは継続的に実行されます。同じコンピューターの2人の開発者が、同じマウスとキーボードのセットで1つの問題を解決します。 ペアプログラミングは、極端なプログラミング方法論の出現後に広く普及しましたが、以前は積極的に使用されていました。 多くの場合、ペアプログラミングは自発的に使用されます。多くの人は、難しいタスクを解決するために、コンピューターの別の開発者のところに行かなければならなかったと思います。
利点：
- 特に、プロジェクトの経験を共有し、知識を広めるという点で、効率が高い。
- 仕事に集中している-ペアで作業することで、開発者は無関係なものに気を取られずにすみます。
- チームが同時に開発するタスクの数の自然な制限は、少数のタスクに焦点を当てることで、より良い、より迅速な実装が保証されることです。これにより、製品の新しいバージョンを継続的に提供できます。
- 検査に固有の心理的な問題はありません。コードの作成者と検査者の両方が、改善の提案は批判ではなく文章として正確に認識されます。
- チームスピリットの向上-カップルで達成された成功は、個々の成果よりも人々を結び付けます。
- 初心者を教えるのに最適です。
短所：
- 全体的なパフォーマンスの低下、2人のプログラマーは2つのタスクを開発する代わりに1つのタスクで忙しい-多くの研究によると、このステートメントは非常に議論の余地があり、ペアで作業するプログラマーは2人のプログラマーが別々に作業するよりも生産性が15％低いだけです。
- 仕事のスケジュールの同期が必要です-パートナーが異なる時間に夕食に出かけたり、仕事に来たりするとき、ペアで働くことは困難です。
- 仕事に常に集中しているために疲れがひどい-ペアで作業しているプログラマーの場合、1日を標準の8時間より短くすることも理にかなっている場合があります。
- すべての人が互換性があるわけではなく、一部の人は誰かと一緒に仕事をすることさえできません。 実際、そのような人々はほとんどおらず、カップルでの相互作用の問題の多くは、カップルで働いた経験の蓄積だけでなく、いくつかのルールに従うことで克服できます（ たとえば ）。
- 日常的なタスクの実行には効果的ではありません。この場合、キーボードを所有していない開発者は退屈するだけです。
- 開発者のペースを同期させることは難しく、経験と知識のレベルは大きく異なります-より効率的に作業するには、経験豊富な開発者は忍耐といくつかの指導スキルが必要です。
上記にいくつかの単語を追加したいと思います。 ご覧のとおり、いくつかの欠点はメリットに起因しています。 これは驚くべきことではありません。一見すると一見すると思われるかもしれませんが、ペアプログラミングは非常に単純ではありません。 したがって、ペアで作業を開始すると、すぐに結果が得られることを期待しないでください。 ある程度の経験を積んだ後にのみ、ペアプログラミングが実を結び始め、さらに、いくつかの悪影響を最小限に抑えることが可能になります。
何を選ぶ？
これで、どのメソッドをどのケースで使用する価値があるかを判断できます。
- コードのレビューを行うことを決めたが、これに煩わされたくない場合は、 非公式の検査が1か所にあるチームに最適です。
- 分散チームの場合、利用可能なレビュー方法はほぼコードを読むことだけです。 リモートペアプログラミング用のシステムがあるという事実にもかかわらず、純粋に心理的な理由から、それらは1台のコンピューターでのプログラミングほど快適ではありません。 さらに、コードの読み取りは未割り当てのコマンドで実行できますが、コードの目的を推測したり、作成者に問い合わせたりする選択肢がある場合は、後者を選択します。
- 正式な検査は 、コードの複雑なセクションや重要なセクションをレビューするのに最適です。この場合、結果に時間を費やすだけではありません。 フォーマルインスペクションを絶えず使用している人もいますが、フォーマルインスペクションが利用可能なすべてのコードをレビューする方法を想像するのは困難です。
- ペアプログラミングは 、極端なプログラミングの原則の1つではありません。 このタイプのコードレビューのみに固有の高い効率性と追加のボーナスにより、チームの開発の主要な方法として推奨できます（単純なタスクまたはルーチンタスクを除く）。 楽観主義は、欠点のほとんどでうまく戦うことができるという事実によって追加されます。 最大の問題は、彼らの意見では、そのような無駄な方法を使用するように経営者を説得する試みかもしれません-ここでは、あなたを助けるために極端なプログラミングの実践者による本や記事を見つけることができます。
ご覧のとおり、十分なオプションがあります。自分に最適な方法を選択できます。 さらに、技術の組み合わせを禁止する人はいません（たとえば、チームの一部がペアで作業し、他の部分は単独で作業しますが、それらによって作成されたコードは必ず検査されます）。 より簡単な方法から始めて、徐々に複雑な方法に移ることができます-主なことは開始することであり、肯定的な効果はすぐに来ると思います。
文学
- 完全なコード（コード完了）。 スティーブマッコネル 第21章共同構築。
- 極端なプログラミング：プロセス設定。 最初のステップから最後まで（Extreme Programming Applied：Play to win）。 ケン・アウアー、ロイ・ミラー 第14章単独での作業を停止します。