はじめに
こんにちは！毎日寒いですね！
昨日に引き続き、みてねチームでCREとして働いているささたつからお届けします。
さて、エンジニアは日々、PRをレビューしたり、レビューしてもらったりしますよね？
この記事では、僕がPRを作るときに気を付けていることを2つ、紹介します。
ひとつのことだけをやる
まずはこれ。1つのPRに複数の変更を混ぜない、です。
1つのPRには「ひとつのこと」だけを含めるべきです。あれもこれも、、と複数の変更を混ぜてしまうと、こんな問題が発生します。
- レビュアーの負担が増加: 差分が複雑になり、レビュアーが理解するのに時間がかかる。
- レビューの質が低下: 大きなPRは見落としが発生しやすくなる。
- トラブルシューティングが困難: バグが発生した場合、原因を特定するのに手間がかかる。
そもそも、なぜ我々は複数の変更を混ぜたくなるのでしょうか。
まとめて出した方が楽だから？複数の変更を複数のPRに分けると、PRを作る手間が増えるから？
たしかに、PRを作る手間は少し増えるかもしれないです。でも、PRの目的が明確になって、レビュアーの負担を減らせるという大きなメリットがあります。
機能追加でも、改修でも、コードを書いてPRを作るだけではそれはまだ仕掛かり中です。レビューが通って、リリースして、はじめてユーザに届きます。ユーザにより早く、より安全に、価値を届けるために、できるだけレビュアーの負担を減らすように工夫するのは大切なことだと考えています。
あと、いろんな変更が入った大きなPRになると、見落としのリスクも高くなりますよね！
お気に入りのツイートです ☺️
小さなPRを積み重ねる
もう1つはこれ。ひとつの巨大なPRを作るのではなく、変更内容はできるだけ小さな単位に分けて、PRを積み重ねていくのが良いと考えています。
- レビュー速度の向上: 小さなPRは変更量が少ないため、レビューが迅速に行える。
- 変更リスクの最小化: 小さなPRは影響範囲が限定的で、問題が発生しても迅速に対処できる。
- 開発のモメンタム維持: 小さなPRを頻繁にマージすることで、開発の進捗を実感しやすくなる。
レビューを依頼されてリンクを開いたときに、大きなPRだったりすると「ちょっと今忙しいからあとで見るか……」みたいな気持ちになることってないでしょうか。そして忘れてしまったり。僕はあります！
小さなPRにすると、レビュアーの負担を減らせて、すぐに見てもらえるようになります。
また、「ここまではレビュー済み（or リリース済み）」という安心感も得られます。これは開発の不確実性を少しずつ減らしていくという意味でも、結構大事なことだと感じています。
具体的には、リファクタを先にやって、そのあとに改修を入れるとか。
大きな変更をいくつかのステップに分けて（モデル → フォーム → コントローラーなど）、小さくPR
を作って小さくリリースしていく、というのもよくやります。
と言っても、最初からすべてを見通すことは難しいことも多いので、最初に全体をある程度作ってみて、そこからPRを小出しにしていくことが多いです。
ただ、進め方がわかっていないとレビュアーもレビューしにくいと思うので、「こうやって進めていきます」を事前に共有したり、PRに書いたりして、進めていきます。
PRに記載するときのイメージ
おわりに
今回は、PRを作るときに気を付けている2つのこととして、「ひとつのことだけをやる」と「小さなPRを積み重ねる」を紹介しました。どちらも、PRを小さくしよう、レビュアーがレビューしやすいようにしよう、という考えに基づいています。
この記事が、みなさんの日々の開発に役立つヒントとなれば嬉しいです！
Discussion