🦔

コードレビューの心理的負荷を下げたい

2025/02/02に公開

背景

コードレビューの依頼が来ると、少し気が重くなることはありませんか?
私はよくあります😇
過去にレビューを依頼した方々も、同じように感じていたのではないかと思います。
なぜなら、私の作成したPRは「レビューしにくいPR」だったという自覚があるからです。

今回は、自分の経験や参考資料をもとに、「どうすればコードレビューの心理的負荷を軽減できるか?」についてまとめます。

コードレビューの目的は?

一般的な定義はさておき、自チームではどのような目的でコードレビューを行っているのかを整理すると、主に以下の点を確認するためです。

  • 要件を満たしているか
  • バグ、リグレッションは発生しないか
  • コーディング規約に違反していないか
  • 性能面、可読性、保守性は問題ないか

どういうときに心理的負荷が高いと感じるのか?

私は、以下のような状況で「コードレビューしないと……😮‍💨」という気持ちになりやすいです。

  • 変更行数が多い
  • 自分が持っているタスクが他にある
  • レビューのやりとりが多く、コミュニケーションコストが高い
  • 要件理解から必要
  • 既存コードの理解から必要
    • 既存が複雑な場合、ここで工数がかかる
    • 実装者も同じところで時間がかかっている場合、実装者とレビュワーで同じところに工数をとられていることになる
  • 自分が最後の砦感がある
    • 問題が起きると「コードレビューちゃんとしたの?😇」みたいな感じになる(言われたことはない)

どうすれば心理的負荷を軽減できるか?

変更範囲を小さくする

他チームからのレビューを受けた際、PRの変更範囲が最小限に抑えられていたことがありました。
そのときは非常にレビューしやすく感じました。(後から聞いたら、レビューしやすさを意識したPRだったらしく、感謝感激でした)

「小さい」とはどの程度か明確に定義するのは難しいですが、そのときは1~2ファイルの変更を1つのPRとしていました。

私のチームでは、1PBIにつき1PRというルールがあるためPRの範囲を決めるのは実装者ではなくPBIの作成者になってしまっています。
しかしPBI作成時にはコードの変更範囲は分からないはずなので、実装者が判断してPRを作成できるようにした方が良いですね。

モブプロ・ペアプロを活用し、文字でのやりとりを最小限に

実装開始時に口頭で実装方針をすり合わせておくと、レビュー時に理解しやすくなります。
また、レビュー後に大きな認識ズレがある場合、文字でやりとりするよりも、実装者とペアプロをしたほうが効率的です。

モブプロやペアプロとまではいかなくても、レビュー前にコード説明会のようなものがあるとレビュワーの負担が軽減されます。

変更箇所にコメントを入れて読みやすくする

複雑な処理にはコメントを入れておくことで、レビュー者が理解しやすくなります。
これはレビュワーだけでなく、今後コードを読むすべての人にとっても有益です。

変更の意図をPRにコメントする

「なぜこの実装方法にしたのか?」をPRの説明やコメントに記載すると、レビュー者にとって親切です。

過去に、PR内で「本当はこうしたかったができなかった」「この変更にはこういう意図がある」などの説明があった際、意図の確認が不要になり、コミュニケーションコストが削減されました。

この種のコメントはコード自体には不要ですが、レビュー者向けには有効です。

要件の確認はテストコード・テストで担保する

複雑な要件の場合、まず要件を理解するのに時間がかかります。
特に、要件定義の担当者とコードレビュー者が異なる場合、要件を把握するのに想定以上の工数がかかることがあります。

そのため、仕様を満たしているかどうかは、テストコードやテストによって担保するのが望ましいです。

弊チームでは「動作確認チェックシート」を用意しており、設計時に作成したテストケースを確認することでも担保できます。(基本的にはテストコードを書く運用になっています)

影響範囲の大きい変更は、別コードとして切り出す

複数箇所で使用されているコードを修正すると、関係のない機能にも影響が出る可能性があります。

そのような場合、対象機能専用のクラスやメソッドに切り出すことで、影響範囲を限定するのが望ましいです。
影響範囲を限定することで、コードレビューの負担も軽減できます。(既存のコードを直接修正するより、新規追加のほうがレビューしやすい)

今後のためにも、不要な結合はどんどん分離してゆきたいところ。

最後に

この記事は、コードレビュー時の辛かった話を愚痴るためのものではありません。
むしろ、これまで自分が「分かりにくいPR」を依頼していたことを反省し、改善するためのものです😇

自分が実装していて「分かりにくい」「複雑だな」と感じた部分は、レビュワーも同じように感じるはずです。
読み手のことを考えた実装を心がけたいと、改めて思いました。

レビュワーに分かりやすいコードにすることでコードの質が上がり、
さらにレビュワーがレビューに集中できることでもコードの質が上がるはず!

良きコードレビュー生活を送りましょう🏡

補足

「Tidy First?」を読んでみて

書籍の中に「コードを読んでいて、『先にこの情報を得られていればもっと早く理解できたのに…』と感じる情報は、次の読み手にとっても同じである。」といったような表現がありました。

自分が実装者のとき、既存のコードを読み解くのに時間がかかると、「自分の理解力が低いせいだ」と思いがちでした。しかし、上記を読んで「レビュワーにも分かりにくいはず🧐」と考えてよいのだと気づきました。

そう考えれば、「レビュワーのために補足が必要だな」という意識になり、コメントを残したり、説明会を開いたりといった対応ができます。
また、レビュワーだけでなく、今後コードを変更する人すべてのために、適切なコメントを追加したり、リファクタリングを行うことが重要だと改めて感じました🐈‍⬛

参考

  • ケント・ベック(2024)『Tidy First? ―個人で実践する経験主義的ソフトウェア設計』オライリー・ジャパン.

Discussion