デバッグ方法論

実践的なデバッグ方法論（デバッグの仕方、事例研究）も強く求められている。デバッガーというツール依存のTipsではなく、ソフトウェアのデバッグというプロセスそのものの形式化である。

人々は誰に教わるでもなく自分のデバッグのスタイルを持っている。自分なりな定石を獲得している。しかしそれを明示化して人に伝えようと試みる人は少ない。伝承がまったく不可能なような議論も少なくない。

わたしはオープンソースの時代こそデバッグの方法論を広く共有できるチャンスに満ちた時代だと考えている。いくつか事例を紹介しつつ解説する。

優れたプログラマは優れたデバッグ方法論を持つ。そのデバッグ方法論をぜひ共有化したい。そのためには情報公開が要である。

デバッグとはプログラムの不具合を修正するプロセスである。テストなどによって発見された何らかの不具合を期待する結果に修正する作業である。テストとデバッグの区別が十分ついていない初心者プログラマもいるが、これは明確に異なるプロセスである。テストは不具合を見つけるプロセス。デバッグはその不具合を直すプロセスである。

生産性の高いテストというのは単位時間あたりたくさんのバグ（不具合）を発見したテストであり、バグを発見したテストについては、テストに成功したというべきである。

一方生産性の高いデバッグというのは単位時間あたりたくさんのバグを修正したものである。

デバッグのプロセスというのは、不具合を認識（それは仕様だという場合もある）、現象を確認（再現方法の確認）、問題の理解、修正、直っていることの確認みたいな感じになる。

問題修正の部分だけをデバッグと狭義に捉える人もいるが、問題を理解しない限り問題は修正できないし、問題を理解するためには現象を再現し確認する必要もあるので、それらも含めたプロセスと認識するのが正しいと思う。

不具合というのは、ある入力に対して期待する出力（状態変移）と異なる出力という風に考えられる。期待する出力というのは、仕様を定義した人によって定義されるので必ずしも利用者のそれではないので、悪名高き「それは仕様です」ということが起こる。

それはともかく、ユメのチカラからデバッグ方法論についてのエントリをみてみよう。

プロセスプログラミングの実践方法
http://blog.miraclelinux.com/yume/2006/07/post_93da.html
デバッグのプロセスを記述することによって、デバッグのプロセスそのものをデバッグしようと言うことを提案している。プログラマとしての技量を向上させるにはデバッグ力（リョク）を向上させなければいけないが、その方法論としてデバッグのプロセスを記述し公開し共有することによって世界の誰かの目にふれさせバザール的に進化させようという試みである。

デバッグの話（昔の日記から）
http://blog.miraclelinux.com/yume/2006/07/post_b753.html
昔の日記（シリコンバレー日記）から引用している。

「ソフトウェア開発の非常に人間的な部分であるデバッグのプロセスをもっともっと深く理解したい。その思いは10年位前と変わらない。しかしながらこの10年で自分がどれほど進歩したかと言うと正直言って忸怩たるものがある。商用ソフトウェアを作っていた当時と比べて自分の専門性がどれだけ研ぎ澄まされたかと言うとほとんど進歩していないのではないだろうか。そう考えると道はとてつもなく長く険しい。

しかし10年前と現在で大きく変わったことがある。OSSとインターネットである。

10年前わたしが記述したバグ情報はすべてプロプライエタリな情報として企業の壁の中にあり同僚以外と共有することができなかった。わたしの書いたコードは門外不出だし、変更記録も、バグデータベースの記述ももちろん知的所有権の名の元に幽閉されている。

10年前はわたしとあなたは微視的なデバッグの記述を共有できなかった。

ところが10年たってわれわれはオープンソースと出会い、わたしはわたしのコードだけではなく、わたしのつたないデバッグのプロセスをあなたや世界中の誰かと自由に分かち合うことができるようになった。

なんていうことだ。

[中略]

OSSとインターネットというのはすごい環境である。」

本当にすごいことである。これを使わない手はない。自らのプログラマとしてのプロフェッショナルな価値を向上させるためにもデバッグ方法論・事例を公開し共有したいものである。

gdbの実践的使い方
http://blog.miraclelinux.com/yume/2006/09/post_fa59.html
「ソースコードの読み方」でも紹介したが、OSS定番のgdbの実践的使い方である。

トラブルシューティングの実際
http://blog.miraclelinux.com/yume/2006/10/post_5353.html
これも「ソースコードの読み方」で紹介したが、MySQLで\(半角)→＼(全角)に化けるという問題（円マークが全角の＼に化ける）についてどのように問題を分析していったかという事例である。問題領域の知識というのは必要であるが、そのトラブルシューティングの足跡というのは参考になると思う。

大規模ソフトウェアをgdbを利用して微視的視点から理解をする
http://blog.miraclelinux.com/yume/2006/09/post_8096.html
こんどはPHPでの問題である。同様に問題をどう認識して、ソースコードレベルで理解するかというプロセスを書いている。

コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html
rubyの実装をCPUキャッシュミスの観点からデバッグ（？）した事例を示している。oprofileを利用してL1キャッシュミスを計測しそれをチューニングしたというお話である。rubyの実装への実用的な価値はないのであるが、キャッシュミスをどう削減するかという事例にはなっているので参考になると思う。

PHPだろうがMySQLだろうがrubyだろうが、その構造の全般的な理解は必要ではあるが、ソースコードがあるんだから時間をかければ（早いか遅いか、上手か下手かはあるとしても）だれでも再現可能なプロセスである。

わたしはPHPやMySQLあるいは題材にしたrubyの実装についてはほとんど知らない。しかしC言語が読めて各種ソフトウェアツール(gdb/find/grep/xemacs/cscopeなどなど）が使えれば特に難しいことをするわけでもなく大抵のことができる。

コードを読むチカラ、コードを理解するチカラ。デバッグするチカラ。

OSSの時代にはそれらが強く求められている。

そしてインターネットとOSSのおかげでデバッグの方法論は世界中で共有できるようになったのである。素晴らしい世の中になったものである。

上で紹介した事例についてじっくり読んで自分自身のデバッグ事例についてぜひトラックバックで教えてほしい。世界はあなたのデバッグ事例を待っている。