この記事を読むとできるようになること
Github上でのプルリクエストレビューを円滑に進めるためのポイント、建設的なコミュニケーションを行うために必要なことを理解できる。
レビューアー
自分の作業よりも優先的にレビューする
すぐにレビューしないと、レビューイに仕掛かりのタスクが溜まっていき、生産性が低下したり、コンフリクトしたりしていいことがないので、レビュー依頼が来たら、自分の作業の手を止めてまず優先的にレビューすること
レビューコメントの意図を明確にする
- 単なる質問
- 確認
- 修正の提案
修正の場合、その修正が必須なのか、時間があればして欲しい程度のものなのか明記する。また、必要に応じて、コードの修正案を具体的に提示する
コメントのPrefixなどに区分を書くだけで、認識の齟齬が生まれにくくなるのと、無駄なやりとりが増えるのを防止できる
建設的なレビューコメント
人格否定するようなコメント、高圧的なコメント、マウントを取るようなコメント、人を不快にさせるようなコメントはしない
- 〜するべきです、〜は絶対にやめてください（〜Aは、Bの観点であまり好ましくないため、Cの方が良いと思います。）
- 婉曲表現（角の立たない言い回し）を意識する
レビューイ
適切なプルリクエストの粒度
1プルリクエストには20〜30ファイルを目安に
ファイルが多すぎると、レビューするモチベーションが低下したり、困難になったりするので、多くても30ファイルくらいに
ローカルでのテストを入念に行う
動作保証のないコードをレビューしても二度手間になってしまうので、レビューしてもらう前にまずはローカルでしっかり動作検証すること。また、TODOがあれば、そのコメントを。自動テストで動作保証をしておくことも重要
プルリクエスト自体へのコメント
プルリクエストの概要、目的などを記載する。レビューアーが背景を理解できるように
関連ドキュメント、チケットのリンクを貼る
共通で使えるクラスや関数を作ったら、明示的に共有するようにする
複雑な内容であれば、必要に応じて口頭説明を
レビューの目的は、双方が協力／協働してソースコードを改善することなので、レビューがしにくい理由があればそれを除去できるように積極的に働きかける
File Changedへのコメント
コード上にメモやTODOを残して、File Changedタブの該当の箇所に補足のコメントを書くようにするとベター
NOTE, IMPORTANT（Markdown記法）などの重要度をつけて、コメントを区別することで、レビューを効率的に行ってもらえるようにする
修正する場合はその内容とコミット番号を
単に修正しました!だけではなく、何をどう修正したのか、該当のコミット番号のリンクを添付して返信する（レビュアーはリンクをクリックするだけで、意図した修正が行なわれているか確認できる
コメントには必ず全て返信する
返信できていないスレッドがないか、確認することが大事。また、同じスレッドに返信することで後から追いやすくなる
レビューしてもらえる段階になるまでは、WIPをつける
WIP（Work In Progress）をプルリクエストのタイトルにつけることで、まだレビューできる段階でないことを他の開発メンバーに共有する
レビュー内容に対して素直に受け入れる
一旦指摘された内容を素直に受け入れ、自分の中で整理し、コードの改善につながると感じた場合はフィードバックを取り入れること。（ただし鵜呑みしすぎるYESマンもよくない）
共通
!や絵文字を使う
「！」や絵文字をつけるとトゲがなくなる、柔らかい表現になる。普段のテキストコミュニケーションでも
まとめ
いかがでしたでしょうか。本記事では、Github上でのプルリクエストレビューを円滑に進めるためのポイント、建設的なコミュニケーションを行うために必要なことを紹介しました。開発プロセスにおいてレビューはとても重要ですので、ぜひ参考にして試してみてください。