Webエンジニアの方々の多くは日常業務でチーム開発をしていると思います。
チーム開発では大体の場合、タスク担当者がPR(プルリクエスト)を発行し、1人以上のレビュワーがそのPRのコードをチェックし指摘やアドバイスを行います。
レビュワー(レビューする側)になるとチームの規模によっては1日に複数のPRをレビューする必要があり、下手すると「レビューしていたら1日終わった…」なんてことも。
レビュワーはレビュー専門のポジションではなく他のタスクもあるので、レビュイー(レビューされる側)はなるべくレビュワーがレビューしやすいPRを作成し、レビュワーの時間を奪いすぎないことが重要です。
重要ですし、こういう取り組み自体評価されるべきものだと思っています。
前置きが長くなりましたが、Webエンジニアとしてレビュイー、レビュワーどちらも経験した僕が
- PRを作成する時に含めている情報
- レビュワーになって感じた「この情報欲しい!」と思ったこと
- 知人から聞いて「それ良い!」と思ったこと
をご紹介します。
以前ツイートしたのでこれについて1つずつ説明を入れていきます。
この記事の読者の今後の開発業務の参考になることがあれば嬉しいです。
共通
まずはフロントエンド開発、バックエンド開発に共通して言えることから書いていきます。
チケット(タスク)の情報
どのチケット(タスク)のPRなのかがレビュワーが助かると思います。
チケットの内容はJIRAやBacklog等のタスク管理ツール上に記載することが多いかと思うので、URLをPRに貼っておくと、レビュワーが「このタスクってどんな内容だったっけ?タスク管理ツールから探すか…」という手間が省けます。
実装内容
そのPRでどういうことを実装したのか、そこまで具体的ではなくても良いかと思いますが書いておくと良いです。
何を実装したかを書いておくことで、レビュワーは明らかに実装漏れしている箇所がないかを素早く判断することができます。
あくまで例ですが、以下のように箇条書きで書くのが良いと思います。
- ◯◯APIの実装
- ◯◯テーブルの追加
- テーブル構造はテーブル定義書とおり
- ◯◯APIのテストコード実装
実装コードの補足説明
実装したコードの中でどのような考えた方でそのコードを書いたのかを補足説明した方がレビュワーがレビューしやすいと思うことは積極的に記載することが望ましいです。
次に記載する「特にチェックして欲しい箇所」とカブるところもありますが、実装方針を詳しく説明しておきたいところを書くとコードレビューの手助けになります。
特にチェックして欲しい箇所
ここは個人的には盛り込むのがオススメの内容です。
僕は自分が実装したコードで「ここちゃんとチェックしてもらった方が良さそうだな…」と思う箇所は必ず
- コードの抜粋
- こう書いた理由
- 迷った点、悩んだ点、自信がない点
を書いています。
レビュワーは色々なタスクを担当して忙しい場合もあるので、「他のところは問題なく実装できている(と思う)のでここだけは必ずチェックして欲しいです!」という感じの気持ちを伝えることができます。
(実際には全てチェックして欲しいですけどね笑)
テスト結果
テストコードの実行結果(自動でテストを実行する仕組みが導入されている場合は不要かと思います)も盛り込む必要があれば盛り込みましょう。
ここもなかったらレビュワーが「テストコード全部通る状態になっているのかな?」と思う可能性があります。
フロントエンド開発
次はフロントエンド開発に特化した内容です。
フロントエンド開発では2つ紹介するのですが、個人的にはマストかなと思います。(レビュワーだったらめっちゃ助かるので)
画面のスクショ
これはUIの修正がある場合は絶対に入れるべきです。
UIの修正のタスクにおいて実装後かつPRマージ前に修正後のUIを確認する手段はレビュワーがリモートのfeatureブランチをpullする作業が必要です。
その手間が0になるのはレビュワーにとってはとても助かります。
さらに親切に情報を入れるとしたら
- 修正前のUI
- 修正後のUI
両方のスクショをPRに添付するのが良いと思います。
動画
UIの修正の他に、検索・ローディング、フラッシュメッセージ、ダイアログ等、動的に画面が変わる処理を実装した場合はその動画を添えるとレビュワーはありがたいです。
これもUI修正の時と同じく、レビュワーがローカルで確認する作業を無くすことができ負担軽減につながります。
バックエンド開発
最後はバックエンド開発に特化した内容です。
リクエストとレスポンスのJSON
APIを実装した時に
- リクエストに何を渡して
- レスポンスとして何が返ってくるのか
をPRに添えると仕様通りに機能を実装できているかどうかを一目でわかり、コードレビューする時に「この書き方でちゃんと機能しているのか?」という観点が必要なくなりコードの書き方のレビューに集中することができます。
最後に
レビュワーの負担を減らすことにつながる方法についてまとめました。
ここまで記事を書いて思ったことは
を考えてPRを作成することが最も重要だと思いました。
また、PRの説明で使う用のテンプレを使ってそれを使い回すのも良い手だと思います。
僕はClipyというアプリにPRのテンプレを登録して使っています。
今後の開発業務の参考になっていたら幸いです。
コメント