はじめに
チームで開発する際にはGitHubのプルリクエスト(以下PR)機能を使って「ソースコードレビュー」をする機会が多いと思います。
しかし、PRを作成をする人により「記載内容」がバラバラであるため、レビューがしづらいなと感じることはありませんか？
そこで今回は「PRテンプレート」を使ってこの問題を簡単に解決しよう！という内容です。
※後から名称だけ登場しますが、私は開発に以下ツールを使用しています。
- チャットツール：Slack
- チケット管理ツール：Backlog
- Webデザインツール：Figma
こんな人に読んでほしい
- チーム開発している
- GitHubを使っている
- レビューをすることがある
- レビュー依頼をすることがある
目次
- レビューがしづらいと感じる原因
- レビューがつらいPR事例
- レビュアーのメリット
- レビューイのメリット
- テンプレート事例
- テンプレートの作り方
- GitHubへの反映方法
- まとめ
レビューがしづらいと感じる原因
そもそもPRの「記載内容」がバラバラであると、なぜ「レビューがしづらい」と感じるのか。
私はざっくり以下が原因であると感じます。
※PR運用方法のベストプラクティスについてはここでは言及しません。
- この実装の目的(何がしたいのか)が読み取りづらい
- いつまでにマージしたいのかわからない
- 時にはチャットツールやチケット管理ツールなどから背景を読み取る必要がある
レビューがつらいPR事例
私がつらいなと感じるPR事例を紹介します。
少し極端ですが。
パターンA(情報が少ない)
# 概要
- 機能Aの追加
レビューお願いします！
機能Aの仕様は？デザインは？
ソースコードからすべてを読み取るのはつらい。
パターンB(内容が冗長)
前回のMTGにてクライアントの〇〇さんから
フォーム中項目Bの下へ項目Aを追加したいという要望があり、
フロントエンドでは項目のタイトルとプルダウン表示、
選択がない場合にはバリデーションメッセージの表示、
また単体テストも実装しました。
レイアウトについてはFigmaをご覧ください。
XX月XX日には結合テストのため
△△ブランチへマージする必要があり、
お忙しいところ恐縮ですが早めにレビューお願いします！
たくさん書いてくれるのでなんとか読み取れますが、欲しい情報をピンポイントで取得しづらい。
上記のようなPRを見るのは(特に忙しい時には)つらいと感じますよね。
この「つらい」を解決するために、簡潔にPRに情報を集約させることでレビューの負担を減らそうと考えました。
レビュアーのメリット
- 実装の目的が読み取れる
- 情報取得のためのレビューイとのコミュニケーションを減らすことができる
レビューイのメリット
- 「何を記載すれば良いか」を考える時間を短縮できる
- 「マージ期限」など付加情報をレビュアーに伝えられる
テンプレート事例
実際にテンプレートを作成する前に、私がプロジェクトで運用しているテンプレートを紹介します。
内容はプロジェクトやチームに合わせてカスタマイズしてください。
## 概要
- フォームへ項目Aを追加
## 背景/経緯
- クライアントより項目Aを追加したいと要望があったため
## 対応内容
- フォームへの項目追加
- バリデーションメッセージ表示
- フロントエンドテスト実装
## マージ期日
XX月XX日までにマージしたく、レビューお願いします
## バックログチケット
[チケットタイトル](URL)
## エビデンス
- フォーム内の項目Aレイアウト
（ここに画像をFigmaのURLや画像を添付する）
## 備考
- 何かあればここに記載する
テンプレートの作り方
それでは実際にテンプレートを作っていきましょう。
やることは次の2つだけです。
-
.githubフォルダ作成 -
pull_request_template.md作成
.githubフォルダ作成
プロジェクトのルートで次のコマンド使ってフォルダを作成してください。
mkdir .github
pull_request_template.md作成
作成したフォルダ以下にファイルを作成します。
touch .github/pull_request_template.md
そして記載したい内容をマークダウンで記載してください。
GitHubへの反映方法
テンプレートを作成したブランチをmainブランチへマージすれば、次回PR作成時にdescriptionへ反映されます。
まとめ
今回はPRテンプレートの作成方法を紹介しました。
テンプレートを使うことで、少しでもレビューが楽になれば幸いです。
ここまで読んでくださりありがとうございました！