すぐできる！レビュワーへの気遣い💐

はじめに

チーム開発をしていると、レビューは日常的なやりとりです。
でも、「approveもらえるまで時間がかかる」「レビュワーが忙しすぎて負担が大きそう」と感じることも多いです。
コメントで「サイコー！！LGTM!!!!」といったノリでコメントしてくれる環境でありがたいのですが、レビューを受ける側のちょっとした気遣いで、チーム全体のスピードと品質が上がると思うので、今回は、私がPRを出すときに心がけている工夫を紹介します。

背景

今リリース時期が目前で動けばマージしちゃえみたいなところもありつつなんですが、レビューって時間的コストがかかるんですよね。

私も最近自分のことでいっぱいいっぱいでできていないのですが、レビュワーになるとapproveしていいのかちゃんと見ようと思うと結構時間を食うんですよね。
仕様がガチガチに固まってたらその通りになってるかという観点で見たらいいと思うんですが、そんなものはない！！！！

なので想像しつつ、確認しつつみたいなこともありとにかく時間がかかる。。。
レビュワーもレビューだけが仕事じゃないわけです。
いかにどこを見たらいいかを分かりやすくするかこちらで省ける手間は省いておきたいという気持ちがあります。

やってること

動画つける

動いてることを画面動画で証明します。
API接続のタスクやバックエンドと同時のPRの場合とか、私の手元でローカルサーバー立ち上げて当然開発しているのでそのまま動画撮って動いてることをデモで録画します。

テストコードもバックエンドは書きますがフロントは現状ほぼないので動作しているのを見せるのが一番かなと思ってやってます。
本当に動いているかレビュワーが自分の手元で試さなくても分かりますよね。

私は開発している時に動作させているので私の手間と言えば、データの操作ですかね。
Railsなのでrails cをローカルで実行してコンソール立ち上げてデータ操作をしながら、条件分岐があるUIはいろんなパターンを確認できるようにしています。

タスクを達成したことで他の機能が壊れちゃうことが結構あり、テストで落ちてくれたらCIでわかったりしていいですが、そうじゃない場合には実際に動くことをデモできると安心してapproveできると思うのでいいですよね。
フロントのフォームバリデーションいじったら意図した通りにエラーでたところまでは良かったけど、API側のバリデーション修正していないが故に登録ができなくなったとかあります。
そういうのもAPI疎通までいけてることを動画つけとけばレビュワーも確認しなくての動くことがわかって安心です、、！

バックエンドのAPI作成のPRにはフロント側でコールしちゃってコンソールにレスポンス出力したのスクショ貼ったりすることもあります！
疎通までいけてたらもうOKやろ！ってなりますよね！

PRのOverviewを充実させる

何をしたプルリクエストなのかわかるように描きます。
このPRで新たに接続したエンドポイントなどリストアップしたりします。

今だとQAの修正やってて、バグ潰しゲームなのでバグNoも書いたり、タスクだったらタスクの詳細があるリンク貼ってみたり。。。
この辺りはルールになってるチームも多そうです。知らんけど

こんな感じで書いたりしています↓

#Overview
 - projects/[id]/announcements/[slug]/page.tsx  
 - ヘッダーメニューのリファクタリング  
 - お知らせメニューのAPI接続  

## API接続  
 - GET: projects/:project_id/announcements/:id  
 - PATCH: projects/:project_id/announcements/:id/read  
 - GET: projects/:project_id/announcements/unread

コメント書く

今回のPRではやってないけど今後対応する必要のあるタスクが実装中にわかることも多々あります。
//TODOなど、コメントでしないといけないけど今はわかっててやってない、次のPRで実装するなどレビュワーに伝わるようにコメントしておくのも親切かなと思います。

気づいてないのか、気づいててやってないかつやる予定というこちらの意思をしっかりレビュワーにわかるようにしておきます。

// TODO: 実際の売上データをAPIから取得する必要があります

PRに直接自分でコメントして伝えている強強もいて、それもいいなぁって思いました！
ケースバイケースだと思いつつです！

PRを大きくしない

負担と正確性にこれは本当に重要なことです。

チームのルールや、人によりキャパも色々あると思いますが、差分が大きくなると処理の影響範囲が分かりにくくなったり追いきれません。

上記の記事によると差分200−400行だとバグの発見率が上がるというデータがあるそうです。

たまに10000行とかの差分でPRあげてる方もいますが見れません！！無理！！て感じですね。
現実的な対応としてリリース前だからできることですが、「見れないし仕方ないからおかしかったら後で直そう」でマージしてるみたいですが、結構後から私も手を加えることが多いです、、

実装後にデカすぎた〜って分割するのもするのも大変だしだるいので、機能単位でレビュー依頼するようにするといいと思って、細かくするように心がけています。（大きめのフォームのUIやテストコードとかあると結構厳しいですけどね）

おわりに

思いつくのこんな感じです。

自分もレビュワーになって初めてしるレビュワーの大変さもあり、気遣うポイントが多少わかるようになりました。

バグあるコードを書かないことも大事ですが、レビューでバグを見つけるのもレビュー文化を取り入れているチームにとって重要なことなので、レビュワーの負担を少しでも軽くして品質の高いアプリ開発になるよう心がけていきたいものです！！