[CSDN 編集者注] PR の長さはどれくらいが最適だと思いますか。この記事の著者は、理想的な長さは 50 行だと考えています。
元のリンク: https://graphite.dev/blog/the-ideal-pr-is-50-lines-long
許可なく再配布しないでください！
文 | GREG FOSTER 翻訳 | Crescent Moon
担当編集者 | Xia Meng
出品 | CSDN（ID：CSDNnews）
ほとんどのプロジェクトは、コードの変更は小さいほど良いということに同意しています。理由は簡単で、プル リクエスト (Pull Request、PR) が小さいほどレビューが容易になり、エラーの可能性が低くなり、デプロイが速くなります。
しかし、PR の理想的な長さはどれくらいでしょうか? PRが小さすぎるという問題はありますか？小さな PR が良い場合、それはどの程度良いのでしょうか?
PR の理想的な長さは 50 行である必要があります
私たちの意見では、PR の理想的な長さは 50 行であるべきです。
50 行のコード変更は、250 行の変更よりも約 40% 速くレビューされ、マージされました。250 行のコード変更と比較して、50 行のコード変更は元に戻される可能性が 15% 低く、変更 1 行あたりのレビュー コメントの数が 40% 増加しました。さらに、チームメイトが提出した PR の中央値が 200 行で、あなたの中央値が 50 行の場合、合計コードは 40% 多くなります。
プログラミング速度を確保し、レビュー意見を増やし、失効率を減らし、提出されるコードの総量を増やすには、50 行が最適な選択です。許容範囲としては、PR ごとに 25 ～ 100 行のコードを推奨します。データから、PR が小さいほど、各行のレビュー、マージ、コメントに費やす時間が短縮されることがわかりました。ただし、制限があります。コード変更の行数が 25 行未満の場合、変更が元に戻される可能性が高くなり、配信されるコードの総量も減少します。
以下では、その理由について説明し、この結論を裏付けるデータを見ていきます。
サンプルセット
この記事のすべてのデータベースのステートメントでは、Graphite を通じて同期されたプライベートおよびパブリック PR およびリポジトリを使用します。理想的な PR サイズを把握するために、次の 4 つの主要な指標とそれらの PR サイズとの関係を調べました。
コードをレビューしてマージします。
変更を元に戻す確率。
コメントの平均数。
年間のコード変更の合計。
予防
収集したデータから結論を導き出す際に留意すべき点がいくつかあります。
PR のサイズに従って分類する場合、線形サイズ分類の粒度が細かすぎるため、分類サイズは均一でも線形でもありません。また、指数関数的サイズの分類では多くの詳細が失われます。
個々のリファクタリングによってデータ全体が歪められるのを避けるために、平均ではなく PR サイズの中央値を使用しました。
変更が取り消されたかどうかを判断する基準は、PR のタイトルに「Revert」という単語が含まれていることです。これは、git revert がこの単語をタイトルの前に自動的に追加するためです。
多くの組織がトランクベースの開発スタイルを使用しているため (小規模な PR が奨励されているため)、Graphite ユーザーは一般に小規模な PR を作成する傾向があることがわかりました。
コードをレビューする時期とコードをマージする時期
次に、データをさらに詳しく見てみましょう。まず、コードをレビューする時間とコードをマージする時間を調べます。コード量が最も少ない PR は、2 ～ 5,000 行のコードを含む PR よりも 5 倍近く高速であることがわかります。これは理にかなっています。なぜなら、PR が小さいほどコードが少なくなり、コードが少ないほど、変更が壊れたり、多くの詳細が含まれる可能性が低くなり、レビューが速くなることを意味します。
ただし、変更されたコードの量が 5k 行を超えると、PR は再び速度を上げ始めます。これには、安全なリファクタリング、追加されたパッケージや生成されたコードなど、さまざまな理由があると思います。おそらくコードが大きすぎて、作成者もレビュー担当者もすべてのコード変更を詳細に読むことができないためです。
ここでは、コード 1 行あたりの時間よりも PR あたりの時間に重点を置いていることに注意してください。PR をできるだけ早くコード ベースにマージする方法についてのみ説明すると、PR のサイズは小さいほど良いことがデータからわかります。ただし、コードをできるだけ早く出荷することが目標の場合、2000 行の PR は 1 時間あたり約 12 行でマージでき、10 行の PR は 1 時間あたり約 0.25 ～ 2 行でマージできます。
PR サイズごとの失効率
失効率も同じ結論を反映しています。つまり、PR が小さいほど、リビジョンが取り消される頻度が低くなります。離脱率が最も低い PR: コード変更の量は 25 ～ 50 行です。ただし、一部のエッジケースは依然として非常に興味深い特性を示します。コードが 10 行未満の PR は、コードが 10 ～ 100 行の PR よりも撤回率が大幅に高くなります。これは、10 行未満の PR はほとんどが危険な設定変更であるためだと推測していますが、変更された行数を正規化することでその仮定が反証されるはずです。
PR のサイズが 10k 行を超えると、「セキュリティ」がわずかに向上するようです。これは大規模な PR に一般的にリファクタリングが含まれており、機能の変更が少なく、したがって中断が少ないのではないかと思います。あるいは、10,000 行を超えると、反発やマージの競合により、エンジニアがそのような PR を撤回したがらなくなる可能性があるからです。
PR サイズごとの平均コメント数
最適化の目的 (マージ速度の向上、または詳細なコード レビュー) に応じて、PR を分割するかどうかを選択できます。より多くのフィードバックを得たい場合は、コード変更のサイズを 1 ～ 2,000 行のコードに制御することを選択できます。できるだけ早くマージしたい場合は、コードの変更を 10 行以内に抑えてください。この情報は、変更をできるだけ早く配信することに関心があり、変更について議論することにあまり時間を費やしたくない場合に役立ちます。
また、PR の規模が大きくなるにつれて、平均レビュー数が徐々に減少し始めることもわかります。レビュー担当者はどのくらいのコードを読みたいと思っているのでしょうか? これには実際には制限があります。「読み取り」PR が「参照」PR になるポイントは 2k 行であるべきだと思います。
長期的にコードに対するエンゲージメントとフィードバックの量を最大化することに関心がある場合、PR は可能な限り小さくする必要があります。理解を容易にするために、コードの 39 行ごとにコメントを追加する必要があります。逆に、フィードバックを書くのが嫌いな場合は、PR を 10,000 行以上にすることで、6,000 行のコード変更ごとにいくつかの散発的なコメントしか受け取らないようにすることができます。これを自分で体験してください。結局のところ、究極のフィードバックを送信するプログラマはいないからです。 PR の目的はフィードバックやコメントを得ることです。
配信されたコードの総量
小さな PR を書くことが、配信されるコードの総量に影響を与えるかどうか疑問に思うかもしれません。誰もがスピードを求めますが、場合によっては高い出力が必要になります。20 行未満の PR を一貫して作成することは、プログラミングの速度に大きな影響を与えますが、興味深いことに、100 行を超える PR を作成することもプログラミングの速度に大きな影響を与えます。最大のスループットを確保するために、PR サイズの中央値は 40 ～ 80 行です。配信されるコードの量 = サイズの変更 * 速度の変更 によるものだと思います。変更が小さすぎる場合、マージの速度を上げても出力は最大化されません。逆に、変更が大きすぎると、コードのレビューとコードのマージのサイクルが遅くなります。
要約する
開発者は PR 中央値: 50 を目指す必要があります。もちろん、いくつかのエッジケースも考慮し、実際のニーズに応じてコード変更のサイズを調整する必要がありますが、同時に PR のサイズの調整がレビューの品質、速度、レビューに大きな影響を与えることを理解する必要があります。変更を元に戻す可能性。