コードレビューの目的
2025年末ごろにMackerelチームでレビューの目的や期待していることを話したとき、他のメンバーはバグの発見をレビューに期待しているし、バグを見つけるためにレビューしていると聞いた。自分自身はそんなことを目的と考えていなかったので、これは非常に驚きがあった。
では何を目的にレビューしているかというと、最も大きな理由は「そのコードを受け入れられるか」をみている。具体的に言えば、そのコードで何か問題が起きたとき、自信を持って対応できるか、もしくは変更することになったときに困らないかが重要な関心事なので大きなプルリクエストはこの目的を満たせない(または非常に労力がかかる)。だからPull Requestの適切な大きさには関心があるし、自分のコードは可能な限り小さくするようにしている。
この仕草はおそらく、Plan 9対応のパッチをプルリクエストしたとき、リポジトリのオーナーに「面倒見きれないからマージできない」と何度か言われたことが原体験となっているのだろう。リポジトリにPRを出すということは、そのコードを今後ずっとオーナーが面倒見てくれと言っているに等しいと誰かが書いていた記憶があるし、実際その通りだと思うのでクローズされたことに不満はない。
Russ Coxがgolang-devの”What should we do with CLs generated by AI?”スレッドに投稿した文章では、
Goプロジェクトにコード変更をマージする際、レビュアーや承認者は、たとえ元の作成者が不在になったとしても、将来にわたってこのコードを維持することを約束しているのです。また、変更がコードベース全体に及ぼす影響についても責任を負うことになります。コードレビューの最も重要な目的は、こうした責任を果たすために適切なコードが記述されていることを確認することであり、通常は詳細なコメントと修正を繰り返す編集プロセスを通じて行われます。
とある。また、Googleのレビュー基準も、べつにバグの有無ではなくスタイルや一貫性の話が主だった。