🐙

そのPull Requestデカすぎませんか

2023/07/19に公開

現代のWebアプリケーションはいかにmainlineにコードをmergeしてリリース頻度を高めるかが重要です。

これをチームで実現するには「いかにmergeされやすいPullRequestを作るか」がポイントになります。

レビュアーの負担を最小化する

コードを書く時間もさることながら、チーム開発では「レビューを待つ時間」がリリース速度に大きく影響します。

リリースサイクルを速くするには、

が重要です。

PRはひとつの目的を達成するものにしましょう。タイトルを付ける時に「◯◯と××をする」みたいになったら見直しのサインです。

基本は「ひとつの目的を達成するための最小の差分を提供する」です。

複数の目的を混ぜるとレビューしづらくなるのもさることながら「◯◯の変更はいいけど××は同意しかねる」みたいになった時に、◯◯の変更もリリースできません。

また、機能追加とバグ修正をひとつのPRに盛り込むのも避けましょう。ある行の変更がどちらを目的としたものなのか分からなくなると、それだけレビュアーの負担になります。

「せっかく見てもらうんだから、この変更も一緒に入れてしまおう」みたいに考えがちですが、これも避けましょう。

例えばPRの目的と直結しないが、同じあるいは近い部分にあるコードの表現を変更するような場面がありがちです。

このような変更はいっしょくたにせず独立したPRを立てましょう。たとえ変更が1行だけになっても構いません。

むしろレビュアーからすると、そういう差分の方が安全であることを確認しやすいので通しやすくなります。

MTGの合間などのちょっとした時間でレビューを済ませられるPRはありがたいものです。

関連issueやdescriptionで変更の意図や考えたことをしっかり伝えるのも重要です。それを確認するためにコメントをやり取りする回数を減らせれば、それだけ早くリリースできます。

といったことを事前にまとめておくことでレビュアーの負担は軽くなります。

私はよく目安として「3年後に他人が見ても分かるように書こう」なんて言ったりします。

基本的には、対象の課題について世界で最も深く理解しているのはそのコードを書いたあなた自身です。自分よりもその課題について知らない人がうまくレビューできない場合はそのPRは妥当ではありません。

なお、3年後の自分は他人みたいなもので、説明をちゃんと書くことは未来のあなたにとっても有益です。後でそのコードを見た時に「なんでこう書いたんだろう」が分かるようになっていると余計なバグが混入しづらくなります。

なんなら3年どころか3ヶ月後には「この時に何を考えていたのかおぼえてないッピ」になります。3年後に見直すことは少なくても、数ヶ月前の変更について調べる場面はよくあります。

といった話を以前社内に書いた時に某氏から「そのPullRequestデカすぎませんか」のタイトルを略して「そプデカを合言葉にしましょう」って言われたけど、さっぱり流行りませんでした。

「そプデカ」わりと気に入ったんだけど、ダメですかね。