この記事は ZOZOテクノロジーズ #5 Advent Calendar 2019 12日目の記事です。
昨日は @r-tezuka さんによる vue-cli+Typescriptな環境でTSLintからESLintに移行する方法 でした。
前書き
以下に書いてある内容は、いろんな方のQiitaの記事等を見て自分で実践してみた結果やチームで実践している内容を踏まえて個人的見解で書いています。
そのため、完全な正解ではないです。
参考にしていただいて、チーム内でどうしていくのが自分たちにあっているかを議論するきっかけになればと思います。
～ブランチを切ってからプルリクを出すまで～
最初のコミットは空コミットにしよう！
理由 : 最初のコミットはrebase等がやりづらいらしい、、、
また、別の利点として、コードを書き始める前からプルリクを作ることができる！
（プッシュしないとプルリクは作れない。プッシュするためにはコミット必要。じゃあ空コミットさえしておけばプルリク出せるよね！）
# ファイルをステージしていない状態での最初のコミット
git commit --allow-empty -m "First Commit"
Ref : Gitの最初のコミットは空コミットにしよう
プルリクは早くから出そう！
理由 : プルリクを早くから出せば、部分的にレビューしてもらえるため。
大きな内容を最後にまとまって見るような状況だと、レビュワーは締め切りまでに入念に確認できない可能性ある！
Ref : さっさとプルリクを出そう
プルリクは小さく！
理由 : プルリクが小さいと、開発・レビューのサイクルスピードが上がる！
Ref : 十分小さくプルリクを作ろう
プルリクのタイトルは修正内容が簡単にわかるように！
概要がわかるようにタイトルを書こう！（可能な限り具体的に、かつ簡潔に！）
OK : LP内のフッター画像を差し替え
NG : LP修正 -> 何を修正したかわからない
プルリクを出す時点でまだフィックスしてなければドラフトで作ろう！
理由 : 「ドラフト」は日本語で「下書き 」という意味なので、レビュワーには作業中であることが伝わる！
Ref : GitHubのドラフトプルリクエストを試す
※ドラフト状態だとレビュー依頼に気付きにくいので開発がある程度終わった時点で Ready For Review にする
※もしくはいつ Ready For Review になるのか明記する！
プルリク作成時にディスクリプションを書こう！
理由 : 自分以外の人がプルリクを見たときにどういった開発内容なのか、なにが行われるのか等がわかりやすくなる！
もろもろ、リリースに向けて必要な情報や関係担当者以外が見てもわかるようにしておくのがベター！
ディスクリプションのテンプレートが用意されていれば記入できるところは記入しよう！
※用意されていなければテンプレ作ろう！（テンプレに書く項目はチーム内で議論しよう！）
Ref : Pull Request のフォーマットを決めるとレビューの効率が3倍よくなる
～プルリクをレビューしてもらうまで（レビューされる側）～
レビュワーが楽になるように処理概要がわかるコメントを書こう！
理由 : レビュワーはレビュー期限までに見なければいけないというプレッシャーが少なからずある！
そんな中、複雑な処理をレビューしてもらうとまとまった時間が必要になる。
そのまとまった時間をとることが難しい状況もあるだろう。
また、レビュワーはレビュー依頼が複数存在するのが基本のシチュエーション。
そのため、少しでもレビュワーの負担を下げるためにコード内のコメントやプルリクでのコメントによって読む側の理解しやすさを向上させよう！
コミットメッセージにプレフィックスつけよう！
理由 : コミット単位でレビューする際に一目で修正の種類がわかる！
テキストではなく、絵文字にするとプルリクが殺伐とせずにポップに見える！（個人的意見）
Add
Fix
Delete
Bug Fix
Refactor
:sparkles: Add
:hammer: Fix
:fire: Delete
:bug: Bug Fix
:recycle: Refactor
レビュワーをアサインする
理由 : レビュワーにアサインせずに、Slack等でレビュー依頼をしても忘れることがある！
GitHubと連携してレビュワーにリマインドするツール等もあるのでレビュワーは必ずアサインしよう！
再度レビューしてほしいときは Re-request review！
一度レビューしてもらったあとに追加が発生した場合、再度レビュー依頼を出す必要がある。
そんな時は Re-request review をする！（キャプチャの
を押すとできるよ！）
以上、新卒エンジニア（入社1年半くらいですけど、、、）がチーム開発でGitHubを使うときに気を付けていること（レビュイー編）でした！
明日も @saitoryuji がレビュアー編について記事を書きます！ぜひご覧ください！