デバッガー

Coders at Work

• 作者: Peter Seibel
• 出版社/メーカー: Apress
• 発売日: 2009/09/11
• メディア: ペーパーバック

昨日やっと届きました。とりあえず、Joshua Bloch氏のインタビューだけ読みました。"How did you get into programming?"という質問に対して、1971年に彼がまだ10歳の時に父親がプログラミングコースでFortranを習っていたので、父親からFortranを教えてもらったという話から始まっています。1971年といえば、私は12歳で佐賀県の嬉野に住んでいましたが、コンピュータに触れる環境など全くない頃でした。私が始めてプログラミングを覚えたのは、大学に入学してからですので18歳でした。

このインタビューの中で一番驚いたのは、大学院を修了して、Sunで働きはじめる1996年まではずっとC言語でプログラミングをしてきており、真剣に使った最初のオブジェクト指向言語がJavaだということです。1996年からJavaを始めて、コレクションフレームワークを設計・実装し、2001年に『Effective Java プログラミング言語ガイド』を出版するのですから、やはり、普通の人ではないということでしょう。

色々と興味深い内容が書かれているのですが、デバッグではどんなツールを使うのかとうことに関して、次のように回答しています。

Bloch: I'm going to come out sounding a bit Neanderthal, but the most important tools for me are still my eyes and my brain. I print out all the code involved and read it very carefully.

少しばかりネアンデルタール人のように聞こえるかもしれませんが、私にとって最も重要なツールは今もなお私の目と私の脳です。関連するコードを印刷して、それを注意深く私は読みます。

Debuggers are nice and there are times when I would have used a print statement, but instead use a breakpoint. So yes, I use debuggers occasionally, but I don't feel lost without them, either. So long as I can put print statements in the code, and can read it thoroughly, I can usually find the bugs.

デバッガーは素晴らしいですし、いつもならprint文を入れるような時に、代わりにブレークポイントを使うこともあります。だから、たまにはデバッガーを使うこともあります。しかし、デバッガーがないと困るわけではありません。コードにprint文を入れることができて、じっくりと読むことができれば、大抵はバグを見つけることができます。

As I said, I use assertions to make sure that complicated invariants are maintained. If invariants are corrupted, I want to know the instant it happens; I want to know what set of actions caused the corruption to take place.

先ほども述べたように、複雑な不変式が維持されているかを確認するために、アサーションを使用します。もし、不変式が破られていたら、それが破られ時にすぐに知りたいのです。つまり、破壊を起こした処理が何であるかを知りたいのです。

私も実は、デバッガーはほとんど使いません。それに、コードにやたらデバッグ用のトレース文を入れたりするのも嫌いです。本来のロジックがトレース文の中に埋もれているようなコードを見るとうんざりする時があります。

デバッグの時に、自分の仮説を検証するための最低限のprint文を入れてデバッグし、デバッグが終わったらそのprint文を削除します。

デバッガーに頼りすぎると、デバッガーがないとデバッグできませんという人も現れてきます。さらに、デバッガーが知りたい情報を表示してくれないので、デバッグできませんと言う人まで現れてきます。

（「デバッグの科学的手法」）

コメント 2

デバッグは人によってかなり効率の差が出るものの１つですよね。ここにも「デバッグの科学的手法」の方にもあるように、ツール云々の前に失敗の原因について仮説をたててそれを検証するのが大事、というご意見に大賛成です。
でも、これは他人に伝えるのが難しいです。今後輩にアドバイスする立場にいるんですが、失敗の原因について仮説をたてたり、考えられる可能性を絞り込んでいく勘みたいなものをなかなか伝えられずにいます。
by Shou Takenaka (2009-09-24 22:37) 

Shou Takenakaさん、

教えるのはなかなか難しいですね。私の経験からすると一緒にデバッグしながら、相手に色々と聞くことで相手に考えてもらうのが、一つの良い方法です。

仮説を立てるためには、知識と経験が必要ですので、初心者にはなかなか難しいとは思います。知識は、継続した学習で補ってくださいと教育していくしかないかと思います。

指導する立場だと、原因と現象としてのバグとの因果関係をきちんとと説明させることを、繰り返し指導することも重要ですね。
by Yoshiki (2009-09-25 04:47)