概要
GitHubでのコードレビュー依頼する側のマナー・注意点についてまとめています。
この記事で伝えたいこと
コードレビューは、より良いコードの書き方を学べる一番の機会だと考えています。
なので、コードレビューの機会をどんどん増やしてほしいと思います。
しかし、他人の書いたコードというのは自分が書いたものの何倍も労力を使います。
そのため、依頼される側の負担を減らすためのマナーを少しでも身につけてほしいと思い記事を書きました。
前提条件
- git flowにおけるfeatureブランチでのPullRequestを想定
- １つの機能ごとにブランチを切っていることを想定
※あくまで個人的な意見なので、詳細なコードレビューの手順はチームでのルールに従ってください
意識してほしい３つのこと
-
そのコードを書いた背景を伝える
- レビューを依頼された側の人はコードの背景を知っているとは限りません
- 背景を知ることで、注意してみるべき点が明確になり、読みやすくなります
-
依頼される側の負担を極力減らすために、URLを活用して情報共有しよう
- 先程も伝えたように、他人の書いたコードの理解は、多くの労力を要します
- レビュー以外の負担を極力減らすことを意識してください
-
レビューしてもらう人への感謝を忘れない
- 多くの場合、善意でコードレビューが行われます
- 貴重な時間と労力を割いてくれていることを忘れないようにしましょう
- 書き方が人によって違うことが多々あると思いますが、最低限敬意を持って接してください
レビューの基本的な流れ
- PullRequestの作成
↓ -
概要の作成
- GitHub上で完結して、背景を理解できるような状態にしてください
- "Add a comment"で概要を作成
↓
-
レビュー依頼
- 見てもらいたい人に、メンションをつけてお願いしましょう
- 見てもらいたいPullRequestのソースのURLも記載しましょう
- 知っておくべき情報があれば、それらのソースのURLも記載しましょう
- 感謝の気持ちを述べましょう（ex.よろしくお願いします）
↓
-
再度依頼
- レビューしてもらった内容を再度修正したら、もう一度依頼を出しましょう
- レビュー依頼の返事がない場合、再度お願いしてみよう
構成例
- 要件および経緯
- 解決する課題
- 手順が書けると尚良いので、番号付き箇条書きを使用して明確にします。
- 動作確認
- 確認する内容はもちろんのこと、スクリーンショットなどがあるとわかりやすいです。
- その他
- 伝えておきたいことを記載します。
最後に
最後まで見ていただきありがとうございました。
実体験をもとに、気をつけておいた方がいいと感じたことをまとめました。
少しでも参考にしていただければ幸いです。
また、ご意見やその他意識すべき重要なことがあれば、是非教えていただきたいです。