ソフトウェアエンジニアリングのコードレビューでは、1人または複数のチームメンバーが別のチームメンバーの作業をチェックし、新しいコードにバグやエラーがないか、組織が定めた品質基準が守られているかを評価します。これは、コードベース内のコードの品質を向上させることを目的としています。
なぜコードレビューが必要なのか
コードレビューは、開発者がコーディングスキルを向上させ、異なるチームメンバー間で知識を積極的に共有し、貴重なフィードバックを得る機会です。それは、より大きなコミュニケーションを促進し、若手開発者に貴重な教育的背景を提供します。また、たとえチームが地理的に分散していても、コードが組織のコーディングガイドラインで定義された標準に従っていることを保証します。コードレビューは、製品やコードベースの一部になる前にミスを発見するために重要です。
コード・レビュー・プロセス
開発者/プログラマーは、新機能、機能、改善のためにコードを書きます。コーディングが完了したら、変更を GitHub にプッシュし、レビュアーを追加できるプルリクエスト（PR）を開始します。 CI/CD パイプラインが設定されている場合は、それを含むテストフェーズを通過した後、コードレビュアーがコードをレビューします。プルリクエストがコードレビュアーによって承認されると、 PM/PL/TL はコードをコードベース（例えば master/main ブランチ）にマージすることができます。コードレビュアーから何かフィードバックがあれば、開発者/プログラマーと連絡を取り、適切な対応を取ります。
コードで何をチェックすべきか
コードをチェックする際に留意しなければならないことがいくつかあります。
・ 欠陥や潜在的な欠陥。
・ プログラム全体の設計との整合性。
・ コメントの質。
・ コーディング標準への準拠。
・ コードが必要以上に複雑でないか。
コード・レビュー・チェックリスト
コード・レビュー・チェックリストには、主に2つのタイプがあります。また、技術、言語、プロジェクト要件に基づいて独自のチェックリストを作成することもできます。これらは次のとおりです。
1.基本的なコードレビューチェックリスト
このチェックリストは、若手でもシニアでも使用できます。レビュアーがコードを簡単に理解できるかどうか、組織が定めたコーディング標準／ガイドラインに従ってコードが書かれているかどうか、重複したコードがないかどうか。関数やクラスが大きすぎないかチェックし、もしそうであれば、それらは責任を持ちすぎており、コードのリファクタリングが必要です。
2.詳細コードレビューチェックリスト
詳細チェックリストは、ドメイン、言語、技術、コード決定、コーディングのベストプラクティスに関する専門知識を持つ上級者が主に使用します。
コードのフォーマット
コードは理解しやすく、読みやすいものでなければなりません。理解するのに時間がかかるようなら、コードのリファクタリングが必要か、少なくともコメントを書いて明確にする必要があります。適切なアラインメント（左マージン）と空白があり、コードブロックの始点と終点が容易に識別できること。変数名、ファイル名、関数名について、パスカル、キャメルケースなどの適切な命名規則が守られていることを確認します。コメントされたコードを全て削除します。コメントされたコードは、必要であればソース・コントロールから入手できます。 YAGNI の原則（"You Aren't Gonna Need It"）に常に従います。
アーキテクチャ
コードは、 MVVM 、 MVC などの定義されたアーキテクチャとフォルダ構造に従って、クラス、リソース、その他の情報を簡単に見つけられるようにします。
コードは要件ごとに複数のレイヤー（プレゼンテーション、ビジネス、ネットワーク、データレイヤー）に分割されるべきです。コードは既存のコード・パターン／テクノロジーと同期させます。
ロジック
ロジックは正しく実装されるべきです。コードレビューでは、常に配列のインデックスが範囲内にあるか、ゼロで除算されているかをチェックします。ループは必ず終了させます。 if やループで使用される条件をチェックし、正しい方法で実装します。
エラー処理
エラー処理はコードの重要な部分です。エラー処理とは、ソフトウェアやプログラムが、プログラマーのミスや真の問題によって発生した可能性のあるエラーに対処したり没収したりすることです。エラーメッセージは、理解しやすく、完全なものでなければなりません。エッジケース（NULL、0、負）や配列の範囲外のインデックス、NULLポインタ、負の数が適切に処理されているかどうかを常にチェックします。
コードの決定
どのようなプログラミング言語でも、コードはさまざまな入力に応じて決定を下し、それに応じてアクションを実行する必要があり、それは開発者の知識、能力、経験、問題に対する理解によって異なります。コード・レビューの観点からは、メソッドや関数が適切な数や種類のパラメータを持っているかどうかをチェックします。関数、クラス、構造体、変数に適切なアクセシビリティ（ public 、 private など）が使用されていること。問題に最適なデータ型をチェックします。設定可能な値は、コードの変更が必要ないように、全て用意されていること（ XML ファイル、データベース・テーブル、定数）。
コーディングのベスト・プラクティス
コード・レビュアーは、コード・レビュー中に、ハード・コーディングの代わりに定数／設定値を使うなど、コーディングのベスト・プラクティスのチェックリストを作成します。似たような種類の値を列挙（ enum ）でグループ化します。必要な場合はコメントを使用し、ハック、回避策、一時的な修正を明記します。コメントは、書式、長さ、詳細レベルで一貫性を持たせます。 ToDo コメントで保留中のタスクに言及し、簡単に追跡できるようにします。複数の if/else ブロックは避け、 switch 文を使います。
SOLID原則
SOLID 原則は、オブジェクト指向の設計とプログラミングの中核となる5つの原則です。
i) 単一責任原則（SRS）
クラス/関数の責任は1つだけであるべきです。それ以上の責任がある場合は、クラスや関数をリファクタリングします。
ii) オープンクローズの原則
クラス、関数、モジュールを含むオブジェクトやエンティティは、拡張に対してはオープンでありますが、変更に対してはクローズであるべきです。
iii) リスコフ置換性の原則
子クラスは親クラスの振る舞い（意味）を変更してはなりません。全てのサブクラスや派生クラスは、その基底クラスや親クラスと置換可能でなければなりません。
iv) インタフェースの分離
クライアントは、使用しないメソッドに依存することを強いられるべきではありません。この原則は、クラスが必要とするアクションのセットだけを実行できるように、アクションのセットをより小さなセットに分割することを目的としています。
v) 依存関係の逆転
依存関係をハードコードせず、代わりに注入します。抽象に依存し、具体に依存しません。
非機能要件
i) 読みやすさ
コードは説明しやすいものでなければなりません。コードを読みながら、ストーリーを読むような感覚を得ること。
ii) テスト容易性
コードはテストが容易でなければならなりません。別の関数にリファクタリングします。
iii) 設定可能性
設定可能な値は、コードを変更する必要がないように（ XML ファイル、データベーステーブル）そのままにしておく。
iv） 再利用性
再利用可能なサービス、関数、コンポーネントを考慮します。
v) 信頼性
例外処理とクリーンアップ（廃棄）リソース。
vi) 拡張性
既存のコードに最小限の変更を加えるだけで、簡単に機能拡張を追加できます。
vii) セキュリティ
認証、認可、セキュリティ上の脅威に対する入力データの検証。
viii)パフォーマンス
遅延ロード、非同期処理、並列処理。キャッシュとセッション/アプリケーション・データ。
コードレビューのベストプラクティス
コードレビューの前にビルドとテストを行う。
コードレビューの前には必ずビルドとテストを行うこと。
コードレビューチェックリストを使用する
チェックリストは、頻繁に発生するミスをなくし、潜在的な欠陥を見つけるという課題に立ち向かうための最も効果的な方法です。コードレビューチェックリストは、レビューの種類ごとに明確な期待値を提供し、レポートやプロセス改善の目的で追跡するのに役立ちます。
研究では、開発者が一度にレビューすべきコード行数は200～400行（LOC）以下であることが明らかにされています。
400行未満のコードをレビューする
脳が一度に効率的に処理できる情報は限られており、400行を超えると欠陥を発見する能力が低下します。
60分という時間制限を守る
レビューは一度に60分を超えてはなりません。それ以上長くなると、その時点でパフォーマンスや細部への注意が低下する可能性があります。
助けとなる適切なフィードバックを与え、コメントを提供する。
フィードバックとコメントを提供するのは良い習慣です。フィードバックは、結果に曖昧さがあってはならないので、建設的な方法で、コメントに期待を込めるべきです。提案、必要な変更、議論や明確化が必要な点を区別するようにしてください。
チームと目標と期待を共有する
目標と期待のコミュニケーションは不可欠であり、明確に伝えるべきです。目標や期待を効果的にチームに伝えなければ、結果について曖昧になりかねません。
時間を節約するための自動化（例：スタティックコードアナライザ）
変更後のコードベースの品質を評価するために、静的コード・アナライザーを実行するのは良い習慣です。これらのツールは、関数名の誤りやスペーシングの問題など、あからさまな書式の誤りをカバーします。
著者は注釈をつけるべきである。
著者は、どのファイルを最初に見るべきかをコードに注釈をつけ、ソースコードの修正を全て正当化することで、プロセスを単純化し、より多くの文脈を提供します。
コード・レビューのテクニック
コードレビューは、コードベースの品質保証として機能します。ソフトウェア開発者(著者)は、コーディングが完了したらすぐにコードをレビューしてもらうよう奨励されるべきです。レビュアーは、バグやロジックの問題、エッジケースの発見をするための第二段階としても機能します。レビュアーは、ドメインの専門家であれば、どのチームやグループの人でもかまいません。コードレビューは、コードの不具合を調査または解決するために行われ、その品質はチームの他のメンバーによってもチェックされます。
1. オーバー・ザ・ショルダー(フォーマルではない)
開発者が作者の肩の後ろに立ってコードをレビューします。これは非公式なレビューです。
2. 電子メールによるパスアラウンド
著者は、コードレビューのために、コードの電子メールをレビュアーに送ります。この手法は、オープンソースのプロジェクトに好まれます。
3. ペアプログラミング
2人の開発者が1台のマシンで一緒にコードを開発します。一人の開発者がコードを書き、もう一人の開発者が一台のマシンで同時にコードをレビューします。これは時間のかかる手法です。
4. ツールベース（より形式的）
コードをレビューするために使用される専門的なツールは少なく、コミュニケーションやフィードバック／コメントを提供する機能を備えています。
コード・レビューのためのツール
プロジェクト全体のコード品質を評価する最初のステップは、静的コード解析ツールです。SonarQube、NDepend、Linter などの技術に基づいたツールを使用します。静的コード解析は、プログラムが実行される前にソースコードを調査することによるデバッグの手法です。コーディングルールのセット（または複数のセット）に対してコードのセットを分析することによって行われます。
以下は、市販されている一般的なコード・レビュー・ツールです。
・ Review Board
・ Bitbucket
・ GitHub
・ Visual Expert
・ Crucible
・ Ghodecode
・ Gerrit
・ Azure DevOps
・ GitLab
コード・レビュー・ツールの使用法
開発者は Bitbucket 、 GitHub 、 GitLab のコードホストインターフェイスを使ってコードレビューを行っています。これら3つのツールを合わせると、ツール利用全体の50%以上を占めています。約9%の開発者は、コードレビューに特化したツールを使わずに、あるいはもちろんカスタムツールを使ってコードレビューを行っています。
コードレビューの目的は、バグの発見、エラーの解決、コード品質の向上、知識の共有です。
コードレビューは、開発段階における継続的なプラクティスとして見過ごされがちですが、数え切れないほどの研究が、最も効果的な品質保証戦略であることを示しています。
読んでくれてありがとう。最新の記事はMediumでフォローできます。
コード・レビューについてコメント、質問、おすすめがあれば、下のコメント欄に投稿してください！この投稿が気に入ったら、シェアと拍手👏👏をお願いします。
【翻訳元の記事】
Do you know, What are good Code Review’s best practices?
https://medium.com/@ashokrawat086/code-review-software-engineering-bedff59f5a16