開発からコードレビューまでのフロー
概要
コードレビューのフローを説明するための記事です
コードレビューの必要性
開発からコードレビューまでの流れ
- プリレビューを依頼する（必要あれば）
- 事前にプルリクエストを作成する
- Draft Pull Requestで作成する
- プルリクエスト本文に記入しておくこと
- 初回レビューを依頼する
- セルフレビューを実施する
- レビューを依頼する
- 再度レビューを依頼する（必要あれば）
- 番外編
プリレビューを依頼する
大きい案件や未知数な案件の場合には、手戻りを防ぐため事前に相談する
主に以下の内容を確認する
- 技術選定
- 設計方針
事前にプルリクエストを作成する
Draft Pull Requestで作成する
GitHub には Draft Pull Request という機能があります。
これは作業中ということを示しており、人的ミスによる作業中ブランチのマージを防ぐ機能です。
プルリクエストを Draft Pull Request で作成するメリットは以下の通りです。
- コードベースで共有することで進捗が可視化される
- 事前にやることを本文に記述しているため、タスクの整理ができる
- 実装途中のコードに対して議論したり、フィードバックをもらったりできる
プルリクエスト本文に記入しておくこと
プルリクエストに本文がないと、レビュワーは仕様、実装把握からすることになりかなりの負担がかかります。
何のために何をやったのかを明確にし、必要最低限の情報を提供しましょう。
会社によって異なると思いますが、自分は以下のような形式をよく利用しています。
- 課題URLや概要
- 対応内容
- エビデンス（画面イメージ）
- QA内容
初回レビューを依頼する
セルフレビューを実施する
レビュワーはQA担当者ではないため、不要な確認は極力させないように心がける
セルフレビューで実施すること
- 機械によるレビュー（テストや静的解析）が正常に通っているか
- 個人的なデバッグ用のコードが残っていないか
- 不要なログ、コメントは残っていないか
- コンフリクトは解消できているか
レビューを依頼する
- Reviewers にレビュアーを assign
- Assignees に開発者(実装者)自身 assign
- GitHubのコメント、もしくはチャットツールにてレビュー依頼のメンションを飛ばす
番外編
開発時に気をつけておきたいポイント
- 複数機能が盛り込まれたプルリクを作らない
- コミットの粒度を大きくしすぎない
