✴️ 👇 🐘 コードレビューに関する別の記事 💑 💈 👨‍💼

コードレビューとは

コードレビュー-柔軟な開発方法論の観点からのエンジニアリングの実践。これは、記述されたコードとタスクに従って、コードの記述スタイルのエラー、欠点、不一致を識別するためのコードの分析（検査）です。

このプラクティスの明らかな利点は次のとおりです。

コード品質の改善
実装に「愚かな」エラー（タイプミス）があります
コード所有権の増加
コードは単一の記述スタイルに削減されます。
「初心者」のトレーニング、スキルの迅速な獲得、経験の平準化、知識の交換に適しています。

検査できるもの

どのコードもレビューに適しています。ただし、アプリケーションの重要な場所（たとえば、認証メカニズム、承認、重要な情報の転送と処理-お金の取引の処理など）についてレビューを実行する必要があります。

ユニットテストはレビューに適しています。ユニットテストはエラーが発生しやすいコードと同じであるため、誤ったテストは非常に高価になる可能性があるため、他のコードと同様に慎重に検査する必要があります。

レビューの実施方法

一般に、コードレビューは、他の柔軟なエンジニアリング手法と組み合わせて実施する必要があります。ペアプログラミング、TDD、CI。この場合、最大のレビュー効率が達成されます。柔軟な開発方法論を使用する場合、コードレビューステージを完了機能の定義に入力できます。

レビューの構成

まず、 デザインレビューは将来のデザイン（アーキテクチャ）の分析です。この段階は非常に重要です。これがないと、コードレビューがあまり役に立たないか、一般に役に立たなくなるからです、時間）。例： プログラマーは、配列ソートアルゴリズムを作成する必要がありました。 プログラマーはbogo-sortアルゴリズムを実装しており、コードの品質の観点から、障害（書き込みスタイル、エラーチェック）を見つけることはできませんが、このアルゴリズムは作業時間にはまったく適していません。したがって、この場合のレビューは役に立ちません（もちろん-これは誇張された例ですが、本質は明らかだと思います）。ここでは、アルゴリズムを完全に書き換える必要があります。
実際、 コードレビュー自体は、記述されたコードの分析です。この段階で、コードの作成者にコメントが送信されます。

また、紛争が発生した場合に最終決定を下す際に最後の言葉を持つ人を決定することも非常に重要です。通常、優先順位は、コードを実装する人（計画ポーカー中のスクラムなど）、またはこのコードを担当する特別な人（google-コード所有者など）に与えられます。

設計レビューの実施方法

設計レビューは、テーブル、同僚のサークル、マーカーボード、企業Wikiで実行できます。 設計レビューでは、コードを作成する人が、タスクを解決するために選択した戦略（近似アルゴリズム、必要なツール、ライブラリ）について話します。この段階の魅力は、設計エラーが1〜2時間かかることです（そして、レビューですぐに修正されます）。

コードレビューの実施方法

さまざまな方法でコードレビューを実施できます-各開発者が自分の職場に座っているとき、そして一緒に-同僚のモニターの前に座ったり、会議室などの特別に指定された場所に座ったりできます。原則として、多くの方法があります（ソースコードを印刷して、紙に変更を加えることもできます）。

コミット前のレビュー

このタイプのレビューは、VCSに変更を加える前に実行されます。このアプローチにより、検証済みのコードのみをリポジトリに含めることができます。マイクロソフトはこのアプローチを使用します。変更を含むパッチはすべてのレビュー参加者に送信されます。フィードバックが収集および処理された後、すべてのレビュー担当者が変更に同意するまでプロセスが繰り返されます。

コミット後のレビュー

このタイプのレビューは、VCSに変更を加えた後に実行されます。この場合、メインブランチと一時ブランチの両方にコミットできます（すでに検証済みの変更をメインブランチに追加できます）。

テーマ別レビュー

また、テーマ別のコードレビューを実施することもできます。これらは、完全なコードレビューへの移行段階として使用できます。これらは、重要なコードに対して実行することも、エラーを検索するときに実行することもできます。最も重要なことは、このレビューの目的を決定することですが 、目標は明確でなければなりません。

「 このモジュールでエラーを探しましょう 」-無限であるため、目標としては適切ではありません。
「 RFC 1149仕様に準拠するためのアルゴリズムの分析 」はすでに優れています。

テーマ別レビューと本格的なコードレビューの主な違いは、それらの狭い専門性です。コードレビューでコードのスタイル、問題の実装と定式化の順守、危険なコードの検索を検討する場合、テーマレビューでは通常1つの側面のみを検討します（ほとんどの場合-TK順守のためのアルゴリズムの分析、エラー処理）。

このアプローチの利点は、チームが徐々にレビューの実践に慣れることです（要求に応じて不規則に使用することができます）。ブレーンストーミングセッションの一種の類似物であることがわかります。ソフトウェアの論理エラーを検索するときに、このアプローチを使用しました。レビューの数か月前に記述された「古い」コードを調べました（これは通常のレビューとの違いに起因することもあります。

結果を確認する

レビューを実施する際の最も重要なことは、結果の使用です。レビューの結果、次のアーティファクトが表示される場合があります。

問題を解決する方法の説明（デザインレビュー）
UMLダイアグラム（設計レビュー）
コードスタイルのコメント
実装（設計レビュー、コードレビュー）のより正確なバージョン（迅速で読みやすい）
コードのエラーの表示（スイッチの状態を忘れたなど）（コードレビュー）
単体テスト（設計レビュー、コードレビュー）

同時に、すべての結果が失われず、VCS、wikiに入力されることが非常に重要です。これは次の方法で防止できます。

プロジェクトの日付。
怠azine、開発者の物忘れ
便利なレビューレビューメカニズムの欠如、およびこれらの変更の導入に対する制御。

これらの問題を克服するために、それは部分的に助けることができます：

VCSの事前コミットフック
レビュー後にのみメインブランチに変更が加えられるVCSでブランチを作成する
レビューなしでCIサーバー上の配布ビルドを無効にします。たとえば、配布パッケージをビルドするときは、特別なプロパティ（svn：properties）、またはレビュー結果のある特別なファイルを確認します。すべてのレビュアーがコードを承認しているわけではない場合、ディストリビューションのビルドを拒否します。
開発における方法論の使用（コードレビューは不可欠な部分です）。

レビューの実施の難しさ（主観的意見）

レビューを初めて実装するときに遭遇した主な問題は、レビュー結果に基づいて変更を制御できないことでした。これは、このプラクティスが他のプラクティス-CIなしで適用されたという事実に一部起因します（これは、すべてのエンジニアリングプラクティスを一緒に適用する必要があるという事実を再度証明します）。

レビュー用のユーティリティ

一般に、有料と無料の両方のレビュー用のユーティリティが多数あります。私の視点を押し付けないように、インターネットでは多くのツールと詳細な説明を見つけることができます。

参照資料

提案、追加、批判は大歓迎です

コードレビューに関する別の記事