論より証拠

久しぶりにデバッグで激ハマりしております＠東京。

こういう時の傾向としてありがちなのが、時間的なプレッシャー、焦りから「手っ取り早く現象を解決しよう」として原因究明をしないまま進めようとすることです。

しかし、これは診察・診断をせずに病気を治療しようとするようなもので（いきなり投薬するとか）、仮に治ったとしてもたまたま感半端ないわけです。表面的な症状は治ったかもしれませんが（例えば吐き気とか）、本当の原因は残ったままかもしれないのです（例えば胃がんがあるとか）。

デバッグの基本的な手順として
　1. 現象の確認（確かに現象が起きることを確認する）
　2. 現象の再現（現象が再現するパターンを特定する）
　3. 原因の究明
　4. 修正対応
　5. テスト・修正のリリース
がありますが、人間はハイプレッシャーな状況に置かれるといきなり4から始めたくなる相当な欲求に晒されます。

しかし、原因がわからないということは、何故治ったのか説明できず、治ったことを証明することもできないということです。治ったのか治ってないのかよくわからないけれど（胃がんがあるかどうかはわからないけれど）、とりあえず表面的に現れている現象は出なくなった（胃腸薬の処方でとりあえず吐き気は治った）という状況。

もちろん、これで現実の運用面では問題のないこともあります。つまり、胃がんではなかったケースです。たまたまですが。風邪様症状で、いちいち精密検査などしていられない様に、手っ取り早く現象を治してしまうことが、正解であることもままあるのです。

しかし、胃がんである場合のケースではそうはいきません。修正対応からいきなり着手する方法には（早いというメリットはありつつも）より複雑で深刻な問題を見過ごすリスクが常にあるわけです。そして、繰り返しになりますが、治ったことを証明できないという大きな問題があるわけです。

原因究明なくして根治はありません。これは絶対です。何故なら、治ったことを証明できないからです。

天気の良い日に良いことがありました。これが１０回連続で続きました。そうすると天気が良い＝良いことがあると言い切りたくなりますが、１１回目で良いことがない可能性は捨てきれないのです。何故なら、天気が良いことと良いことがあることの因果関係、つまり原因を明らかにできていないからです。

原因究明を放棄したデバッグも同じです。例えば、メソッドAの一部を修正したら、不具合の現象が１０回連続で出ませんでした。これで治ったと言いたいところですが、１１回目で不具合が再発する可能性は捨てきれないのです。

時間の関係で毎回原因究明までできないことはありますし、その判断が結果として正解のこともあります。しかし、それはあくまでたまたまであることを意識しておく必要があります。デバッグにて難敵が現れたら、原因究明から逃げてはいけないのです。

論より証拠。問題があることを、問題の原因を、確実に治ったことを、証明せよ。そう自分に言い聞かせて仕事に戻ります。