コードレビューの心理的負荷を下げたい
背景
コードレビューの依頼が来ると、少し気が重くなることはありませんか?
私はよくあります😇
過去にレビューを依頼した方々も、同じように感じていたのではないかと思います。
なぜなら、私の作成したPRは「レビューしにくいPR」だったという自覚があるからです。
今回は、自分の経験や参考資料をもとに、「どうすればコードレビューの心理的負荷を軽減できるか?」についてまとめます。
コードレビューの目的は?
一般的な定義はさておき、自チームではどのような目的でコードレビューを行っているのかを整理すると、主に以下の点を確認するためです。
- 要件を満たしているか
- バグ、リグレッションは発生しないか
- コーディング規約に違反していないか
- 性能面、可読性、保守性は問題ないか
どういうときに心理的負荷が高いと感じるのか?
私は、以下のような状況で「コードレビューしないと……😮💨」という気持ちになりやすいです。
- 変更行数が多い
- 自分が持っているタスクが他にある
- レビューのやりとりが多く、コミュニケーションコストが高い
- 要件理解から必要
- 既存コードの理解から必要
- 既存が複雑な場合、ここで工数がかかる
- 実装者も同じところで時間がかかっている場合、実装者とレビュワーで同じところに工数をとられていることになる
- 自分が最後の砦感がある
- 問題が起きると「コードレビューちゃんとしたの?😇」みたいな感じになる(言われたことはない)
どうすれば心理的負荷を軽減できるか?
変更範囲を小さくする
他チームからのレビューを受けた際、PRの変更範囲が最小限に抑えられていたことがありました。
そのときは非常にレビューしやすく感じました。(後から聞いたら、レビューしやすさを意識したPRだったらしく、感謝感激でした)
「小さい」とはどの程度か明確に定義するのは難しいですが、そのときは1~2ファイルの変更を1つのPRとしていました。
私のチームでは、1PBIにつき1PRというルールがあるためPRの範囲を決めるのは実装者ではなくPBIの作成者になってしまっています。
しかしPBI作成時にはコードの変更範囲は分からないはずなので、実装者が判断してPRを作成できるようにした方が良いですね。
モブプロ・ペアプロを活用し、文字でのやりとりを最小限に
実装開始時に口頭で実装方針をすり合わせておくと、レビュー時に理解しやすくなります。
また、レビュー後に大きな認識ズレがある場合、文字でやりとりするよりも、実装者とペアプロをしたほうが効率的です。
モブプロやペアプロとまではいかなくても、レビュー前にコード説明会のようなものがあるとレビュワーの負担が軽減されます。
変更箇所にコメントを入れて読みやすくする
複雑な処理にはコメントを入れておくことで、レビュー者が理解しやすくなります。
これはレビュワーだけでなく、今後コードを読むすべての人にとっても有益です。
変更の意図をPRにコメントする
「なぜこの実装方法にしたのか?」をPRの説明やコメントに記載すると、レビュー者にとって親切です。
過去に、PR内で「本当はこうしたかったができなかった」「この変更にはこういう意図がある」などの説明があった際、意図の確認が不要になり、コミュニケーションコストが削減されました。
この種のコメントはコード自体には不要ですが、レビュー者向けには有効です。
要件の確認はテストコード・テストで担保する
複雑な要件の場合、まず要件を理解するのに時間がかかります。
特に、要件定義の担当者とコードレビュー者が異なる場合、要件を把握するのに想定以上の工数がかかることがあります。
そのため、仕様を満たしているかどうかは、テストコードやテストによって担保するのが望ましいです。
弊チームでは「動作確認チェックシート」を用意しており、設計時に作成したテストケースを確認することでも担保できます。(基本的にはテストコードを書く運用になっています)
影響範囲の大きい変更は、別コードとして切り出す
複数箇所で使用されているコードを修正すると、関係のない機能にも影響が出る可能性があります。
そのような場合、対象機能専用のクラスやメソッドに切り出すことで、影響範囲を限定するのが望ましいです。
影響範囲を限定することで、コードレビューの負担も軽減できます。(既存のコードを直接修正するより、新規追加のほうがレビューしやすい)
今後のためにも、不要な結合はどんどん分離してゆきたいところ。
最後に
この記事は、コードレビュー時の辛かった話を愚痴るためのものではありません。
むしろ、これまで自分が「分かりにくいPR」を依頼していたことを反省し、改善するためのものです😇
自分が実装していて「分かりにくい」「複雑だな」と感じた部分は、レビュワーも同じように感じるはずです。
読み手のことを考えた実装を心がけたいと、改めて思いました。
レビュワーに分かりやすいコードにすることでコードの質が上がり、
さらにレビュワーがレビューに集中できることでもコードの質が上がるはず!
良きコードレビュー生活を送りましょう🏡
補足
「Tidy First?」を読んでみて
書籍の中に「コードを読んでいて、『先にこの情報を得られていればもっと早く理解できたのに…』と感じる情報は、次の読み手にとっても同じである。」といったような表現がありました。
自分が実装者のとき、既存のコードを読み解くのに時間がかかると、「自分の理解力が低いせいだ」と思いがちでした。しかし、上記を読んで「レビュワーにも分かりにくいはず🧐」と考えてよいのだと気づきました。
そう考えれば、「レビュワーのために補足が必要だな」という意識になり、コメントを残したり、説明会を開いたりといった対応ができます。
また、レビュワーだけでなく、今後コードを変更する人すべてのために、適切なコメントを追加したり、リファクタリングを行うことが重要だと改めて感じました🐈⬛
参考
- ケント・ベック(2024)『Tidy First? ―個人で実践する経験主義的ソフトウェア設計』オライリー・ジャパン.
Discussion