最速でマージされるPRを作りたい!

はじめに

こんにちは、エンジニアを目指す大学生Tetsuです。今回はチーム開発で大事なプルリクエストについて、僕が考える最速でマージされるPRについてを語りたいと思います。

こんな人に読んでほしい

• これからチーム開発に挑戦する人
• 中々自分のプルリクエストがマージされず悩んでいる人
• 初学者

言及しないこと

• プルリクエストとは何か

記事を書くに至った背景

数ヶ月前に２社目のインターン先に来てからレビュワーを任されるようになりました。
そこで1社目で教わったPRの作り方の大事さに気付かされたので、
チーム開発初学者に『良いPRやレビュワーの負担を減らすPRについて考えて欲しい』と思いました。
そこで一旦レビュワーの視点を知った上でPRの作成について考えようと思います。

意識していること

はじめに僕がPRを作るときに意識していることに３つについてお話しします。

1. レビュワーは自分の作業を全然知らない

レビュワーと担当者には前提知識に圧倒的な差があります。当然ですよね。
レビュワーはそのブランチで何をしているか詳しく知りませんし、担当者は自分でコードを書いたので、一番よく知っているわけです。しかし、この理解度の差を意識するのは難しいことです。

しかし、意識していれば「この部分は伝わりづらいので、備考やコメントを追加しよう」と気づくことができます。

2. レビューをするのは大変

これはレビューをして初めて実感したことです。レビュワーはただコードをみているのだけではありません。レビュワーの工程を確認しましょう。

1. PRを確認して、まずは頭を切り替える
2. プルリクエストを見て何をしたいのか、どうやっているかを理解する
3. コードにミスがないか、バグがないかを確認する
4. もしあれば修正箇所や理由を一つ一つコメントする
5. 修正箇所があれば上記を繰り返す

これを見ればレビューの認知的な負荷の大きさが分かると思います。
この間レビュワーは自分のタスクを進められない訳ですから、レビューの負荷や時間を減らすことは重要なことです。

3. プルリクエストはコミュ力が命

プルリクエストはコードを読んでいないレビュワーに『僕はこの部分をこうやって実装したんだ』と伝えるものです。担当者はレビュワーのことを想定して自分の実装の意図が伝わるプルリクエストを作るべきだと思います。レビュワーの期待している機能を漏れなく実装することも大事です。

ここが上手くいかないと、何度も修正依頼が来て時間が掛かってしまいます。

よくあるミス

次に初心者の僕がよくやってしまったミスと対策について紹介します。

1. タイポ

これはとても気付きづらい部分ですが、とても重要です。タイポが目立つとレビューするときに余計に気を配る必要が出てきます。見慣れない単語やライブラリ名には気をつけましょう。SpellCheckerも便利です。

2. コンフリクト

コンフリクトで修正を出されるのは、勿体無いです。PR作成前だけでなく新しいブランチがマージされた時も気をつけましょう。定期的にdevをマージすることを忘れずに。

3. ファイル数が多い

ファイル数に応じてレビューが大変になります。レビューするべきファイル数は最大10個くらいが目安だと思います。ファイル数がどうしても増えそうな時はfeatureに加えてtopicブランチを切るのも良いですね。

4. 他のブランチの作業内容が混ざる

これは気をつけるべきですミスです。関係のない差分があるとレビュワーが混乱しますし、余計に頭を使ってしまいます。現在作業しているブランチには気をつけましょう。

理想的なPR

上記を踏まえて理想的なPRとは

1. ケアレスミスが無い

ケアレスミスが無いと余計に修正依頼を出さなくて済みますし、重要な部分をレビューするのに専念できます。

2. ファイル数が適切

ファイル数が適切だと『このブランチで何をしているか』を把握しやすいのでレビューが圧倒的にしやすくなります。

3. 余計な差分がない

余計な差分があると、必要なコードと不必要なコードの仕分けに頭を使ってしまいます。

4. 初めて見る人でも理解しやすい

ポイントは『１週間後の自分でも理解できるか』
以下の順番で工夫すると良いと思います。

1. 変数名をわかりやすくする、関数を適切に使って処理の流れをわかりやすくする
2. 小まめにコミットし、コミットメッセージを具体的に書く
3. どうしても複雑な部分などファイルの差分にコメントを残す
4. 前提や伝わらないことは備考欄に書く

理想的なPRを作成できるようになれば、PRが最速でマージされて担当者もレビュワーも別のタスクを進められます。これはチーム全体の開発スピードを上げることに繋がります。

最後に

最後まで読んでいただきありがとうございます。自分自身まだまだチーム開発に慣れていない部分や足りない知識は沢山あると思いますので、間違い等あればご指摘いただけると助かります。