チーム開発において効率的にレビューしてもらうことはタスクを円滑に進めるために重要です。
コードの構築や設計をする時間が支配的になると考えがちですが、レビューを依頼して承認をしてもらうことで初めてタスクが完了します。
そんなレビューの時間を効率的にできることをレビュイーができることたちを紹介します。
最後にちょっとした仕組み的な解決方法も紹介します。
レビュイーができること
どのような目的タスクなのかを明記する
レビュイーは構築を担当しているので基本的に要件や実装内容、テスト内容を最もしているはずです。
一方でレビュワーはそのタスクがどのような目的で実装されたのかを事細かに知らないことがあります。
レビュイー目線で当たり前になっていることもレビュワーは知らないことがあるので、プルリクを作成するときにはそのタスクの変更の背景/目的、実装方針と内容を一目で読んでわかるように明記することが重要です。
動作確認、テストの結果を明記する
実装内容を事細かに説明しても、その動作が正常に行われているかどうかはコードを読むだけではわからないことも多い。
もし動作確認の内容を伝えなかったらレビュワーは実装内容をローカルに落としてデータを準備して、実行して動作チェックをすることで何重にも確認のための作業が必要になります。
プルリクを作成するときに動作確認内容を明記することでレビュワーはその内容を参考にして動作確認を行うことができ、レビュワーの負担を減らすことができます。
特に構築しているときに迷ったことなどアドバイスしてもらいたい箇所を明記する
自分をジュニアと思っていても、ある程度経験をしたエンジニアだと思っていても実装や設計に迷うことはもちろんあると思います。
実際にコーディングしていてもしっくりこなくてより良い方法がありそうなものの思いつかないなど人に相談したいことは少なくないと思います。
そんな時にはXXXについてもっと良い書き方があればコメントがほしいという感じでレビュワーにアドバイスを求めちゃいましょう。
（レビュワーもきっとアドバイスをしてくれるはずだ）
タイポや誤字脱字をレビュー依頼前にレビューに出す前に修正する
レビューの価値はコードや設計を第三者の目を通して確認してもらい品質を向上させることだと思っています。
この営みの中でスペルミス、タイポ、誤字脱字などはレビュワーにとっては上記の目的を達成するためのノイズになってしまいます。
レビュイーもレビュワーに求めるコメントはコードや設計に関するものであって、スペルミスや誤字脱字に関するものは求めていないと思います。
このようなノイズを減らすためにはレビュイーがプルリクを出す前にセルフレビューをして極力減らすことが重要。
Linter, Formatter, 自動テストなどのツールを使って反している部分はレビューに出す前に修正する
プロジェクト内のコードの品質を自動で高めるためにCIでLinterやFormatter、自動テストを実行していることが多いと思います。
その中で規定されているルールに反してCIが通らない状況でプルリクを出すとレビュワーはその部分に対してコメントをすることになります。
この連絡のラリーはレビュワーの時間を奪ってまでやることではないと思うのでCIが通っているかを確認してからプルリクを出しましょう。
仕組み的な解決方法
.github/PULL_REQUEST_TEMPLATE.mdの作成
GitHubではプルリクを作成するときにテンプレートを作成しておくことができます。
プルリクエストを作成するときに自動でtextboxにテンプレートが表示されるので、そのテンプレートに沿って情報を入力することでレビュイーに必要な情報をぬけもれが少なくなります。
まとめ
レビュイーができることをまとめました。
意識的にセルフレビューをしてテンプレートを使って効率にレビューをしていきましょう！