小さなプルリクエストの大きな力: レビューを改善し、開発をスピードアップする方法

私はプロとしてコードを書いて5年以上になります。最初の4年間は、プルリクエスト（PR）のサイズを気にしたことはありませんでした。しかし、昨年、何千行もの変更を含む大規模なPRを送信するのではなく、より小さく管理しやすいものに分割するようになりました。この移行によるメリットは計り知れないものがあり、このブログではそのメリットについてお話しします。

GitHubによると、プルリクエストとは次のようになります。

プル リクエストとは、あるブランチから別のブランチに一連の変更をマージする提案です。プル リクエストでは、共同作業者は、変更をメイン コードベースに統合する前に、提案された一連の変更を確認して話し合うことができます。

本質的に、プル リクエストはコラボレーションの方法であり、このコラボレーションを強化するためにあらゆる手段を講じる必要があります。このコラボレーションを改善する効果的な方法の 1 つは、PR を小さく保つことです。

小さな PR と大きな PR を区別する普遍的な定義はありません。自動生成されたコードやテストによって行数が膨らむ可能性があるため、変更された行数だけに頼るのは不十分です。この記事で小さな PR と言っているのは、大きな PR を複数のより小さく論理的に一貫性のある PR に分割することを意味します。それぞれの小さな PR は、独立していて、マージ可能で、デプロイ可能である必要があります。

私は、PR を 2 つに分割し、1 つにすべてのコードを含め、もう 1 つにテストだけを含めるといった人為的な分割を推奨しません。このアプローチでは、以下で説明する利点が得られないからです。

効率的なレビュー:

プログラマーに 10 行のコードをレビューするように頼めば、10 個の問題が見つかるでしょう。500 行レビューするように頼めば、問題ないと言うでしょう。

この引用はユーモラスですが、真実を伝えています。誰もが自分の仕事で忙しく、PR のレビューを依頼するということは、基本的に時間を要求していることになります。PR のレビューでは、レビュー担当者は自分の仕事からコンテキストを切り替える必要があり、レビューにかなりの時間がかかる場合、仕事に戻るのが難しくなり、レビューに対するモチベーションやコミットメントに影響する可能性があります。

レビューに 20 ～ 30 分しかかからない小さな PR は、2 ～ 3 時間かかるものに比べてはるかに簡単に取り組むことができます。さらに、大きな PR は、集中力に限界があるため見落としが起こりやすく、1 つの PR で多数の変更を行き来するのは混乱を招く可能性があります。私の経験では、小さな PR の方がフィードバックが良く、より有意義な設計に関する話し合いにつながる傾向があります。

より速いレビュー:

現時点では、私が亡くなった後も PR がまだ審査中である場合に備えて、遺言に PR を追加することを考えています。

長い PR はレビュー担当者に多大な時間的コミットメントを要求するため、特に影響の大きい機能に関連しない場合は、注目される可能性が低くなります。一方、小さな PR はレビュー担当者の時間をあまり必要とせず、邪魔にならないため、迅速にレビューされます。

このレビューのスピードは、プロジェクトの期限を守るために非常に重要です。上級レビュー担当者が大規模な PR に時間を割くことができなかったためにプロジェクトが遅れるのを見たことがあります (これは小規模な PR でも起こり得ますが、大規模な PR ではリスクが本質的に高くなります)。

小規模なリワーク:

設計変更後に大規模な PR を作り直すことは、建造が終わったばかりの船のデッキチェアの配置を変えて、その後船を沈めてしまうようなものです。

誰もが、PR レビュー中に別の設計の方が保守性が高く将来性があっただろうと誰かが気付き、新しい設計に基づいて PR をやり直すのに追加の時間を費やす必要があるという状況を経験したことがあります (最初に実装された設計に完全に同意していたというわけではありません :p)。これは非常に自然なことです。コードで書かれたものを見ると物事がより明確になり、設計フェーズで見逃していた可能性のある側面に気づき始めることがあるからです。

大規模な PR では、多くの要素をやり直す必要があるため、これは重大な問題になる可能性がありますが、小規模な PR では変更が簡単です。さらに重要なのは、レビュー担当者が問題を早期に特定して最初の PR で対処する可能性が高くなり、後続の PR を新しい設計に基づいて作成できるため、やり直しの可能性が低くなることです。

より良いテスト:

より小さな PR は、PR の作成者にとってもメリットがあります。プロジェクト全体を一度にテストするのではなく、小さな変更を段階的にテストするのに役立ちます。小さな変更をテストすると、システムの各コンポーネントをより徹底的にテストできるため、運用中のバグが少なくなります。これは、自動テストと、作成者または専任の QA エンジニアが実行する手動テストの両方に当てはまります。

さらに、PR が小さいほど、システム全体ではなく限定された範囲に集中できるため、テスト ケースが見落とされる可能性が低くなります。

テストを書く？それは将来の私の問題のように聞こえます。

開発者（私自身も過去にはそうでした）が、機能や製品にすぐに「目に見える」価値が生まれないという理由で、自動化テストの作成をためらうのを見たことがあります。PR を小さくすると、必要なテストの数と作成に費やす時間が制限されるため、こうした摩擦が軽減されます。

より簡単なデバッグ:

どれだけ徹底的にテストしても、本番環境ではバグが発生します。本番環境でのバグはユーザー、ビジネス、またはその両方に直接影響するため、本番環境でバグをデバッグできることは非常に重要です。大規模な PR では変更の表面積も大きくなるため、時間がかかり、問題の根本原因を見つけるのが難しくなります。一方、小規模な PR にはコードが少なくなるため、デバッグがはるかに速くなります。

小さな変更をデバッグするのはタイプミスを見つけるようなものですが、大きな変更をデバッグするのは百科事典を校正するようなものです。

段階的な機能展開:

最後に、小さな PR はプロダクト マネージャーとユーザーにとっても役立ちます。小さな PR を使用すると、システムの一部を継続的に本番環境にプッシュできるため、ユーザーからの早期のフィードバックを得るのに役立ち、必要に応じて早期に軌道修正することができます。

早期のフィードバックを省略することは、何も味見せずに 5 コースの料理を調理するようなものです。つまり、大惨事にならないことを祈るだけです。

小規模な PR の利点は数多くありますが、上記で概説した点は、私が個人的に経験した中で最も影響力のあるものの一部です。小規模な PR のその他の利点や、私が取り上げていない大規模な PR の課題に遭遇したことがある場合は、ぜひご意見をコメントしてください。

この記事が、小規模な PR を取り入れるきっかけになれば幸いです。すでに PR を取り入れている場合は、この記事が、この実践の価値をさらに高めてくれることを願っています。

読んでいただきありがとうございます。次回まで、コーディングを続け、好奇心を持ち続けてください。