記載内容は私個人の意見であり、所属している会社とは一切関係ありません.

This article is my own personal opinion and does not reflect the views or opinions of my employer.

序章

Googleでは全てのコードにレビューがなされており、時間が経過し、スケールが拡大するとともにコードレビューの恩恵を感じるようになる.
Googleでは、Google特製のCritiqueを用いてコードレビュープロセスを支援している.

本書では、Crituqueを用いていたコードレビューを前提としているが、分かりにくいので、GHEで行うとどうなるのかを、個人的に解釈して記載することにする.

コードレビューのフロー

レビューフロー
1. レビュイー（レビューしてもらう人）は、コードの変更を行い、1名以上にレビュー依頼を提出
2. レビュアー（レビューする人）は、コードの差分からコメントを投稿する.
  - 明示的な問題解決を促すコメント
  - 情報を提供するだけのコメント
3. レビュイーは、フィードバックを反映した後、レビューに返信する
  - ステップの2と3は複数回繰り返すこともある
4. レビュアーは、変更が十分であると思ったタイミングで「LGTM（Looks good to me）」の印を付けてApproveする.
5. 変更差分をマージすることが可能
  - 全コメントを解決していること
  - Approveされていること.
『コードは負債（Technical Debt）である』
- 因みに本書では、負債ではなく、債務と訳されている.
- コードは将来、誰かの保守タスクとなる.
- 新機能の開発の際には、開発に足る正当な理由を確かめる必要がある.
  - コード上での話で、車輪の再発明っぽいことをしている気配があった場合は理由を聞きましょうということ.
- 重複したコードは、労力の無駄であり、そのコードに依存するコードに対するコストも高くなる.
- 完全に新しいコードはBadであり、車輪の再発明はすべきではなし.
  - 調査は前もって行われるのが理想である.
  - タスクを作成する際に調査しましょう.

Googleでのコードレビューはどのように機能しているか

Approveするための3つの条件
- 別のエンジニア（チームメンバが多いが、チームメンバである必要なし）のチェック
  - コードが適切であり、レビュイーの意図する通りの動作をするかどうか.
  - 記載したコードの意味の把握
- コードオーナー1名からの承認
  - レビュイーがコードオーナーの場合は、スルーできる.
  - オーナーシップの特権は、チーム内で決定する.
- その言語に対するリーダビリティ、様式、スタイル、ベストプラクティスに沿って記載されていること.
  - Googleにはリーダビリティを認められたエンジニアという枠組み（全社共通リスト）がある.
  - レビュイーが上記エンジニアに該当する場合は、スルーできる.
  - コードオーナーは有している場合が多いとのこと.
- レビュアーは、1人で上記条件を有している場合が多いとのこと.
  - レビュアーが気にしていることは以下の3つ
    - 保守は簡単？難しそう？
    - 技術的負債は増える？
    - 保守に必要な専門知識はチーム内にある？
オーナーシップ
- チーム内全員にリポジトリの全てのアクセス権を与えるのが普通である.
- GitHubのOWNERSファイルに書かれている人物は該当するリポジトリ・フォルダ・ファイルに責務を持つこと.
  - オーナーシップを通過儀礼としてはいけない.
  - チームを去る際は、速やかにオーナーシップを明け渡すこと.

コードレビューの恩恵

序文
- Googleの場合は、どのような規模のコードにおいてもコードレビューを実施する.
- コードレビューは義務であるが、速度面やコストに影響を与えているのではないか.という疑問が生じる.
- 長期的には、以降に紹介する恩恵をもたらすことを信じているからである.
コードの正しさ
- プロセスの比較的早期に欠陥を発見すると、後々修正に必要とする時間は短くなる.
  - コードレビューが合理化され、軽量的である必要がある.
- レビュアーは個人の意見を理由に代案などを出すべきではない.
  - レビュアーが出せる代案は2つ
    - 意味の把握を強める代案
    - 機能性を向上させる代案
コードの意味の把握
- コードレビューは、ある変更が理解可能かどうかを試す最初の試練である
  - コードの理解と意味の把握は、生死を分けるほどに重要である.
    - コードは書かれるより、読まれることの方が多くなるからである.
- 異なる視点を持つレビュアーを見つけることができると有益である.
- 意味把握の質問を受け流した場合は？
  - 対応したくなかった場合には、時間の経過とともに何倍にも膨れ上がる.
コードの一貫性
- コードは、理解可能かつ保守可能となるように一貫性を持つべきである.
  - 他の誰かが、記載したコードに依存関係を持つようなコードを記載するようになったり、保守したりするようになる.
- コードの健全性を保つようなコードレビューをすべきである.
- リーダビリティを認められたエンジニア（JavaだとJavaリーダビリティという）からの承認をもらうことで健全性を保つ.
- リーダビリティを持つエンジニアは、他のPJTで代役として、コードレビューを行うこともある.
  - コードレビューにおいて、チーム外のメンバーに助けを求めることはある.
心理的ならびに文化的な恩恵
- コードレビューにより、エンジニアに、コードは自分個人向けのものではなく、事業の一部であるという認識を持たせることができる.
- 人は、批判的フィードバックの受け入れを躊躇してしまいがちである.
  - コードレビューとは、批判的なフィードバックを要求するものである.
  - グレード評価などに影響があると思ってしまう.
- 優秀なエンジニアでも、インポスター症候群になる
  - 持っているドメイン知識が多くなると、建設的なフィードバックを得にくくなることがある.
- 多くのエンジニアは、完璧主義者ではない.
  - 完璧だが開発に時間が掛かるコードよりも、仕事にけりを付けるコードの方が良いと思ってしまう.
知識共有
- レビュアーは、提案、テクニック、助言となる情報を提供することで、ドメイン知識を分け与えることが可能である.
  - FYI（For your information）は、変更などを要求しないが、レビュイーを助けるために使う.
- 実際、多くのコードレビューには、情報交換が双方向に行われる.
- Googleのエンジニアの主なタスクはプログラミングであるが、エンジニアの時間の大部分はコードレビューに費やされる.

コードレビューのベストプラクティス

礼儀正しく、かつプロフェッショナルになれ
- Googleは信頼と尊敬の文化の育成に注力している.
- 優秀なエンジニアでも、コードレビューを受けるとストレスを感じるが、フィードバックと批判をプロフェッショナルの領域に留めておくことが重要である.
- レビュアーは、レビュイーのアプローチを尊重すべきである.
  - 不十分な場合にのみ指摘
  - アプローチに欠陥があった場合は、双方にとっての学びの機会と考えるべきである.
  - そのアプローチが間違っていると批判する前に、そのアプローチをとった理由を聞くべきである.
- レビュアーは24h以内にコードレビューからのフィードバックが行われることが期待される.
  - 時間内にはキツそうな場合、一旦軽くは見たけど、後日着手予定と返信すべき
- レビュイーは、自分のアプローチへの質問は歓迎し、処理内容を説明する心構えをしておくべきである.
- レビュイーは、レビュアーのコメントを必ずしも受け入れる必要はないが、コメントの対処はすべきである.
  - レビュアーのコメントに同意しない場合
    - レビュアーに同意しないことを連絡
    - 理由を記載
    - 代案を提案
    - レビューが納得するまで上記を繰り返し実施
小さな変更を書け
- コードレビューのプロセスを軽量化する方法は、変更を小さく留めておくことである.
- Googleでは、大規模な変更は実施しないように勧告している.
  - 大規模な変更の場合は、レビュアーは、拒絶することが可能である.
  - 全体像が分からず、小さな変更が望ましいとされていることに賛成していない者もいる.
  - 小さな変更とは、200行までのコードに限定されるべきである.
- Googleでは、最初のフィードバックは、1日以内に実施すべきである.
  - Googleでのコード変更の35%は、たった1つのファイルに対するものである.
- 実は、CCで全メンバにレビューが送られているので、様々な人からレビューはくるが、LGTMをもらうべき人は、筆頭レビュアーである1人のみである.
良い変更説明を書け
- 1行目にその変更がどのような種類のものかを記載すべきである.
  - 1行目が一番重要である.
  - 何が変更されており、何故変更されるのかを記載すべきである.
    - 「バグ修正」とかは良くない.
- ドキュメントの変更の場合は、実装の詳細を外部に漏洩させないようにするのが一般的である.
  - 実際の実装コードに対しては、可能な限り実装詳細を共有すべきである.
レビュアーの人数は最小限にとどめよ
- Googleの場合は、1人のレビューで十分である.
  - 以下を有しているエンジニアがほとんどであるため
    - コードの正しさ
    - オーナーの受理
    - 言語リーダビリティ
  - 別部署からのエンジニアから追加意見を得ようとする風潮がある.
    - 収穫逓減の可能性があり、最初の1人目のレビュアーのLGTMが最も重要である.
可能な場合は自動化せよ
- コードを作成するのを機械に実施し、自動化を図るべきである.
- 自動化には、静的解析（要するにCI）
  - テスト
  - リンター
  - フォーマッター

コードレビューの類型

Googleの他のコードレビューの仕方.

グリーンフィールドコードレビュー
- コードの元となっている前提条件を時間とスケールが変化したとしても、コードの保守は容易であるかということ.
- Googleでは相当量の設計レビューを求められる.
  - コードレビューは設計状の決定について討議すべき時間ではなし.
  - コードレビューは、APIの設計を紹介するためのものではなし.
- APIについて
  - APIが設計と一致していること.
  - 今までに作成したユニットテストで、全APIエンドポイントと一緒に完全にテストされていること
  - 前提条件が変わる場合は、テストが失敗すること.
  - コードオーナーによる、十分なコメント、必要なら補足のドキュメントが提供されていること.
挙動の変更、改善、最適化
- 変更が改善を生むか.
- 修正がコードの削除である場合もある.
- パフォーマンスのベンチマークを最適化する場合もある.
バグ修正とロールバック
- バグ修正以外のことはしないこと.
  - テストの修正が必要な場合も多い.
  - 大規模なコードほど、破綻する依存関係があり、ロールバックを実施する.
    - ロールバックにより、複雑な依存関係を破綻させないよう、どんな小さな変更（要するに全ての変更）であれ戻す.
リファクタリングと大規模変更
- Googleのほとんどの変更は機械が自動的に実施する.
  - 機械の変更でもレビューは必須である.
  - 機械に対しては言及せず、機械の不具合がありそうな場合は、機械を監督しているグループへ追加の情報を求め、適切なエスカレーションを実施する.