InfoQ

News

デバッガは有害か?

作者 Werner Schuster, 翻訳者 編集部 投稿日 2007年11月9日 午前12時40分

コミュニティ
Ruby
トピック
デバッグ,
ソフトウェアテスト,
コード分析,
プログラミング
タグ
テスト,
BDD,
Code Coverage,
SmallTalk

Giles Bowkett 氏は、Debugger Support Considered Harmful (デバッガサポートは有害だ) (source)で次のように記述している。

Ruby のデバッガサポートが貧弱である理由を尋ねるのは、イルカにえらがない理由を尋ねているのと同じです。Ruby のデバッガサポートが貧弱であるのは、Ruby プログラマはデバッガを使用すべきではないからです。Ruby は、おそらく Smalltalk を除いた他のどの言語よりも TDD および BDD に対するサポートが優れています。デバッガサポートは、テストを正常に実行することができない言語のためのものです。

注意: TDD は「テストドリブン設計/開発」、BDD は「ビヘイビアドリブン開発」を表す。 

この記事はさまざまな反響を呼んだ。その多くが、Smalltalk コミュニティからのものであった。Smalltalk と Ruby は近い親戚のようなものであり、特に関係が深い。Cincom Systems の James Robertson 氏(source)は、TDD を行う際に Smalltalk のデバッガが有用であることを説明するスクリーンキャスト(source)を作成し、次のように説明している。

私は、テストを作成し、それを実行します。テストが失敗したら、テストをデバッグして、デバッガで不足しているメソッドを作成します。つまり、デバッガでそのメソッドのコードを記述し、すぐにもう一度テストを実行するのです。これは、うまく機能しない場合のための予備的手段ではなく、より高度な TDD の方法であると言えるでしょう。 

Avi Bryant 氏 (Smalltalk の Seaside Web フレームワークの作成者) は次のように述べている(source)

Giles 氏は、コードを最初にどのように理解するかについて触れていません。コードを理解するには、それが自分で記述したものであっても、他の人が記述したものであっても、デバッガで一行ずつ追ってみるのが一番です。Giles 氏は、脚本家でもあるようなので、次のようなたとえが良いでしょう。コードを読むことは、脚本を読んでいるようなものです。テストを作成することによって、絵コンテを作成するのと同じように、最終的な成果物を視覚化することができます。デバッガを使用するのは、スロー再生などの機能を使用しながら映像を見ていくことに似ています。

Blaine Buxton 氏は、デバッガの役割を別の方向から考えている(source)

デバッガは、新しいフレームワークを試し、それがどのように機能するかを確認する際に、試験的にプログラミングをしてみるときに非常に役立ちます。私は、一行ずつ追ってみることが好きなので、実際に Seaside を学習するときにそうしました。これは、どんな文書よりも役立ちました。デバッガ内に展開されるすばらしいコードを見ることは、まさに優れた書籍を読むことと同じだと言えます。また、ひどいコードを扱っているときは、単に見ているだけではわからないことをデバッガが教えてくれます。動物なら、生きていれば、各器官がどのように機能するかを見ることができます。それなのに、なぜ動かないものを解剖して調べようとするのでしょうか。
Ben Matasar 氏は、「デバッガ」という名前が問題である(source)とコメントを寄せた。

私は、デバッガという名前が人々に間違った考えを抱かせていると思います。少なくとも、Smalltalk に関してはそうでしょう。私は、昨年の 12 月に初めて Smalltalk を使いましたが、このときデバッガを使用しようとはしませんでした。デバッガは、困ったときに使う補助機能であると考えていたからです。現在は、コードベースの中で自分の方向性を見出すためによく使用しています。実際、私は、デバッガからそのまま大量のコードを記述します。Web ブラウザの応答を待っている間に作業してしまうこともよくあります。

今では、デバッガはメソッドコンテキストブラウザであると考えています。コールスタックの各ステップに有効な REPL が存在します。これが優れているのは、オブジェクトにメッセージを送信し、オブジェクトを調査し、それらがメッセージにどのように応答するかを確認できる点です。 

上記から考えると、従来のデバッガは、ブレークポイントや任意の場所で実行を中断し、現在の状態を確認するためのツールを指していた。こうした機能は、ソースコードを単に見るだけの場合に比べて、システムの実行時の実際の動作を開発者がより理解できるようにするための、一連のツールの一部であると考えることができる。この一連のツールには、カバレッジツール (たとえば、rcov(サイト・英語))、プロファイラトレーサ、またはロガーなどが含まれる。

最初のブログ記事には、Ruby のデバッガサポートが十分ではないという主張も含まれていた。しかし、何を指してそう主張しているのか明らかではない。Ruby インタプリタにはデバッガサポートがある (Ruby で作成された遅いものと、ruby-debug(サイト・英語)などのより高速なもの)。これは、JRuby についても言えることであり、現在では、高速なソリューション (jruby-debug)(source) が機能するようになっている。Rubinius などの他のRuby 実装には、オーバーヘッドの少ないデバッグ機能がある(source)。また、下層にある VM のデバッグサポートを使用することもある。

当然ながら、デバッガの実装は一面でしかない。デバッガのユーザーインターフェイスも使用可能でなければならない。しかし、これも Ruby において使用することができる。主な最新の Ruby IDE は、デバッグをサポートしている。RDT (現在は Aptana の一部)(サイト・英語) では、長年にわたってデバッグがサポートされている。最近の Netbeans(source) のデバッグサポートは、RDTと同じコードベースを基にしている(source)。Eclipse DLTK Ruby(サイト・英語) にも、他の非 Java ベース IDE (Steel IDE 内の Sapphire Steel の Ruby(サイト・英語)、Komodo(サイト・英語)など) と同じようにデバッグサポートがある。  

Ruby のデバッグに関して、どのような経験をお持ちだろうか。

原文はこちらです:http://www.infoq.com/news/2007/10/are-ruby-debuggers-harmful

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

ジャンル別一覧

インタビュー: Emmanuel Bernard氏にBean Validation仕様について聞く

Bean Validationフレームワークの初期ドラフトに関する以前の記事に続き、InfoQは専門家グループが求めているコミュニティの関与と提案について理解を深めるため、Emmanuel Bernard氏と対談しました。

ポーカーに学ぶ、ソフトウェア開発のレッスン

ポーカーは他のトピックにも広く適用できるような数少ない教えを私にもたらしてくれたと信じています。実際私はソフトウェアを開発すればするほど、これら二つの仕事は非常に似ていると言う確信の度合いを深めています。

InfoQがBPEL4PEOPLEの代表と対談

恒例の「バーチャルパネルセッション」で、InfoQは新しいOASIS BPEL4People技術委員会の代表と対談をし、この作業が何故必要であるかについて彼らのフィードバックを得る機会を得ました。

CLR上でのドメイン特化言語の構築

ドメイン特化言語は最近非常に人気が高まっている話題です。これは恐らく、Rails現象に起因していると考えられます。Railsの人気と、Railsにおけるドメイン特化言語(以降、DSL)の大規模な使用は、DSLに対する広範な関心を呼び起こしました。

Rubyのデバッガを調査

Rubyには、Rubyコミュニティの内外で広く知られている誤解が一つある。Rubyにはデバッガがないという誤解だ。しかし、Rubyにデバッガが無いということは誤解なのだ。実際のところ、Rubyにはデバッガ用のツールがある。

改善、成功と失敗: 中国でのスクラム導入

InfoQ Chinaは中国でスクラム(Scrum)がどのように導入されているかに関する調査を行いました。私たちはこの記事のために5つの事例をピックアップしました。これらの事例は、異なるさまざまな会社によるもので、異なるプロセスが利用され、異なる結果が生じたものです。

洗練されたサービス契約による見事なスケーラビリティ

Udi Dahan氏のチームが、サービス契約を利用した2度の失敗を避け、複数の側面でのスケーラビリティに対処しています。

塹壕より Scrum と XP

Agileを始めるときは、とても分かりにくいです。一体どこから手をつければいいのでしょう?この物語はそんな皆様の一助になれば幸いです。本書は、スウェーデンにある、とある40人ほどの会社で、どのようにAgileとXPを実行したか、プロセス改善を行ったかを記しています。