株式会社JMDCでモバイルアプリエンジニアをやっている @mrtry です。入社した当初、モバイルアプリチームのエンジニアは私一人だったのですが、現在では4人になりました。最近はPull Requestのレビュー数も爆増しており、とても疲弊しがちです(嬉しい悲鳴)。たいへんポイントを減らすために、最近Pull Requestまわりの運用を整えたので、今日はその話をしたいと思います。
Pull Requestのレビューがたいへん
現在、モバイルアプリチームでは、3つのプロダクトの開発をしています。各プロダクトに1名ずつassignされており、リードエンジニアとして私が一通りレビューをしている状況です。そんなこともあり「Pull Requestのレビューがたいへん」というのが最近の悩みでした。
Pull Requestのレビューをするとき、私は以下のような観点でレビューしています。
- 機能仕様レベルで、求めるユースケースと解決となる機能実装の対応が妥当か
- 技術仕様レベルで、機能実装の実現方針が妥当か
- コードレベルで、変更内容が妥当か
- 変更されたコード全体を結合して見たとき、機能要件を満たしているか
- 変更内容をcommit単位で見たとき、各commit内容が適切な意味を成しているか
- 変更内容に依って出る影響範囲が考慮されているか
上記の観点でレビューする際に、以下のような指摘をすることがありました。
- 機能仕様レベル
- 動作確認方法がわからない
- ひとつのPull Requestで扱うcontextが大きすぎる
- ひとつのPull Requestで扱うcontextが複数ある
- 技術仕様レベル
- 実装方針が適切ではない場合、全体的に作り直しになることがある
- コードレベル
- ひとつのPull Requestでコードの差分が大きい
- commit messageがcommit内容の説明になっていない
- 各commitの粒度が大きく、commit messageの1文で説明が足りない
- 改修による影響範囲の想定がわからない
これらの指摘内容が含まれているPull Requestのレビューをすると、改修の妥当性の判断が難しかったり、前提理解のために時間がかかったりすることが発生し、レビューの効率や質が悪くなってしまいます。
なるべく効率的に、また効果的なPull Requestのレビューをできるようにするために、取り組んだことを紹介します。
やったこと
Pull Requestのテンプレートをつくった
GitHubにPull Requestのテンプレートをつくりました。必要な情報を予めテンプレートとして列挙しておくことで、Reviewer視点ではコードを読む前に必要な情報をインプットしやすくなり、Reviewee視点では自身の作業内容についてセルフレビューすることができます。
これだけ見ると各項目に何を記入するのかわかりにくいので、テンプレートにコメントを入れてあります。また、チームメンバーに日本語が母国語でない方もいるので、英語も併記してあります (ただ、翻訳を通して雑にいれたものなので、英文的な正しさが微妙かもしれません)。
実際に作成したテンプレートは以下になります。こちらのPull Requestテンプレートをベースにしています。
「良いcommit」の知見を共有した
commitについても、人によって粒度がまばらで統一感を取りにくいです。実例を示しつつ、以下のような「良いコミットとは何か」という内容が説明されている文献をチームにシェアして、共通認識を取るようにしました。
得られた効能
結果として、当初のたいへんポイントは解消されました🥳
Reviewer視点では、以下の効能がありました
- レビューする内容が明確になった
- 実装背景等が記入されるようになり、変更の妥当性が判断しやすくなった
- コード差分が小さくなり認知不可が下がったことで、細やかなところまで気を行き届かせやすくなった
- レビューにかかる時間が長くても30分程度になった
- 他のプロダクト開発メンバーが見ても、変更内容が理解できるようになった
Reviewee視点では、以下の効能がありました
- レビューして欲しい内容が明確になった
- Change Requestがあったとしても、手戻りが少なくなり、精神的ダメージが少なくなった
- テンプレートを埋める過程で、セルフレビューをすることができるようになった
おわりに
高品質なプロダクト開発を継続的に続けるために、様々な事柄に対しての構造化に取り組んでいます。今回はPull Requestの話ですが、設計やCI/CDなど、他にも色々取り組んでいます。このような取り組みに興味を持たれた方がいらっしゃいましたら、ぜひカジュアル面談でお話ししましょう!🥳