PRレビューの学び

初めまして。開発グループでフロントエンドエンジニアをやっている渡邉です。
ユビレジに入社して半年近くが経ちましたのでそこで学んだPR(プルリクエスト)のレビューや、PR周りで学んだことをご紹介させて頂ければと思います。(内容的には初心者向けかも)

今まで

今までチーム開発は何件か経験があったのですがどこのチームもルールも違くて、求めるクオリティや、気遣いなども全く違いました。
そのためあまりPRのレビューをした経験も、レビューをしっかりしてもらった経験も少なくユビレジで学ぶことが多くありました。

PR作成において大切なこと

まずPRを見てもらうには、PRが見やすくないといけないと感じました。
今までは「同じチームだから」とか、「急いでるから」という理由でタイトルはタスク名、本文はタイトルのコピペ、または雑に書いた説明などが多かったと思います。

誰でもわかりやすいPRを作成するように心がける

PRを見る人がプロジェクトに関わるエンジニア以外のメンバーが見てもわかるような内容だと理想的だと思います。

１. タイトルは長すぎずわかりやすく書く
タイトルに細かく情報を詰め込まず、大事な部分をピックアップして設定する。
タイトルを見ただけで何をしたいのかがわかると望ましいと思います。

２. 概要はしっかり書く
概要には情報を細かく書くことを意識する。

「なぜやるのか」、「何をやったのか」、「結果」の最低3つは記載するように意識しています(案件やタスクにもよりますが)。

「なぜやるのか」では、このタスクの背景を記述します。
そうすることでレビュワーや、チームメンバーにどういう意図・問題があり、対応が必要になったのかが伝わりやすくなり、
その対応が必要かどうかの判断にもなったり、追加で対応が必要なことなどの発見にも伝わるかと思います。

「何をやったのか」では、目的に対してどのように対応したのかを記載します。

また、見た目やログなど結果がわかるようなものは対応前と対応後でスクショを撮っておきPRに乗せておくことで更に見やすくなると思います。

3.関連するリンクを追記する

開発をしているとタスク管理にgithubのissueや、jiraでのタスク管理など色々なツールを使うと思います。
出すPRがどのタスクに紐づいているかをわかりやすくするために、タスクの詳細が書いてあるリンクなどを貼ってあげると親切です。
また、コメントなどでも参考にしたリンクや、エビデンスを貼るとレビュワーに伝わりやすくなります。

4.見た目で変更があればbefore, afterの画像も載せる

ビュー側で変更点がある場合などは、対応前と対応後で変化がわかるように画像を載せておくことでエンジニアだけでなくデザイナーさんにも確認してもらうことができたり、別の部分で問題が発見できたりなどメリットもあります。

5.自分でもコメントをする

わかりづらい部分や、混乱を招きそうな部分がある場合はコメントを残しておくことでレビュー時間を短縮することができます。

他メンバーのレビューもしてみる

PRのルールが敷かれていない環境などでは特に色々な人のPRを見てみると勉強になります。
また、PRレビューに慣れていない人にとってもPRレビューは勉強になるので積極的にレビューをした方がいいかと思います。

わからなくてもとりあえずレビュー

わからなくてもレビューをすることで、自分で調べたり、PR作成者に質問したりをすることでコード理解に繋がったり、逆に問題点の発見に繋がったりもするので両者ともにメリットがあると思います。

動作確認も

動作確認もしておかないといけません。
時間がなかったり、余裕がないと動作確認をせずコードを見るだけで終わってしまうこともありますが、レビューだけだと見逃してしまうバグやコード状は問題なさそうだけど画面が真っ白だったなどということもあるので
動作確認はしておきましょう。

まとめ

色々と初歩的なことを書きましたが、自分もレビューの習慣がなかったので色々な大事なことをレビューから学びました。
まだ自分自身も慣れていないところも多いですが、これからも意識して習慣化していきたいと思います。