スコープクリープの回避

スコープクリープとは、単一の貢献によって解決される問題や実装される機能のリストが、作業開始時に想定していた範囲を大幅に超えて膨張する現象を指す。単純な問題から着手し、密接に関連する問題を発見してその修正も追加し、さらに第三の問題が…気がつくと、5件の問題を解決し3つの新機能を追加するプルリクエストが完成している。そこには数十ものファイルが含まれているのだ。

スコープクリープは誰にでも起こり得る。経験豊富な開発者にとってはおなじみの概念であり、誰もが何度も経験し、それに伴うあらゆる問題に直面してきた。

スコープクリープを避けるべき非常に現実的な理由があります。貢献が大きくなるほど、扱いが難しくなります。エッジケースや潜在的な問題を特定するのが困難になり、貢献の全体的な品質が低下する可能性があります。 また、レビュアーが複数の、おそらく関連性のないコンテキストを扱う必要がある場合、レビュー作業もより困難になります。貢献が大きくなるほどレビューコメントも増え、貢献者として複数のレビュースレッドを追うのが難しくなる可能性があります。GitHubの操作体験さえも損なわれます——プルリクエストのサイズが大きくなるにつれてGitHubのUIは遅くなり、GitHubインターフェースを通じてファイルをナビゲートしたりレビューコメントを残そうとしたりすることが次第に困難になるのです。

貢献内容に、元の提案やバグ報告に明示的に含まれていない要素を追加する理由を見つけた場合は、スコープクリープに陥っていないか検討すべきです。 別々に実装可能な2つの独立した機能はありませんか？既知の制限やバグを抱えた状態で機能を実装し、後続のプルリクエストでそのバグを修正することは可能ですか？バグ修正の一部は他の部分と独立していませんか？変更の一部を省略しても元の貢献内容が変わらない場合、おそらく省略すべきです。

ソフトウェア開発は常に段階的な改善のプロセスです。個々の貢献はマージの結果としてコードベースをより良い状態にすべきですが、バグや機能の一部を将来の改善課題として残すことは全く問題ありません。そのためにはプルリクエストを独立してレビュー可能な複数の部分に分割したり、誰かが調査・解決できるよう問題を記録したりすることが考えられます。

各投稿の範囲を限定することは、関係者全員、あなた自身も含めて有益です。査読者も、そしてあなた自身も、そのことを高く評価するでしょう。