KINTO Technologies Advent Calendar 2021 - Qiita の16日目の記事です。
TL;DR
- レビューを出す時はレビュアーが見やすいフォーマットにして提出しよう。
- レビューをお願いする前に必ず変更点をGithub上で再確認しよう。
上記の点を意識すればレビュアーは短時間で的確なフィードバックを返しやすくなり、
チーム全体の作業時間が増えるし、自分のスキルアップにも繋がるよねってお話です。
レビューが大変💦
レビューが溜まってなかなかちゃんとした指摘ができない。（そもそも溜めるなという話もありますが...😅）
レビューで何度も同じ様な指摘をしている。
そういった事はチーム開発を行なっているとよく遭遇します。
解消する方法は色々ありますが、今回はプルリクエストのテンプレートを使った方法を発表します。
また、以後プルリクエストは PR と表記していきます。
レビューがなぜ大変なのか色々と原因はありますが、
一つに 何がしたいのか分からず、追うのが大変 という事があるかと思います。
そういった問題を解消するのに役に立つのがPRテンプレートです。
PRテンプレートは何が良いのか？
PRテンプレート自体はご存知の方も多いと思いますが、PRテンプレートを設定しておく事で、PR作成時に入力しないといけない事柄をチームで共有できるので、フォーマットをチームで決めてしまえばレビュアーはPRの内容を素早くキャッチアップできる様になり、PRレビューのコストを下げる事ができます。
弊チームのPRテンプレート
早速ですが、弊チームが現在使っているPRテンプレートがこちらになります。
## WHY
> この PR で実現したいことを記載してください
## WHAT
> この PR でやったことを記載してください
-
-
-
## SCREEN SHOTS
> UIを変更した場合、変更前後のスクリーンショットを貼って下さい
| BEFORE | AFTER |
| --- | --- |
| | |
## MEMO
> レビューをする際に見てほしい点、ローカル環境で試す際の注意点、など
## CHECKs
> レビュー前の最終チェック項目です。落ち着いて確認しましょう☕️
- [ ] Push内容を再確認したか？
- [ ] DangerのLGTMはもらえたか？
- [ ] 着目点、注意点がちゃんと伝えられているか？
- [ ] PRで対応すべき範囲以上の変更が入っていないか？ ([YAGNI原則](https://e-words.jp/w/YAGNI%E5%8E%9F%E5%89%87.html))
> ロジックの追加・変更があった場合はこちらも確認しましょう。
- [ ] テストは足りているか？
- [ ] [SOLID原則](https://qiita.com/baby-degu/items/d058a62f145235a0f007)を満たせているか？
このテンプレートは大きく二つの構成になっていて、
- PRの定義の明確化（レビュアー向け）
- 自分のコードの再確認（レビュイー向け）
という構成になっています
PRの定義の明確化
主にレビュアーのために用意する項目になります。
レビューをする上で何をどこまでレビューするのかを明確にするための項目で、
レビュアーはここを見ればPRの内容をおおよそ理解する事ができます。
WHY
PRで実現したい内容を書きます。
この欄に書いた内容以外の要素はこのPRに入れてはいけません。
WHAT
PRで対応した内容を書きます。
やった作業の明文化をする事で自身の作業を頭の中で整理すると同時に、
レビュアーの人にPRの内容の大まかな概要を理解してもらうための要素。
SCREEN SHOTS
画面に変更がある修正・機能追加を行なった場合にスクリーンショットを添付します。
画面構築をするクライアントサイドならではの項目で、
ローカルでビルドする前にレビュアーがPRの内容を理解しやすくするための要素
MEMO
このPRでの注意事項や着目してほしい事柄、ビルド時の注意点を書きます。
WHYでもWHATでもない事柄をここに書きます。
自分のコードの再確認
自分の確認用の項目になります。
基本的にはチェックボックスを埋めてからレビューをお願いするフローです。
CHECKs
## CHECKs
> レビュー前の最終チェック項目です。落ち着いて確認しましょう☕️
- [ ] Push内容を再確認したか？
- [ ] DangerのLGTMはもらえたか？
- [ ] 着目点、注意点がちゃんと伝えられているか？
- [ ] PRで対応すべき範囲以上の変更が入っていないか？ ([YAGNI原則](https://e-words.jp/w/YAGNI%E5%8E%9F%E5%89%87.html))
> ロジックの追加・変更があった場合はこちらも確認しましょう。
- [ ] テストは足りているか？
- [ ] [SOLID原則](https://qiita.com/baby-degu/items/d058a62f145235a0f007)を満たせているか？
CHECKsの項目はチェックボックス化してレビュイーが自分でチェックを入れる様にしています。
これはCI中やレビューをお願いする前に再度自分の上げた内容を見直してもらいたい。
自分自身で最終確認をしてもらいたいという狙いです。
また、YAGNI原則やSOLID原則を知らないエンジニアにもチェック要素に入れる事で、各原則に沿っているかを確認してもらい、それらの原則への理解を深める目的もあります。
※もちろん、自分のチェック用なので、チェックを入れたからといってレビュアーからその件に対して指摘が入る事はあります。
さいごに
弊チームではこの発表内容以外にも開発に集中できる様な環境づくりに力を入れています。
今後もチームの状態に合わせてどんどんアップデートしていきます。
当社では、トヨタ車のサブスク「KINTO」等の企画/開発を行っており、エンジニアを募集中です。
KINTO Technologies コーポレートサイト