レビュイーができること

レビュイーは構築を担当しているので基本的に要件や実装内容、テスト内容を最もしているはずです。

一方でレビュワーはそのタスクがどのような目的で実装されたのかを事細かに知らないことがあります。

レビュイー目線で当たり前になっていることもレビュワーは知らないことがあるので、プルリクを作成するときにはそのタスクの変更の背景/目的、実装方針と内容を一目で読んでわかるように明記することが重要です。

実装内容を事細かに説明しても、その動作が正常に行われているかどうかはコードを読むだけではわからないことも多い。

もし動作確認の内容を伝えなかったらレビュワーは実装内容をローカルに落としてデータを準備して、実行して動作チェックをすることで何重にも確認のための作業が必要になります。

プルリクを作成するときに動作確認内容を明記することでレビュワーはその内容を参考にして動作確認を行うことができ、レビュワーの負担を減らすことができます。

自分をジュニアと思っていても、ある程度経験をしたエンジニアだと思っていても実装や設計に迷うことはもちろんあると思います。

実際にコーディングしていてもしっくりこなくてより良い方法がありそうなものの思いつかないなど人に相談したいことは少なくないと思います。

そんな時にはXXXについてもっと良い書き方があればコメントがほしいという感じでレビュワーにアドバイスを求めちゃいましょう。

（レビュワーもきっとアドバイスをしてくれるはずだ）

レビューの価値はコードや設計を第三者の目を通して確認してもらい品質を向上させることだと思っています。

この営みの中でスペルミス、タイポ、誤字脱字などはレビュワーにとっては上記の目的を達成するためのノイズになってしまいます。

レビュイーもレビュワーに求めるコメントはコードや設計に関するものであって、スペルミスや誤字脱字に関するものは求めていないと思います。

このようなノイズを減らすためにはレビュイーがプルリクを出す前にセルフレビューをして極力減らすことが重要。

プロジェクト内のコードの品質を自動で高めるためにCIでLinterやFormatter、自動テストを実行していることが多いと思います。

その中で規定されているルールに反してCIが通らない状況でプルリクを出すとレビュワーはその部分に対してコメントをすることになります。

この連絡のラリーはレビュワーの時間を奪ってまでやることではないと思うのでCIが通っているかを確認してからプルリクを出しましょう。

仕組み的な解決方法

GitHubではプルリクを作成するときにテンプレートを作成しておくことができます。

プルリクエストを作成するときに自動でtextboxにテンプレートが表示されるので、そのテンプレートに沿って情報を入力することでレビュイーに必要な情報をぬけもれが少なくなります。

レビュイーができることをまとめました。

意識的にセルフレビューをしてテンプレートを使って効率にレビューをしていきましょう！