レビューの価値はバグ止めより、読めるコードと知識の広がりにある。役割で承認を分け、小さく速く回す。
目次
主目的は「他人が読めるコード」
Google がレビューを入れた最大の動機は、他人が理解できるコードを書かせること
- 「分かりにくい」という指摘はすべて妥当と受け取る
- 正しさの確認は多重防御の1枚で、完璧でなくてよい
- 新しいコードには作る理由を問う。決着済みの設計は蒸し返さない
承認を役割で分ける
変更には3つの承認が要り、各人が自分の観点に集中できる（§9.2）
| 承認 | 誰が | 何を見る |
|---|---|---|
| LGTM | 別のエンジニア | 正しさと分かりやすさ |
| オーナー承認 | OWNERS の少数 | その場所に入れてよいか |
| リーダビリティ承認 | 言語の認定者 | 言語のスタイル |
- LGTM は1人で足りる。増やすとコストが価値を上回る
速く回すための作法
遅さの多くは、レビューそのものより進め方から来る
- 小さく出す。論文では変更行数の中央値が24行
- 24業務時間以内に返し、コメントを小出しにしない
- 機械で分かることは静的解析に任せる
| 種類 | 見ること |
|---|---|
| 新しいコード | 設計の合意と API のテスト |
| 挙動の変更・最適化 | 必要か。最適化ならベンチマーク |
| バグ修正 | 手を広げず、再発を捕まえるテスト |
つまずく場面
成熟した今でも、距離・言い方・期待のずれでうまくいかない
- 地理や組織の距離による遅れと誤解
- きつい言い方や承認の引き延ばし
- 設計をいつ固めるか、緊急か任意かの食い違い
関連
- 知識共有 — リーダビリティという仕組み
- チームでうまく仕事をするには — 批判の伝え方と受け止め方
- スタイルガイドとルール — 一貫性の基準
- テスト — テストがあるとレビューが軽くなる