皆さん、レビューしてますか？
読むのに時間がかかったり、どこまで突っ込んでいいのか迷ったり、そもそも何を見ればいいのかすらわからなかったりして、どうにも苦手だという方も多いのではないでしょうか。
レビューが難しいと感じる場面はいろいろあります。
そもそも実装されたのが何の機能かわからない、用語が理解できない、見る量が多すぎる…etc
読む前に立ち止まるポイントが多いと、それだけで負荷が上がります。
こうした小さなつまずきが積み重なると、レビューそのものが負担になったり、億劫になってついつい放置してしまう結果になりがちです。
さて、私自身もレビューが得意というわけではないのですが、Recustomerに入社して開発を続ける中で少しずつ苦手意識が薄れてきたように感じています。
そこで今回は、私自身の負担が軽くなった経験をもとに、レビューをしやすい、されやすい世界にするための取り組みを、
- 個人で今日からできること
- チームで実施すると楽になること
に分けて紹介してみたいと思います。
「レビュー苦手なんだよな…」と思っている方や、レビュー文化をもう少し良くしたい方にとって、ちょっとした参考になれば幸いです。
個人で今日からできること
まずは、自分ひとりでも意識しやすく、レビューが負担になりやすい場面ごとに、その改善案についてまとめてみます。
場面1. PR が大きすぎて開いた瞬間に後回しにしてしまう
差分が多い PR は、それだけで読む負荷が上がり、どうしても後回しにしやすくなります。
UI の調整・バグ修正・リファクタのように、性質の違う変更が混ざっていると本題が見えづらく、読み進めるのに余計な時間がかって、後でまとまった時間に見よう…となりがちです。
改善案: 1つの PR に目的を詰め込まない
- 仕様変更、バグ修正、リファクタなどはできるだけ分ける
- UI / ロジック / リファクタは混ぜない
正しく分けることより、混ぜないことを意識するとPRの粒度はいい感じになる気がしています。
なお、必ず1つの目的という粒度で区切る必要はなく、私たちのチームではドメイン・ユースケース・アダプタなど、責務のレイヤーごとに PR を分けることが多いです。それでも大きいのであれば、さらに分けても良いと思います。
場面2. 背景や意図が分からず、レビューの入口に立てない
PR を開いてもそれが何を解決する変更なのか、どういった理由で必要になったのかが分からず、実装内容を理解するのに過剰に時間がかかることがあります。
背景が見えない状態だとコードから推測するしかなく、余計な脳の負荷もかかりますよね。
改善案: 実装背景と実装内容の概要は共有する
- PR の description に、変更の背景や概要は必ず書く
- 判断が揺れた箇所や特に見てほしい部分はコメントで補足する
背景とポイントが分かっているだけで、コードを読むことへの心理的な抵抗が減ります。
レビューが「読み解く作業」から「確認する作業」に近づくので、入りやすさがぐっと変わるはずです。
場面3. 自分の知識ではカバーしきれず、レビューを諦めてしまう
知らない領域や複雑な処理が多いと、この部分理解できていないけどコメントして大丈夫かなと不安になったり、全然わからないけど多分大丈夫なんだろうと読み流してしまうことがあります。
全部を理解しようとするほど負荷が高まり、結局レビューそのものが止まってしまうこともあります。
改善案: 自分が見られる観点に絞ってチェックする
レビューは、PR 全体を深く把握しないと実施できないというものではなく、自分の知識で判断できる部分を押さえるだけでも、十分に価値があるものだと思います。
例えば、初めは以下のような観点に絞ることを意識すると手をつけやすいと思います。
- 関数や変数の命名は動作を表現できているか
- 1つの関数内でさらに複数の処理を行うスーパー関数ができていないか
- エラーハンドリングが適切か
- 型定義が適切なのか
このようにどこを見るべきか意識しておくと、手探りでレビューをするよりもかなり負荷が下がるのではないでしょうか。
チームで実施すると楽になること
ここからは、同様によく陥ってしまう場面ごとに、チーム単位で取り組むのにおすすめな改善について紹介します。
すでに仕組みが整っている方も多いと思いますが、効果を感じたものを並べているのでぜひ目を通してもらえると嬉しいです。
場面1. PRのフォーマットがバラバラで、読む前に疲弊する
機能の箇条書き、概要のみ、URLのみ、画像のみ、などなど、
フォーマットが定まらない状況ではいろんな人が自由な形式でPRを作成し、中には必要な情報が足りず、レビュー時に推測するしかない(or本来不要な質問のやり取りが発生する)ケースがあります。
改善案：PR テンプレートを準備してみる
- (タスクのチケットURL)
- 実装背景
- 変更内容の概要
- デザインの画像などあれば
個人でできることでも変更の背景や概要は必ず書く点について触れましたが、これをチーム単位でフォーマットとして扱えると、人によって大きく書き方がブレることなく進められて良いと思います。
このくらいの情報が前提として揃っていれば、レビュー箇所についてあまり触った経験がなくともレビューに着手することができるのではないでしょうか。
場面2. 用語のズレによって、認識もズレている
仕様や概念の呼び方が人によって違うと、変数名や関数名、コメントの意味にズレが生まれ「あれはこの機能とは別物？」のような推測や誤解が生まれやすいです。
改善案：ユビキタス言語を定義して共有する
- 概念の名前と意味について共通認識を持つ(モデルレビューなどで認識を合わせる)
- PR・Issue でも同じ用語を使う
共通の言葉があるだけで、前提をそろえるための説明が減り、レビューのやり取りもスムーズになります。
コードの内容そのものに集中しやすくなるので、無駄な読み直しや確認も少なくなるはずです。
場面3. レビュアーが動作確認まで担ってしまっている
単体テストがない変更は、レビュアーがそもそも動くのかという点から意識しなければならず、どうしても負担が大きくなります。
改善案：単体テストで最低限の動作を担保する
- 基本的な動作の正常系だけでもテストを書く
- テストが落ちれば壊れていることが分かる状態をつくる
テストで最低限の動作が保証されているだけで、レビュアーは構造や意図の確認に集中しやすくなるのではないでしょうか。
レビューの範囲を動作の確認から切り離せるため、レビュー時の余計な考え事を少なくすることができます。
場面4. レビューしやすい、されやすい空気がない
これが正直一番重要だと思っている点です。
これは個人でも着手可能なものですが、チームとして実行しないと改善しないと考えているので、チームで取り組むこととして記載しています。
レビューはコードに対して行うものですが、どうしても人のコミュニケーションが絡みます。
指摘する側もされる側も構えてしまう空気があると、単純にやりづらく、レビュー文化の妨げになりそうです。
改善案：レビューに関する空気をチームで良くしていく
- 詰めるのではなく、実装の意図を聞く
- コメントは質問ベースで書く
- 「なぜ」「どこを」「どうしてほしいか」を明確にする
- 実装、レビューありがとうございます、の文化を大切にする
心理的安全性があるだけで、指摘や質問が攻撃ではなく協力として受け止められるようになります。
安心して意図を伝え合える環境があると、レビューに余計な緊張がなくなり、より一層実装が捗ること間違いなしです。
おわりに
レビューにはどうしても手が止まりやすいポイントがいくつかありますが、
今回挙げたような改善の取り組みが積み重なっていくと、徐々に取り組みやすい状態に近づいていくように思います。
全部を一度に変える必要はなくて、「これならできそうだな」と思ったところから試してみてもらえるだけでも十分です。
書く側も、読む側も、少しでも気持ちが楽になればそれで良いのだと思います。
それでは、良いレビューライフを〜！
Discussion