PRが肥大化する本当の理由

以前、習慣的に巨大なプルリクエスト（PR）を投げてしまう会社で働いていました。一つのPRが数週間も放置されることもありました。それをレビューするには、サブシステム全体を頭に叩き込む必要がありました。バグは積み重なり、締め切りは遅れ、最終的には誰も安全に変更できなくなったため、システムのかなりの部分を再構築せざるを得なくなりました。

エンジニアが悪かったわけではありません。彼らは優秀で、懸命に働いていました。PRが大きくなったのは、退屈な理由によるものでした。

誰も、仕事を細分化する方法を教えていなかったのです。

私たちはよく、巨大なPRを規律の問題として扱います。「もっと小さなPRに分けて」と言います。1,500行の変更と150行の変更の差が、単なる意志の強さの違いであるかのように振る舞います。

それは意志の問題ではありません。大きな仕事を小さく独立した塊に分けることは「スキル」です。ほとんどの人はそれを教わることがありません。「決済機能を追加する」というチケットがあったとき、それは一つの単一のタスクのように感じられます。どこで一つのPRが終わり、どこから次が始まるのかを見極めることこそが、難しい部分なのです。

私もかつては大きなPRを出していました。「完了」とは、問題を一度にすべて解決してレビューに回すことだと思っていました。小さければ小さいほど良いと学ぶのに、何年もかかりました。

小さなPRは、私にとってすべてを変えてくれました：

• レビュアーがより多くのバグを検知できる。人間が論理的に追えるのは200行程度の変更までです。2,000行は無理です。ただ流し読みして承認するだけになってしまいます。
• マージが迅速に行われる。PRがキューに溜まり続けることがなくなります。
• 圧倒される感覚がなくなった。一度に一つの要素に集中できるようになりました。
• プランニング能力が向上した。仕事を細分化するには、その仕事の全体像を理解していなければなりません。

私はシステムをレゴブロックのように捉えるようになりました。それらはカチッとはめ込める小さなパーツです。ブロックの存在が見えてくると、仕事を切り分けることが自然に感じられるようになります。

現在のチームは小さなPRを出しています。その結果は明らかです：

• 平均マージ時間は1.5日です。
• 変更内容が読みやすいため、バグを迅速に見つけて修正できます。
• デリバリーのタイミングが安定しています。

仕事を細分化することは、コーチングすべきスキルです。ルールだけで巨大なPRを解決することはできません。ブロックの捉え方を教えることで、解決できるのです。

AIの登場により、このスキルはさらに不可欠なものとなっています。

かつて、2,000行のコードを書くには多大な労力が必要でした。その摩擦（ハードル）があったからこそ、PRは小さく保たれていました。AIはその摩擦を取り除いてしまいました。プロンプト一つで、膨大な変更を生成できてしまいます。

労力が消えたわけではありません。それはレビュアーへと移動しただけです。作成者は何の負担も負いませんが、レビュアーがその代償をすべて支払うことになるのです。

もしコードのサイズが著者の作業量を表さなくなったのであれば、サイズからリスクを判断することはほとんどできません。どの部分に最も細心の注意を払うべきかを、自ら見極める必要があります。

チームに「レンガ」を見ることを教えましょう。それはエンジニアリングにおいて、最もレバレッジの効く習慣です。

あなたのチームでは、どのPRに深いレビューが必要で、どのPRを素早く承認できるかをどのように判断していますか？

出典: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3

オプションの学習コミュニティ: https://t.me/GyaanSetuAi