コードレビューとは、作者以外の人が該当するコードをチェックし、以下のような質問を検討するソフトウェアの品質保証のためのアクティビティです:

• TL;DR: コードはcleanか? :)

• 設計(Design): コードはよく設計され、あなたのシステムに適しているか？

• 機能性(Functionality): 開発者が意図したと思われる動作をするコードか？ユーザーにとって正しい動作か？要求事項を見ると、すべてのケース/機能が完全に実装されているか？

• 複雑性(Complexity): このコードをもっとシンプルにできないか？将来、別の開発者がこのコードに出会ったとき、簡単に理解して使うことができるだろうか？マーティン・ファウラー氏の著書Refactoring: Improving the Design of Existing Codeの中で述べているように:

  コンピュータが理解できるコードを書くのはどんなバカでもできる。優れたプログラマーは、人間が理解できるコードを書きます。

• テスト(Tests): コードには正しく、よく設計された自動テストがあるか？新しい自動テストは新しいコードに対して十分か？コードの変更に伴い、既存の自動テストは書き直す必要があるか？

• 命名規約(Naming): 変数、クラス、メソッドなどの名称を明確に決めているか？

• コメント(Comments): コメントは明確で有用か？

• スタイル(Style): スタイルガイドに沿ったコードになっているか？

• ドキュメント(Documentation): また、関連するドキュメントを更新しているか？

コードレビューの最も重要な利点は、Collective Code Ownershipです。これは、あらゆるプロジェクトの"Code Ownership"は、個人ではなく、チームそのものに属するというeXtreme Programming (XP) のプラクティスです。スティーブ・マコーネルは、彼の著書 "Code Complete" の中で、このことを"Collective Ownership in Construction（構造における集団所有）"と呼んでいます。これは、すべてのコードが貢献者(contributors)のグループによって所有され、貢献者はそれぞれ平等に、集団で所有するプロジェクトにアクセスし、変更することができるという考え方です:

ソフトウェアエンジニアリングのプロセスを管理する方法の1つは、”最低価値"の段階、つまり、投資が最も少なく、問題の修正に最もコストがかからない段階で問題を発見することです。この目標を達成するために、開発者は”クオリティゲート"と呼ばれる定期的なテストやレビューを行い、ある段階での製品の品質が次の段階に進むのに十分であるかどうかを判断するのである。

これによって、2つ目の重要な利点は、Ego-less Programmingが挙げられます。ジェフ・アトウッドがブログ記事で以下のように述べています：

あなたはあなたのコードではありません。 レビューの目的は問題を発見することであり、問題は必ず発見されることを忘れないでください。問題が発見されても、それを個人的に受け止めないでください。

もし誰かが間違いを犯したとしても、この方法ならそれを受け入れ、修正することが容易になります。そして、"あなたがどれだけ '空手'を知っていても"、ジェフ・アトウッドが言うように、***"他の誰かがもっと知っている"***のです。

また、開発者よりも知らない人がいる場合もあり、そのような場合には、敬意と忍耐の両方を示さなければなりません。コードレビューによって、開発者はこれらのことを短時間で理解することができます。

その他の重要な利点としては、以下のようなものが挙げられます：

• 知識の共有と新人エンジニアのメンタリング
• より良いコード
• 不具合の発見
• コミッターのモチベーションを高める
• 長期的には、より良い見積もり

コードレビューの種類は、所要時間とレビューの目的によって3つに分類されます:

• インスペクション: 1時間程度かかる長時間のコードレビュー。"モデレーター"と呼ばれる第三者がこのセッションに参加し、1時間以上かかることも大いにあり得るレビューの進行をモデレートします。この場合、これ以降はパフォーマンスや細部へのこだわりが低下する傾向があります。
• ウォークスルー: これは、通常、先輩開発者が新人プログラマーにコンセプトを説明するための教育機会を提供することを目的としたワーキングミーティングに変化する、より時間のかからない中堅レベルのコードのためのものです。
• ショートレビュー: 小さな変更へのコードレビューであれば10分程度、特にリリースフィックスやバグフィックスは非常に短い時間で修正することができます。

効率的なコードレビュー手法

モブプログラミング、ペアプログラミング、 -あるいはピンポンプログラミングのようなサブメソッド- は、コードレビューの利点を提供し、コードレビューの定義によく合っているので、コードレビュー技法としてカウントすることができます。ただ、"ペアプログラミング"の場合は、レビュアーと並んで座り、コードを書きながらレビューされるという違いがあります。そのため、効率性のレベルはそれぞれ異なり、効率の高いものから低いものへと以下のように分類することができます:

from "10 Faulty Behaviors of Code Review"

上記からわかるように、ペアでサイドバイサイドのプログラミングを行う以外に、最も効率の良いコードレビュー手法は"プルリクエスト"を開くことで、これはGitHubやGitLabなどのgitプロバイダで活発に使われている非常に効率の良い技術です。