http://martinfowler.com/bliki/DiffDebugging.html

最近の話だが、ある本を執筆中にサンプルコードを書いていた。すると、テストが失敗してしまった。「ぐわっ」青ざめた。「先週はパスしてたじゃん。何だよこれ。」そこで私は目の前にあるコードのバグを探すよりも、思い浮かんだ「ある方法」を試してみることにした。これを「diffデバッグ」と命名することにしよう。

まずは、最後に動いていたと思われるコード（5/14分）を新規にチェックアウトした。 そしてコンパイル。それからテスト。よし、さっき失敗してた項目はパス出来た。次に、レポジトリのログを見てみた。そのときから変更されたのは、ええと、次の日だな。auto-import用にコメントを追加したんだ。5/15分を別のディレクトリにチェックアウト。今回はテストが失敗してしまった。うーん、つまり、この5/15に何かヤッチまったわけだな。

ミスを探すため、diffツールを投入。2つのディレクトリの差分を取り、どこが変更されたかをじっくり見ていくことにした。まずは、それっぽいファイルから始めた。変更点をざっと見る。コメントがいくつか追加されていた。リネーム個所もいくつかあるようだ（IntelliJでリネームの失敗をしたことはない）。それから、ええと、うげげげ、行が削除されてる……orz。削除された行の名前が、失敗したテストの個所であることを明確に示しているよ。脳内で「つーか、なんでこの行を削除したんだ？」というバックグラウンドプロセスが走り出したが、私のメインプロセスは、削除した行を元に戻す→レポジトリの先っちょに戻す→テスト→緑→ウマー(゜Д゜)、である。

さて、さっきのバックグラウンドプロセスをフォアグラウンドに戻そう （デバッグをした後で、心の中でミニレトロスペクティブ(訳注：レトロスペクティブ：回顧。コーバーンが提唱している。)を行うのはいいことだ）。 どうして行を消してしまったのか？ 答え：（自信たっぷりに）IntelliJとEmacsのキーバインドが私の指と合わなかったから。IntelliJでは、何も選択しないでCTRL-Xを押すとその行をカットしてしまう。これまではこれで何も問題なかったんだが（もっとも、使ったことがないからなんだが）、去年、emacsをめちゃくちゃ使ってたのね。O S に で も な る ん じ ゃ ね ー か と い う エ デ ィ タ を使っている人なら分かると思うけど、emacsでバッファを保存するには、CTRL-X, CTRL-Sという一連のキーを押さなきゃならんわけよ。この2つのキーはすぐ指になじんじゃうだな。だから、IntelliJを使っているときに、保存する前に行を削除しちゃった、というわけだ。早速、pluginを入れて、このCTRL-Xキーバインドを外してやったわい。

今回の講義で一番大切なのは、藻前ら、diffデバッグは重要ですよ、ということだ。 レグレッション問題があり、テストを行う必要があり、合理的なビルドプロセスが必要であれば、この方法は十分機能する。合理的に素早く問題個所を発見できるだろう。 ローカルにバージョン管理機構があれば、プログラミング中にdiffデバッグを行うこともできる。だいたい皆、そうやっているようだ。もちろん、やってない人間も多い。ビルドプロセスが難しすぎると思っているようだ。しかし、ビルドプロセスがうまくいけば、どんなデバッグ方法よりもうまく行くと思うぞい。