プログラマyasuhoの隠れ家

某ソフトウェア企業に勤務するおじさんプログラマyasuhoです

名探偵プログラマ

プログラマという職業について、もう25年くらいになるのであるが、その間にコンピュータのコストパフォーマンスは、それこそムーアの法則に従って、10万倍〜100万倍くらい向上した。にもかかわらづ、デバッグの方法というものの劇的な変化はほとんどみられない。


プログラミング入門書では、デバッグについて、ほとんど議論されていないし、仮にふれられていても、おざなりな方法というか、かなり邪険にあつかわれていたりする。プログラマの多くの時間がデバッグについやされていたとしてもだ。

わたしがprintf()デバッグをしない理由 - 未来のいつか/hyoshiokの日記

ところで、皆さんは、誰にデバッグ方法を教えてもらったのだろうか?テストの方法を誰に教えてもらったのだろうか。あるいは、ソフトウェア開発方法論を誰に教えてもらったのだろうか。学校でならったのは、プログラミング言語の文法であり、アルゴリズムであり、コンピュータアーキテクチャであった。デバッグ方法は誰も教えてくれなかったので、見よう見まねで行っていたのが学生時代だったような気がする。

デバッグ方法論 - 未来のいつか/hyoshiokの日記


たしかに私もデバッグの方法論を教えてもらった経験はあまりないような気がします。そういった書籍をあまり見た覚えもないですね。

ではどうやって学んだのかと言えば


吉岡さんの言われているように「見よう見まね」だった気がします。その多くは誰かが問題を発見した過程から学ぶことが多かったですね。時にはそれはソースコードの中であったり、デバッグのknow howを記載した社内ドキュメントやサイトであったり。


学んだというとカッコいいですが、実際には訳の分からない問題を解決しなくてはならなくなり、解決方法をやみくもに模索している中で覚えた、というのが正確なところでして。:)


私はわりと特殊な環境下でのデバッグが多かったので、多くの人には役立たないと思いますが、自分なりのデバッグ手法を紹介してみたいと思います。興味のある方はどうぞ。


デバッグは最高に面白いパズルゲーム - yasuhoの隠れ家
デバッグを想定しながらコードを書こう - yasuhoの隠れ家
訳の分からない問題に対処するには - yasuhoの隠れ家

ちなみに私もprintf()デバッグはあまりしません


もちろんその方が効率がいい場合には使いますけどね。なぜかと言うと、


デバッグに大切なのは推理する力


だとyasuhoは思うからなのです。

まわりにいませんか?


ちょっと見ただけで問題の原因を見つけてしまう人。私のまわりにもいます。「そんな短時間でなぜ分かっちゃうの?」残念ながら私はそういう人ではないので、あくまで推測なのですけど、そんな人は推理する能力が高い人じゃないかと思うのですよね。


もちろん豊富な経験があってこその力なのでしょう。けど、最初に原因を推測するには、ある種のカンが必要なのだと思います。最終的には検証が必要ですが、まずはアタリをつけてみないことには始まりませんよね。


デバッガやログ収集はあくまで補足的に使われるべきだと思うのです。そもそもデバッガが常に使えるとは限らない。再現性が低く、情報収集もままならない環境で発生した問題の原因究明は少なくありません。


一見少なく見える現象から多くの情報を見つけだす。一つの見方にとらわれず、いろいろな角度から物事を見てみる。複数ある選択肢を消去法で潰し、やがて真実を見つけだす。


そんな名探偵みたいなプログラマになれたらいいな。:)