はじめに
コードレビューを依頼するとき、どんな気持ちでお願いしていますか？
自分が始めたての頃は、「チェックしてもらえてありがたいなあ」くらいの考えでした。
コードレビュー依頼とは、いわば責任の共有依頼です。
つまり、本質はそれほどカジュアルなものではありません。（依頼しやすい関係性は別として）
コードレビューを通したレビュアーには、品質の保証をしたという責任が伴います。
通したコードが不利益を生んだ場合には、レビュアーも責任を負わなければなりません。
そのリスクを負ってもらうことに対し、レビュー依頼者（reviewee, 以下レビューイと呼びます）」が果たすべき義務は、レビュアーが最小限のコストで効果的にレビューできるように最大限努力することです。
その努力の具体的な方法を、以下に書いていきます。
効果的/効率的なレビューをしてもらうために
👨💻 開発で気をつけること
レビューに必要なコストは、開発時点で半分以上決まると言っても過言ではありません。
具体的には以下の４点です。
1. 読みやすいコードを書こう
読みやすいコードを書くことは、コード品質を高め、結果的にレビューコストを下げることができます。
意図の伝わりやすい実装、命名を心がけ、読みやすいコードにしましょう。
より詳しい読みやすいコードの書き方については、リーダブルコードなどの書籍や他の方の記事をご参照ください。
2. Linter, Formatterを利用しよう
コード規約、フォーマットに関しての指摘・修正は基本的に人間のやることではありません。
pre-commit hookやVS CodeのcodeActionsOnSaveなどを利用し、自動的に実行されるようにしましょう。
2. コミットを分けよう
コミットを細かく分けることで、小さい粒度でレビューできるようになります。
レビューにおいてのみでなく「変更の経緯を追いやすい」「ロールバックしやすい」などのメリットがあります。
3. プルリクエストが大きくならないようにしよう
差分ファイル数や変更行数があまりに多いと、レビューがちょっと億劫になりますよね。
仕様設計・工数見積もりの段階で差分が膨らみそうだと思ったら、まずは親ブランチを作り、そのブランチへのプルリクエストを小さく作るようにしましょう。
そうすることでレビュー機会を分割することができます。
4. セルフチェックをしよう
レビューでの指摘を減らす為に、あらかじめ自分で確認することで手戻りを防ぎましょう。基本的には以下のようなことです。
- 仕様を満たせているか
- 読みづらくなっている部分はないか
- 動かしてみて不具合はないか
ただし、個人的な経験ではセルフチェックでは自分を正当化するバイアスがかかりやすい為、客観性を意識的に強めるようにしましょう。
🛠 合同レビュー
レビューを依頼する相手にとって、あまり知らないシステム、大規模な変更のレビューなどは非常に読解コストが大きいです。
そのようなケースでは、合同でレビューする場を設けましょう。
仕様や実装について説明を行い、コミュニケーションをとりつつレビューを進めていきます。
🏷 プルリクエスト
概要を書こう
満たすべき要件を共有しましょう。
具体的にはIssue、チケットへの関連付けです。
「システム要件を満たしているか」は、レビューしてもらうべき重要な要素の一つ、大前提になります。
システム仕様
システム要件を実現するために、どのように実装したかを記述しましょう。
書き方は様々あると思いますが、コアになる部分と、追加した/関連するテストを書くようにしています。（カバレッジ部分から注意して見るべきロジックの場所がわかる）
「わかりにくいところをわかりやすくする」ために書く、ということを念頭に置きましょう。
画像や図
画面に変化がある場合などはスクリーンショットを添付するとより伝わりやすいです。
必要に応じて注釈を加えましょう。（Mac付属のプレビューで簡単にできます）
🗣 コミュニケーション
レビューでコメントをもらったら、必ず返信(リアクション)するようにしましょう。
必要に応じて意見を述べ、修正し、再度確認を依頼しましょう。
このときビジネスのスピードとの塩梅で、対応するべきかどうか迷うこともあると思います。
基本的にはレビューイが仕様・実装・事業的優先度を最も把握できている ので、責任を持って判断してください。
もちろん、必要に応じてチームと相談するようにしましょう。
まとめ
一貫して大切なのは、相手がどうしてくれたら嬉しいのか考えること、思いやる気持ちです。
コードレビューは依頼する側、される側の双方の歩み寄りでより効果的・効率的に実施できます。
その実現のためには、逆の立場の視点を持つことが効果的です。
レビュアーの視点についても書いているので、ぜひ読んでみてください。