はじめに
コードレビューに関するTipsを投稿しよう！ by CodeRabbit Advent Calendar 2025 の記事です。（滑り込みの投稿になります）
最近はテックリード的な立場になり、その経験からのコードレビューでどういうことをすべきかのまとめになります。
ジュニアメンバー的な方は、将来的にはこういうことが求められるという見方をしてもらえればと思います。
どうあるべきかを示していく
リーダーに求められる役割は、チームをどういう方向に進めていくかどうかを決めて、そこに向かうことを促すことです。基本的には、チームメンバーが受け入れる形でそれを提示していく必要があります。
言語やデザインパターンの知識、レビューのルール決めなど、いろんな要素がコードレビューにありますが、どの場面でも「どうあるべきか、なにが望ましいものか」を示していくことが重要です。
正確な答えを持たなくてもいい
方向性を示すことが重要なので、正確な形の答えを持っていなくてもいいです。方向性を示したことでレビュイーの方がより良い答えにたどり着くもあり、むしろそういうケースを増やしていく方が、レビューとしての価値が高いです。
既存のコードベースに望ましいものがなければ、自分で作る
良い状態のプロジェクト・チームなら、参考になるコードが既存にあるかもしれません。そういう状況であれば、既存のやり方を踏襲した方が良いかもしれません。
けど、そうでない場合は、自分でどうあるべきかを考え、作る必要があります。長期的なコードの保守性・変更容易性のためには、一時的な複数のやり方が混在することを許容してでも、望ましいやり方を提示し、定着させることを決断しなければなりません。これができないと、過去のやり方にただただ流されてしまいます。
どうあるべきかの共通認識が増えるとレビューがスケールする
どうあるべきかが共有されていくと、詳細な説明が段々不要になっていきます。少ない言葉で、お互いがわかるようになってくるので、レビューでラリーすることも減ってきます。なんなら、そもそも指摘する箇所自体も減ります。
具体的にやったこと
ここからは、ある程度具体的にやったことや、それに至った経緯などのまとめになります。
プロダクションコード
ガイドラインの作成
チームメンバーが多かったり、新しいメンバーが入ってくると、過去に指摘したことを繰り返す場面がでてきます。
同じ指摘を繰り返すことは自身の停滞につながりますし、効率も悪いので、どういうコードを書いて欲しいかをガイドラインという形でドキュメント化しました。
内容としては以下になります。
- パッケージ構成
- クラス・変数の命名規則
- フレームワーク・ライブラリの使い方
- バージョンアップによる新しい書き方
- 特定のケースの実装方針
いわゆるコーディング規約よりも、業務内容に踏み込んだものを含んでいます。
asis/tobe, bad/goodと、良い・悪いがわかるようなサンプルコードもつけています。
サンプルコード付きのコメント
自然言語だけでは正確に伝わらず、コメントのラリーを続けてしまうことが何度かありました。
同じオフィスにいれば、そのタイミングで対面でのやりとりにできますが、リモートだとそうもいかないです。
意図を明確に伝えるためにも、ほぼ動くレベルのサンプルコードを書くようになりました。
名前がついてるパターンを提案したときは、それを伝える
良く使うのが、static factory methodなのですが、そういう名前がついてるパターンについて、その旨と参考になるリンクを添えるようにしました。レビュイーが自分で周辺知識を学んで、自力で同じパターンを使えることを促すためです。
メソッドの使い方を提案したときは、api docのページも伝える
こういうメソッドを使うといいですよという提案したとき、Javaならjavadocのリンクもいれるようにしています。
そのメソッドの詳細や、やりたいことに適したメソッドの探し方を伝える意図があります。
テストコード
ガイドラインの作成
テストコードの保守性・可読性を高めるには、プロダクションコードとは求められることが大分違います。
方向性を決めずに、テストコードを書き始めると収拾がつかなくなりやすいです。
よくわからない人は、中身がトートロジー的なテストコードを書いてしまったりします。
- Arrange-Act-Assert pattern
- ネストによる構造化
- テストメソッドの命名規則
- テストフレームワークの使い方
- 事前・事後処理
- パラメタライズテスト
などを中心に方向性を決めるようにしました。
AAAパターンと、assertionの内容をテストメソッドの名前にすることを徹底すれば、おかしなことには滅多にならないです。
リーダブルなテストコード
TDDについては結構昔からありますが、「リーダブルテストコード」というのは、ここ2~3年で出てきたという印象です。これはテストコードが普及しないと、そもそもリーダビリティがあまり求められなかったせいかもしれません。下記の資料が参考になりました。
PR関連のルール
GitHub/Bitbucketなど、つかっている製品によって、細かいやり方は変わってきますが、大筋は同じようなことができます。
レビューコメントのタスクリスト化
コメントの対応漏れを防ぐために、コメントをなんらかの形でタスクリストにします。
Bitbucketはタスクとしてコメントすれば、リスト化されます。
GitHubもstart a reviewでコメントすれば、resolve conversationでリスト化されます。
WIPで早めにPRを出す
差分が大きくなること自体は問題ないですが、方向性が大きくずれたまま進めてレビュー依頼を出すと、お互いが不幸になります。そういったことを回避するために、途中でもいいので方向性をすりあわせるために、早い段階でPRを出すことを推奨しています。
PRのdescriptionのテンプレート
テンプレート機能を使うなどして、PRの内容の説明資料をつけることを推奨しています。
設計資料など、実装した内容の根拠となるものがあると、レビューしやすいです。
GitHubの場合は、実装のためのタスクリストもつけると、PRの進捗状況をお互いが把握しやすくなります。
まとめ
レビューを成功させるには、その前にやるべきこと・やった方が良いことが、実はたくさんあります。
粒度も、設計の方針から、レビューのルールなど、大小様々です。
レビューがうまくいってるかどうかを、客観的に示す指標もあまりありません。
（コメントした数がありますが、状況に応じて、多い・少ないのどちらが良いかが変わってしまいます）
どうあるべきかを模索し、示していくことが重要です。