この記事は ZOZOテクノロジーズ #5 Advent Calendar 2019 13日目の記事です。
昨日は @saitoryuji による 新卒エンジニアがチーム開発でGitHubを使うときに気を付けていること（レビュイー編） でした。
前書き
以下に書いてある内容は、いろんな方のQiitaの記事等を見て自分で実践してみた結果やチームで実践している内容を踏まえて個人的見解で書いています。
そのため、完全な正解ではないです。
参考にしていただいて、チーム内でどうしていくのが自分たちにあっているかを議論するきっかけになればと思います。
～プルリクをレビューするまで（レビューする側）～
【Must】否定的な言葉は使わない！
理由 : レビュイーの心理的安全性を保つため！
本当にひどいコードだったとしても伝え方は考えよう！
コードを書いた側は時間を使って、自分の中での正解と思われるコードを書いたはず。
それを頭ごなしに否定されると人格を否定されたと感じる場面もあるだろう。
絶対に相手を批判するような内容のレビューはしない！！！！
思いやりを持ってレビューしよう！
Ref : Pull Requestのレビューが辛くて会社をやめたい
Ref : コードレビューは粗探しや指示ではない
レビュワーは早くレビューをしよう！
理由 : プルリクのレビューがなかなか終わらず次の作業に入れないという状況を防ぐため！
チーム内で無理のないレビュー期限を設けよう！
期限までにレビューが終わらない場合はその旨だけでもコメントするとレビュイーは安心！
Ref : レビュワーやasigneeはすぐにプルリクを見よう
レビューコメントにラベルを付ける
理由 : レビュー内容の優先度がわかるようになる！
また、必ずしも修正しなければいけない内容ではないが、一応コメントしておきたいときに便利。
[must] 必ず対応してほしい！ロジックにバグがある！
[imo] 自分の意見や提案・好み。 自分ならこう書くけどどうかな？
[nits] 些細な指摘。 ほんの小さな指摘だけど出来れば直してほしい。インデントやタイポ、コード規約
[ask] 質問,確認。 コードの意味や背景が分からないから教えて！こういう理解でOK?
Ref : レビューコメントにラベルをつけるだけで開発効率があがって幸せになれそうな話
Resolve Conversations は積極的に使っていこう！
理由 : コメント内容が解決したことがわかるため！
あとはプルリクが縦に長くなって可読性が下がることを防ぐため！
基本的には最初にコメントを書いた人がResolveする！
例1
レビュワー : この処理ってどうなってますか？
レビュイー : ほげほげになってます！
レビュワー : なるほど！ありがとうございます！ ←この時点でレビュワーがResolveする！
レビュワー : この処理はこのままでも問題ないけど、こうしたほうが可読性上がりそうですね！
レビュイー : なるほど！以下のコミットで修正しました！（コミットIDつける）
レビュワー : 確認しました！修正ありがとうございます！ ←この時点でレビュワーがResolveする！
Ref : https://qiita.com/azujuuuuuun/items/b93f33e6135228bcdec5
レビュワーにアサインされていないプルリクも積極的に見よう！
理由 : できるだけいろんな人のコードを見て他人の知識を吸収しよう！
アサインされている人以外のレビューで気付ける点があればなおよし！
レビュワーにアサインされてないのになんでレビューしたんだよ！って怒る人がいなければ積極的にやろう！
コーディングに自信がない人でもレビューをする！
理由 : レビューとは、指摘・アドバイスをすることではない！
自信がない人は他人のコードをみて、どうしてこの書き方にしたのか？というような質問もレビューでしてみよう！
また、自分ができてないことでも臆さずレビューに書くことも大事！
Submit Review を使い分けよう！
理由 : レビューした結果、どういった状態かわかるようにするため！
Comment : 軽微な指摘、コメント
Approve : 承認
Request Change : 修正依頼
～レビュー完了後～
マージが完了後ブランチの削除をしよう！
理由 : 対応完了したブランチが残っているとブランチを探すときにノイズが多くなって効率が下がるため！
マージした人は積極的に削除をしよう！
使いおわったおもちゃを片付けるのと同じ！
※削除してもリストアもできるので安心だよ！
～もっとGitHubを使いやすくするために～
Pull Panda を導入しよう！
理由 : 自分がアサインされているプルリクやレビュー待ちのプルリクのリマインドがSlackに送られてくるので便利！
Ref : 無料になった Pull Panda を GitHub に導入すると、Pull Requestのやり取りが自動化されて便利に！！
以上、新卒エンジニア（入社1年半くらいですけど、、、）がチーム開発でGitHubを使うときに気を付けていること（レビュアー編）でした！
明日は @ikeponsu さんが記事を書いてくれます！乞うご期待！