メンバページ: Go

エレガントデバッグのススメ

Do you like the Elegant Debug ?

このページは、エレガントにデバッグするコツを掲載していきます。

A: エレガントデバッグって、なんですか
G: ほれ、わしのようにじゃ、優雅に歌を口ずさみ、踊りながらデバッグすることじゃ。
A: それの方が疲れるような気がしますが・・・
G: まぁ、なんじゃ、夜は寝ずに血眼になってやるデバッグとは違うんじゃ。
A: 夜は寝なくても昼間は居眠りしているような・・・
G: いや白鳥は優雅に見えて、実は努力していると
A: もういいですから、始めてください。

- 更新記録 -

1日目	エレガントデバッグとは
2日目	使えるものは何でも使え
3日目	見込み捜査の甘い罠
4日目	教科書を捨てて
5日目	デバッグパターン
5日目定時後	番外編：本当にデバッグできたのか？
6日目	非技術的なエレガントな手法って
7日目	エレガントなまとめと参考文献

1日目 --- エレガントデバッグとは

ここではエレガントデバッグについて書いていきます。

疲れることはしない

エレガントデバッグとは、一言で言えば、「疲れることをしないデバッグ」です。

疲れることをしないためには、何でもします。使えるものはなんでも使います。例えば、ソースコードのコメントも使います。これはデバッグの有用な情報になります。
既に取ってあるなら、メモリダンプも使います。しかしメモリダンプをわざわざ取ることはしないです。エレガントじゃありませんから、疲れますから。
デバッグツールはあるのであれば使います。さらに言えば「なくても」使います。新たにインストールして使います。結局はエレガントでないことをツールに任せることによって、エレガントなデバッグを進めることになることが多いからです。
ここは2日目の「使えるものは何でも使え」に詳しく書く予定です。
疲れるデバッグは、しばしば「力ずくのデバッグ」と呼ばれています。例えば、上記に出てきたメモリダンプが典型的な手法です。他によくあるのは、印字命令の散りばめです。C であれば、printf 文の散りばめです。またはデバッガによって、ブレークポインタやステップ実行を無闇に行うなどがあります。
これらのデバッグはエレガントデバッグの対極にあります。全く、エレガントではありません。
最後の手段でもないです。そもそも最初に使っている場合も多いです。

A: 疲れることはしないって、それはわがままなのでは？デバッグは疲れるものでは？
G: 疲れるのはきっと単調な仕事をしておるからじゃ。それは機械にやらせれば良いんじゃ。
A: それはそうなんですが・・・じゃ、人間は何をするんですか？
G: それがこれからの話じゃ。
A: そもそもエレガントなデバッグってどういうことなんですか？
G: それもこれからじゃ。
A: もう引っ張るなぁ〜。いいですから、始めてください。

バグの原因を考えろ！そして考えろ！

デバッグは、その多くの作業はバグの原因を掴むことです。逆に言えば、バグの原因が分かれば、その対処は容易になることが多いです。しばしば、1行で済む場合もあります。
バグの原因を探るには、「帰納法」と「演繹法」があると言われています。要するに、バグの現象から類推してバグの原因を推定するか、バグの原因を先に仮定してそれを証明するかの違いになります。
両者に根本的な差はありません。順序の問題ですので、自分のやり方に合った方を選びます。しばしば、この業界ではバグの原因を「犯人」と呼び、真犯人、主犯、従犯を見つけることを行います。
ここでエレガントなデバッグの基本法則があります。
「デバッグは楽しんで行え」、これが重要です。これがエレガントデバッグへの近道になります。
犯人を推定できれば、次に証拠集めになります。自白が得られない場合が多いですから、状況証拠の積み重ねで証明していく場合が多いです。
この段階は、兎に角、考えることになります。灰色の脳細胞をフルに使って。
ここは3日目の「見込み捜査の甘い罠」で詳しく実例で紹介していきたいと思います。注意することとともに説明します。

A: ふーん。
G: ふーん、って何じゃ？文句があるとでも？
A: いえ、一般的なことしか言っていなくて。。どこがエレガントなのか分かりません。
G: それもこれからの話じゃ。3日目に期待じゃ。
A: また引っ張るんですか？

考えても分からないときもある

バグの原因を考えて、それが証明できれば、万歳です。教科書はここまでしか書いていません。デバッグの研修でも理想的なサンプルしか用意していないです。
「エレガントなデバッグとは無闇に力ずくデバッグをせずに考えること」という単純な話になっています。
読者や受講者は、それを聞いて、分かった風になるというパターンです。
もちろん、現実は「こんなに単純な話ではありません」。

問題はつまり、どんなに考えてもバグの原因が不明であることが多いことです。
これをここでは「オカルトバグ」と呼びます。この名称もデバッグは楽しんで行うの一環です。なお、本当に怖がってはいけません。
オカルトバグが出てきたときに、どのようにエレガントにデバッグをするかを4日目の「教科書を捨てて（スマートに考えてを改題）」で、話していくようにします。つまり3日目のアンチテーゼになっています。

A: やっと面白うな雰囲気になってきましたね。でどうなんですか？
G: それもこれからじゃ、答えは「ｘｘｘするのが得」じゃ！
A: え、分かりません。
G: それもこれからのお楽しみじゃ。4日目に期待じゃ。
A: もぉ引っ張るんだから。。。

エレガントにデバッグ

エレガントデバッグとは、つまり、「力ずくデバッグ」でもない、また「単純に考えるデバッグ」でもないということです。言い方を変えれば、単純労働でもなく、数学でもないということです。
私たちはエンジニアです。エンジニアとして、エレガントにデバッグをするという使命があります。このためには、4日目で言及したことも考慮することになります。もちろん、ツールによって力ずくデバッグをやることもあります。数学者になってバグを証明することもあります。しかし本質はエンジニアとして行うデバッグです。これをエレガントなデバッグと呼びます。
ここでは、そのエレガントデバッグについて話していきます。また、周辺の話として、デバッグの確認や非技術的な話、例えば、情報伝達や共有などの話もしていくように考えています。

A: え、終わり？　バグもプログラムが1行も出てこなかったのに。。。
G: これからじゃ！
A: もぉ引っ張るんだから。。。大丈夫なのかなぁ、こんなに煽っておいて。
G: これからじゃ！・・・たぶん。時間が取れれば。

みなさんもエレガントなデバッグしていきましょう。

See you again !!