コードレビューにエゴはいらない 【Looks Good To Me みんなのコードレビュー】
Looks Good To Meの書籍紹介記事です。
※本記事は、読書時のメモを入力としてChatGPTに書かせたものを自分なりに加筆修正したものです。
目次
- レビューはバグ取りではなく知識共有の場である
- 良いレビュー文化はルールを作り、形骸化から守らなければならない
- 文書化と自動化でレビュー文化を根付かせなければならない
要点
1. レビューはバグ取りではなく知識共有の場である
- レビューには【人間主導】【ツール支援】【ハイブリッド】の3型がある。
- 人間主導：対面でレビューを進める
- ツール支援：ツールで中継してリモートで連携する
- ハイブリッド：上記の中間
- コードレビューの本来の価値はバグを見つけることではなく、「知識共有・記録保持」である。
- 自動テストや静的解析で代替可能なものは、無理にレビューの目的に含めなくてよい。
2. 良いレビュー文化はルールを作り、形骸化から守らなければならない
- 良いプルリクエストの特徴は「タイトルで概要がわかる」「説明だけで理解できる」「外部参照不要」こと。
- タイトルにはプレフィックスを付与し、説明に根拠や影響範囲を明記する。
- レビューコメントは「エゴを捨て、根拠を明確に、具体的に」指摘する。
- レビューされる側もエゴを捨てる、コメントを自己否定と解釈してはいけない。
- 「なんとなくLGTM」「相互承認ゲーム」などの形骸化を避ける仕組みが必要。
3.文書化と自動化でレビュー文化を根付かせなければならない
- 規約やルールを文書化して共有し、レビュアーごとのブレを防ぐ。
- 自動化（リンター、フォーマッター、テスト）が負担を下げ、文化を維持しやすくする。
- 改善策は「負担の分散」「プルリクの分割」「対面での議論」など。
- レビューを文化として続けるには、暗黙の了解をなくし、改善可能なプロセスとして扱うことが大切になる。
感想
本書で特に印象に残るのは「良いプルリクとは何か」という具体的なルール群。
タイトルにプレフィックスを付けて方向性を示し、説明文に背景や影響を明示し、タグやステータスで進行状況を整理する。
「細かすぎて面倒」と思う一方で、徹底できれば混乱を防ぎ、レビューを単なるチェックから「チームの知識を残す仕組み」にできるのだろうと思う。
一方で不安に感じるのは、このようにルールが厳密に定義されている割に、それを強制・維持する仕組みが弱いことだ。
結局、人間が神経を使って守り続けるしかなく、自動化には常に限界がある。
「ルールがここまで細かいのに、自動で守れるように設計されていないのは不安だ」と感じながら読んでいた。
コードレビューのために作るルールはある種の憲法みたいなものかもしれない。
不断の努力で維持し続ける絶対的なルール。すべてのメンバーが従うべき聖域として。
本書のタイトルにもある「Looks Good To Me (良さそうに見える)」だが、総じて肯定的な意味で登場することはあまりない。
常にLGTMの後ろにつく言葉が見える。
「なんか良さそう、『知らんけど』」
あまりにもレビュー対象が多く細かく見る気力がなくなったときや、雰囲気で問題なさそうだと思ったときに使いがちかもしれない。
LGTMとは言わないまでも、レビューが疎かになって証拠かも？
余談ですが、Qiitaが記事の高評価を「LGTM」に一瞬切り替えてすぐ「いいね」に戻したことがあった。
Qiitaの「LGTM」を「いいね」に戻します - Qiita Blog
今思うとこれは英断だったのかもしれない。
軽薄な「なんか良さそう」と言ってしまえる文化から脱出できたのかも。知らんけど。
総評
チーム開発においてコードレビューの「導入を検討中」または「導入しているが品質にいい効果が出ていない」場合に向いている本だと思う。
また今回はあえて通読したが、飛ばし読みでも全然かまいません。
目安としては、
- 2章が「コードレビューを導入したいときに読む部分」
- 3 ~ 5章が「どんなふうにコードレビューをすればいいか」
- 6 ~ 10章が「どうやってレビュー品質を守るか」
となる。
13章が生成AI関連だが、すでに時代遅れ感が否めないので流し読み程度でいい。
最後に、もしこの本がコーディングだけのことだと思って読むのを避けていたなら、
その必要はありません。
大枠でとらえれば、きっと コードだけでなく他の成果物に対しても同様に適用可能でしょう。
さいごに
本記事の中身にした読書メモは↓のスクラップにまとめています。
【読書メモ】LGTM
今後も読書記録は残していこうと思うのでどうぞごひいきに！
Discussion