<p>この記事は、<a href="https://qiita.com/advent-calendar/2022/lancers" target="_blank" rel="nofollow noopener noreferrer">Lancers（ランサーズ） Advent Calendar 2022</a> の2日目の記事です。</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__074b423a994c4" src="https://embed.zenn.studio/card#zenn-embedded__074b423a994c4" data-content="https%3A%2F%2Fqiita.com%2Fadvent-calendar%2F2022%2Flancers" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://qiita.com/advent-calendar/2022/lancers" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://qiita.com/advent-calendar/2022/lancers</a></p>
<h2 id="%E3%83%A2%E3%83%81%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3">
<a class="header-anchor-link" href="#%E3%83%A2%E3%83%81%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3" aria-hidden="true"></a> モチベーション</h2>
<p>一般的にPull Requestはサイズが小さいほうが良いとされていますが、理想的なPull Requestのサイズは具体的に何行なのでしょうか？<br>
また、なぜPull Requestのサイズは小さい方が望ましいのでしょうか？</p>
<p>本稿ではPull Requestの理想的なサイズとその理由について、リサーチした内容をまとめます。<sup class="footnote-ref"><a href="#fn-79e8-1" id="fnref-79e8-1">[1]</a></sup></p>
<h2 id="%E6%9C%AC%E7%A8%BF%E3%81%A7%E5%8F%96%E3%82%8A%E6%89%B1%E3%81%86%E8%A6%B3%E7%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6">
<a class="header-anchor-link" href="#%E6%9C%AC%E7%A8%BF%E3%81%A7%E5%8F%96%E3%82%8A%E6%89%B1%E3%81%86%E8%A6%B3%E7%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> 本稿で取り扱う観点について</h2>
<p>Pull Requestのサイズを考察するにあたり、主に注目される観点は以下の2つがあります。</p>
<ul>
<li>リーン思考に基づいたフロー効率の観点</li>
<li>コードレビューに関する観点</li>
</ul>
<p>本稿では、理想的なPull Requestのサイズについて具体的な数字を示したいというモチベーションから、<code>コードレビューに関する観点</code>について取り扱うことにします<sup class="footnote-ref"><a href="#fn-79e8-2" id="fnref-79e8-2">[2]</a></sup>。</p>
<h2 id="tl%3Bdr">
<a class="header-anchor-link" href="#tl%3Bdr" aria-hidden="true"></a> tl;dr</h2>
<ul>
<li>1時間以内に完了するPull Requestのレビューは不具合の発見率が高い</li>
<li>200から400行程度のPull Requestは1時間以内にレビューが完了する可能性が高い</li>
<li>理想的なPull Requestのサイズは200から400行である</li>
</ul>
<h2 id="%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%82%92%E3%81%99%E3%82%8B%E7%90%86%E7%94%B1">
<a class="header-anchor-link" href="#%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%82%92%E3%81%99%E3%82%8B%E7%90%86%E7%94%B1" aria-hidden="true"></a> コードレビューをする理由</h2>
<p>Pull Requestを用いた開発プロセスでは、殆どの場合コードレビューを行っているかと思います。<br>
では、そもそも何故コードレビューを行うのでしょうか？</p>
<p><a href="https://jglobal.jst.go.jp/detail?JGLOBAL_ID=201002065206894692" target="_blank" rel="nofollow noopener noreferrer">IBMの調査</a>によると、コードの欠陥(外部品質、内部品質両方)を発見する最も費用対効果の高い方法がコードレビューだそうです。<sup class="footnote-ref"><a href="#fn-79e8-3" id="fnref-79e8-3">[3]</a></sup></p>
<h3 id="%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E6%99%82%E3%81%AB%E6%A4%9C%E5%87%BA%E3%81%A7%E3%81%8D%E3%81%9F%E4%B8%8D%E5%85%B7%E5%90%88%E3%81%AE%E4%BF%AE%E6%AD%A3%E3%81%AF%E4%BD%8E%E3%82%B3%E3%82%B9%E3%83%88%E3%81%A7%E3%81%82%E3%82%8B">
<a class="header-anchor-link" href="#%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E6%99%82%E3%81%AB%E6%A4%9C%E5%87%BA%E3%81%A7%E3%81%8D%E3%81%9F%E4%B8%8D%E5%85%B7%E5%90%88%E3%81%AE%E4%BF%AE%E6%AD%A3%E3%81%AF%E4%BD%8E%E3%82%B3%E3%82%B9%E3%83%88%E3%81%A7%E3%81%82%E3%82%8B" aria-hidden="true"></a> レビュー時に検出できた不具合の修正は低コストである</h3>
<p>少々本題とは逸れますが、コードレビューの重要性を示す情報についても合わせて紹介します。</p>
<p>不具合の修正は開発プロセスの早い段階であるほど低コストであるというレポートがあります。</p>
<p><img src="https://res.cloudinary.com/zenn/image/fetch/s--h8uhYv1S--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_1200/https://www.luxoft-training.com/upload/medialibrary/537/fixing_defect.jpg" alt="https://www.luxoft-training.com/upload/medialibrary/537/fixing_defect.jpg" loading="lazy" class="md-img"><br>
<em><a href="https://www.luxoft-training.com/news/7-principles-of-testing-part-2/" target="_blank" rel="nofollow noopener noreferrer">7 Principles of Testing - Part 2</a>より</em></p>
<p>QAエンジニアによるテストプロセスで不具合が検出されるよりも、コードレビュー時に不具合が検出されたほうが修正コストが低い、という考え方ができると思います。</p>
<h2 id="1%E6%99%82%E9%96%93%E4%BB%A5%E4%B8%8A%E3%81%8B%E3%81%8B%E3%82%8B%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AF%E4%BD%8E%E5%93%81%E8%B3%AA">
<a class="header-anchor-link" href="#1%E6%99%82%E9%96%93%E4%BB%A5%E4%B8%8A%E3%81%8B%E3%81%8B%E3%82%8B%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AF%E4%BD%8E%E5%93%81%E8%B3%AA" aria-hidden="true"></a> 1時間以上かかるコードレビューは低品質</h2>
<p>ここまでの内容から、<code>より多くの不具合を検出できるコードレビュー</code>が効果的なコードレビューであると考えられます。</p>
<p><a href="https://www.oreilly.co.jp/books/9784873115115/" target="_blank" rel="nofollow noopener noreferrer">Making Software ―エビデンスが変えるソフトウェア開発</a>という書籍の18章「Modern Code Review」では<code>1時間を超えるコードレビューは品質が低下する</code>ことを示す研究が紹介されています。<sup class="footnote-ref"><a href="#fn-79e8-4" id="fnref-79e8-4">[4]</a></sup></p>
<p>加えて、シスコシステムズで行われた調査によると、<code>1時間に500LOC(Line of Code)を超える速度でレビューを行うと、不具合の検出効率が低下する</code>ことが分かったと報告しています。</p>
<p><img src="https://res.cloudinary.com/zenn/image/fetch/s--PHrmLUjF--/https://static1.smartbear.co/smartbear/media/images/product/collaborator/code-review-best-practices-figure-02.gif" alt="https://static1.smartbear.co/smartbear/media/images/product/collaborator/code-review-best-practices-figure-02.gif" loading="lazy" class="md-img"><br>
<em><a href="https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/#:~:text=2.-,Take%20your%20time.%20Inspection%20rates%20should%20under%20500%20LOC%20per%20hour,-It%20can%20be" target="_blank" rel="nofollow noopener noreferrer">Best Practices for Code Review #Take your time. Inspection rates should under 500 LOC per hour | SmartBear</a>より</em></p>
<p>以上から、1時間以上かかるコードレビューは不具合の検出という観点において、品質が低下すると言えます。</p>
<h2 id="%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%8C1%E6%99%82%E9%96%93%E4%BB%A5%E5%86%85%E3%81%AB%E5%AE%8C%E4%BA%86%E3%81%99%E3%82%8Bpull-request%E3%81%AE%E3%82%B5%E3%82%A4%E3%82%BA%E3%81%AF200%E3%81%8B%E3%82%89400%E8%A1%8C">
<a class="header-anchor-link" href="#%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%8C1%E6%99%82%E9%96%93%E4%BB%A5%E5%86%85%E3%81%AB%E5%AE%8C%E4%BA%86%E3%81%99%E3%82%8Bpull-request%E3%81%AE%E3%82%B5%E3%82%A4%E3%82%BA%E3%81%AF200%E3%81%8B%E3%82%89400%E8%A1%8C" aria-hidden="true"></a> コードレビューが1時間以内に完了するPull Requestのサイズは200から400行</h2>
<p>では、コードレビューが1時間以内に完了するPull Requestのサイズは具体的に何行なのでしょうか？</p>
<p>ある企業でコードレビューにかかる時間と行数を調査したところ、200行程度のPRであれば、90%の確立で1時間以内に完了することが分かったと報告しています。</p>
<p><img src="https://res.cloudinary.com/zenn/image/fetch/s--qQC1-vpL--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_1200/https://smallbusinessprogramming.com/wp-content/uploads/2017/10/pull_request_review_time.png" alt="https://smallbusinessprogramming.com/wp-content/uploads/2017/10/pull_request_review_time.png" loading="lazy" class="md-img"><br>
<em><a href="https://smallbusinessprogramming.com/optimal-pull-request-size/#fnref-352-3:~:text=How%20much%20code%20can%20my%20team%20review%20in%20an%20hour%3F" target="_blank" rel="nofollow noopener noreferrer">Optimal pull request size #How much code can my team review in an hour? - Small Business Programming</a>より</em></p>
<p>同様に、シスコシステムズで行われた調査から<code>400行を超える行数の変更を一度にレビューしようとすると欠陥を見つける検知能力が下がる</code>という報告があります。</p>
<p><img src="https://res.cloudinary.com/zenn/image/fetch/s--G3UHXo2H--/https://static1.smartbear.co/smartbear/media/images/product/collaborator/code-review-best-practices-figure-01.gif" alt="https://static1.smartbear.co/smartbear/media/images/product/collaborator/code-review-best-practices-figure-01.gif" loading="lazy" class="md-img"><br>
<em><a href="https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/#:~:text=1.-,Review%20fewer%20than%20400%20lines%20of%20code%20at%20a%20time,-A%20SmartBear%20study" target="_blank" rel="nofollow noopener noreferrer">Best Practices for Code Review #Review fewer than 400 lines of code at a time | SmartBear</a>より</em></p>
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81">
<a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
<p>本稿ではPull Requestのサイズが小さいことが良いとされる理由についてコードレビューの品質の観点からリサーチを行い、内容をまとめました。<br>
結論としては以下のことが分かりました。</p>
<ul>
<li>1時間以内に完了するPull Requestのレビューは不具合の発見率が高い</li>
<li>200から400行程度のPull Requestは1時間以内にレビューが完了する可能性が高い</li>
<li>理想的なPull Requestのサイズは200から400行である</li>
</ul>
<p>このことは見方を変えると、Pull Requestの作成者は変更行数に気を配ることによって、レビュアの仕事の質を向上させることに寄与できるとも言えます。</p>
<h3 id="pull-request%E3%82%92%E5%B0%8F%E3%81%95%E3%81%8F%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95">
<a class="header-anchor-link" href="#pull-request%E3%82%92%E5%B0%8F%E3%81%95%E3%81%8F%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95" aria-hidden="true"></a> Pull Requestを小さくする方法</h3>
<p>最後にPull Requestを小さくする方法についても簡単ですが触れておきます。</p>
<ul>
<li>複数の機能を実装しない</li>
<li>1つの機能で実装が大きくなる場合はFeature Toggleを使う</li>
<li>ついでのリファクタリングをしない
<ul>
<li>してもいいけどcherry-pickして別PRをたてるなど工夫しよう</li>
</ul>
</li>
<li><strong>本当にそのPRは分割できないか、よく自問自答する</strong></li>
</ul>
<hr>
<p>明日はフロントエンドエンジニアの<a href="https://twitter.com/high_g_engineer" target="_blank" rel="nofollow noopener noreferrer">@high_g</a>さんです。</p>
<section class="footnotes">
<span class="footnotes-title">脚注</span>
<ol class="footnotes-list">
<li id="fn-79e8-1" class="footnote-item">
<p> 本稿は社内のnotionに雑に投稿していた内容を公開用に再編集したものです <a href="#fnref-79e8-1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn-79e8-2" class="footnote-item">
<p>フロー効率の観点からPRの具体的な変更行数を調査したレポートをご存知の方いらっしゃいましたら是非教えてほしいです <a href="#fnref-79e8-2" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn-79e8-3" class="footnote-item">
<p>結構古い資料なので最近の研究についてご存知の方は教えてください <a href="#fnref-79e8-3" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn-79e8-4" class="footnote-item">
<p>白状すると筆者はこの書籍をまだ読んでいません <a href="#fnref-79e8-4" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


Pull requestの理想的なサイズとその理由

レビュー時に検出できた不具合の修正は低コストである

1時間以上かかるコードレビューは低品質

コードレビューが1時間以内に完了するPull Requestのサイズは200から400行

Discussion