差分デバッグ

回帰バグとは、これまで提供されてきたソフトウェアの機能に新たに発生したバグです。このバグを追究するときは、ソフトウェアのどの変更によって発生したのかを突き止めることが通常は役立ちます。その変更を調べることで、バグの位置や解決方法の手がかりを得られます。このような調査方法にはよく知られた用語はありませんが、私はDiffデバッグと呼んでいます。

Diffデバッグは、コードがバージョン管理されている場合にのみ機能しますが、幸いにも現在はそれが標準になっています。ただし、効率的に機能させるために必要なことが他にもいくつかあります。古いバージョンのソフトウェアを簡単に実行できるように、再現可能なビルドが必要です。また、高頻度統合により、コミットが小さいと非常に役立ちます。そうすれば、有罪のコミットが見つかっても、何が起こったのかをより簡単に特定できます。

バグを発生させたコミットを見つけるには、最初にバグのない過去のバージョンを見つけます。これを正常な最後のバージョンとしてマークし、現在のバージョンを不具合の最初のバージョンとしてマークします。次に、その2つのちょうど中間のコミットを見つけて、バグがあるかどうかを確認します。ある場合、このコミットは不具合の最初になり、それ以外の場合は正常な最後になります。このプロセス（「半インターバル」検索または「バイナリ」検索）を、有罪のコミットを確認するまで繰り返します。

gitを使用している場合、git bisectコマンドはこの作業の多くを自動化します。バグの存在を示すテストを書くことができる場合、git bisectもそれを使用して、有罪のコミットを見つけるプロセス全体を自動化できます。

Diffデバッグは、プログラミングセッション内でも役立つことがよくあります。実行に数分かかる低速テストがある場合、関連性の高いテストのサブセットのみを実行して30分間プログラミングします。緑色のテストの実行ごとにコミットを行う限り、低速テストの1つが失敗した場合にDiffデバッグを使用できます。長期的履歴ではそれらをまとめる方がよいと感じるほどコミットが小さくても、頻繁にコミットする価値があります。一部のIDEでは、バージョン管理へのコミットよりもきめ細やかなローカルの履歴を自動的に保持することで、この作業が容易になります。