Ruby デバッグ完全ガイド | puts から高度なツールまで徹底解説

Ryuji Owan

Read this post in other languages:

• English

Ruby 開発者の皆さん、こんにちは！

デバッグはソフトウェア開発に欠かせないスキルです。この記事では Ruby コードの動作を調べる方法について取り上げます。 RubyMine チームには Ruby 開発者向けツールの開発に関する膨大なノウハウが蓄積されているため、その経験と知識を皆さんと共有したいと思います。

先日の EuRuKo 2024 カンファレンスでは、当チームのメンバーである Dmitry Pogrebnoy が「Demystifying Debuggers（デバッガーを解明する）」という講演を行いました。 このブログ記事は、そのプレゼンテーションに基づいて Ruby アプリケーションのデバッグに役立つインサイトを提供することを目的とした連載の最初の記事です。

あらゆる Ruby プログラマーにとって、コードが期待どおりに動作しない状況は避けられません。 そのような状況では、誰もが問題を素早く正確に特定して修正できる効率的な方法を望むものです。 そこで活用できるのが、デバッグツールです。

この記事では Ruby 開発者がバグの調査に使用できるさまざまなツールと手法を詳しく取り上げ、 いくつかの種類のツールについて、その強みと弱みと共に説明します。 各ツールの特徴を理解することで、特定のデバッグシナリオに最も効果的なツールを選択することができます。

JetBrains 社内のある Ruby プロジェクトで遭遇した実際のバグを例に挙げて具体的に説明したいと思います。 このケーススタディによって適切なデバッグ手法の重要性を説明し、デバッグツールを考察するための準備を整えます。

経験豊富な Ruby 開発者であれ初心者であれ、このガイドを活用してデバッグスキルを磨き、より効率よくバグに取り組むことができます。 では始めましょう！

RubyMine チームが体験した実際のバグ

RubyMine チームが取り組んでいるのは IDE 自体の開発だけにとどまりません。 IDE の機能を拡張する独自の gem をいくつも作成しています。 インサイトを共有するため、1 年ほど前にこのような gem の 1 つで見つかった実際のバグを詳しく取り上げます。 核心的な問題に注目できるようにするため、コードサンプルを切り離して単純化しました。

次の Ruby コードを見てみましょう。

def process(thing)
 if defined? thing.to_s || defined? thing.inspect
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5)               # -> Element is Printable
process(BasicObject.new) # -> Element is Printable

この process メソッドは一見すると単純です。 特定の引数に to_s または inspect メソッドがあるかをチェックするのが目的です。 process はどちらかのメソッドが存在する場合に「Element is Printable」を出力し、どちらも存在しない場合に「Element is Not Printable」を出力するようになっています。

このメソッドの 2 つの呼び出しとその出力が一番下に書かれています。 最初の呼び出しである process(5) は「Element is Printable」メッセージを生成します。 これは正しい動作です。 しかし、2 つ目の process(BasicObject.new) という呼び出しは疑わしく思えます。 この呼び出しは BasicObject を引数に取っていますが、「Element is Printable」を出力しています。 BasicObject インスタンスは探しているどちらのメソッドにも対応していないため、この動作は誤っています。 つまり、このコードには明らかにバグがあります。

では、process メソッドを詳しく見てみましょう。 バグを見つけられますか？

defined?(thing.to_s || defined?(thing.inspect))

def process(thing)
 if defined?(thing.to_s) || defined?(thing.inspect)
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5)               # -> Element is Printable
process(BasicObject.new) # -> Element is Not Printable

このような実例を紹介することで、デバッグが経験レベルを問わずあらゆる開発者に不可欠なスキルであること示したいと考えています。 これはエラーを修正するだけのスキルではなく、言語の複雑さを理解してより信頼性の高いコードを書くスキルです。

より複雑な本番環境レベルのアプリケーションでは、このような問題を特定して解決するのははるかに困難になります。 このことは、次のセクションで取り上げる堅牢なデバッグツールと手法の重要性を明確に示しています。

最適なツールを選ぶ

Ruby コードのデバッグに関しては、開発者がすぐに使用できるツールと手法がいくつかあります。 まずは基本的な選択肢を確認した後、より高度な手法を詳しく見ていきましょう。

puts ステートメントの使い方とその限界

最も基本的でセットアップや追加の gem を必要としないのは、puts ステートメントを使用するデバッグ手法です。 この手法では変数値や実行フローの情報を出力するため、コード内に直接 print ステートメントを挿入する必要があります。 単純な手法ではありますが、素早く調査するには驚くほど効果的です。

この手法を前の例に適用してみましょう。

def process(thing)
 puts "defined? thing.to_s: #{defined? thing.to_s}"
 puts "defined? thing.inspect: #{defined? thing.inspect}"
 puts "defined? thing.to_s || defined? thing.inspect: #{
   defined? thing.to_s || defined? thing.inspect
 }"
 if defined? thing.to_s || defined? thing.inspect
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5)
process(BasicObject.new)

これにより、以下の出力が得られます。

defined? thing.to_s: method
defined? thing.inspect: method
defined? thing.to_s || defined? thing.inspect: expression
Element is Printable
defined? thing.to_s: 
defined? thing.inspect: 
defined? thing.to_s || defined? thing.inspect: expression
Element is Printable

引数が異なる 2 つのメソッドからの出力に矛盾があり、問題がありそうな箇所が示されています。 BasicObject.new の場合、thing.to_s と thing.inspect のどちらも未定義であるにもかかわらず、条件が true に評価されているのが分かります。

基本的な puts ステートメントは便利ですが、いくつかの gem を使ってより多くの情報を得ることができます。

1. puts_debuggerer gem は、ファイル名、行番号、およびその行の内容を puts の出力に追加します。

例:

require 'puts_debuggerer'
pd "defined? thing.to_s: #{defined? thing.to_s}"

出力:

[PD] example_puts_debuggerer.rb:5 in Object.process
   > pd "defined? thing.to_s: #{defined? thing.to_s}"
  => "Debug print 1: method"

2. awesome_print とそれに類似する gem は、より構造化された読み取りやすい出力を提供します。複雑なオブジェクトには特に便利です。

puts ステートメントは概して便利であり、単純なケースや何らかの理由で他のツールでは対応できない場合には効果的ではありますが、 puts ステートメントは非常に基本的です。 既存のメッセージを調整したり、新しいメッセージを追加したりするたびにソースコードを変更しなければなりません。 出力内容を変更するたびにプログラムを再起動する必要もあるため、通常は利便性に欠けています。

puts を使用したデバッグの長所と短所

長所:

• 単純ですぐに実装できる。
• あらゆる Ruby 環境で機能する。
• 追加のツールやセットアップが不要である。

短所:

• ソースコードの変更が必要である。
• 使いすぎるとコードが乱雑になる。
• 出力内容を変更する際にはプログラムの再起動が必要になる。
• より高度なツールに比べて情報量が限定的である。

puts ステートメントは素早く確認する場合には非常に有益ですが、複雑なシナリオの場合や頻繫な変更が必要な場合にはあまり効率的ではありません。 そのような場合には、対話型コンソールやフル機能のデバッガーなどのより高度なツールを使用することで、さらに優れた柔軟性と性能を得られます。

対話型コンソールを使ったデバッグ

Ruby 開発者にとって、対話型コンソールは次のレベルのバグ調査ツールと言えます。 主な選択肢としては IRB と Pry の 2 つがあり、どちらも強力なイントロスペクション機能を備えています。

対話型コンソールをデバッグに使用する場合、一般的にはソースコードに binding.irb または binding.pry 呼び出しを挿入する必要があります。 バインディングのコマンドが実行されると対話型コンソールが起動し、現在のコンテキストにアクセスし、そのコンテキスト内で任意の式を実行できるようになります。

前の例で IRB を使用してみましょう。

def process(thing)
 binding.irb
 if defined? thing.to_s || defined? thing.inspect
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5) # -> Element is Printable
process(BasicObject.new) # -> Element is Printable

コードが binding.irb の行に到達すると、対話型セッションが始まります。

From: 5_example_define_irb.rb @ line 2 :

    1: def process(thing)
 => 2:   binding.irb
    3:   if defined? thing.to_s || defined? thing.inspect
    4:     puts "Element is Printable"
    5:   else
    6:     puts "Element is Not Printable"
    7:   end

irb(main):001> defined? thing.to_s
=> nil
irb(main):002> defined? thing.inspect
=> nil
irb(main):003> defined? thing.to_s || defined? thing.inspect
=> "expression"
irb(main):004> exit
Element is Printable

この対話を通して条件の各部分の動作を調べ、問題を特定することができます。

対話型コンソールを使用したデバッグの長所と短所

長所:

• puts ステートメントよりも複雑で柔軟である。
• その場での調査が部分的に可能である。
• すべてのデバッグ出力を事前に決める必要がない。

短所:

• ソースコードの変更が必要であることには変わりない。
• イントロスペクション箇所を事前に定義しておく必要があり、実行時に変更できない。
• イントロスペクション箇所を変更する際にはプログラムの再起動が必要になる。

対話型コンソールの場合は単純な puts ステートメントよりも高い性能を得られますが、制限がなくなるわけではありません。 たとえば、複雑なデバッグシナリオの場合や実行を細かく制御する必要がある場合、フル機能搭載のデバッガーであればさらに多くの機能を使用できます。

RubyMine デバッガーで効率的にバグ修正

デバッガーは、Ruby コードのバグ調査に使用できるツールの中では最高峰のものです。 単純な puts ステートメントと対話型コンソールをはるかに超える機能を備えており、プログラムの実行を完全に制御できます。 開発者はこの強力な機能セットを使用して以下の操作を行えます。

• ブレークポイントを使用して特定箇所で実行を停止する。
• 変数をリアルタイムに検査して変更する。
• 各ブレークポイントでコールスタックを調べる。
• コード行単位でステップ実行する。
• 現在のコンテキストの式を評価する。

Ruby 用の主な 3 つのデバッガーを詳しく見てみましょう。

1. byebug gem

• Ruby 2.5.X、Ruby 2.6.X、Rails 5、および Rails 6 用のデフォルトのデバッガー。
• ブレークポイント、ステップ実行、コンテキスト、スタックイントロスペクションなど、デバッガーに求められる基本機能がすべて備わっている。
• Rails アプリケーションの場合、アプリケーションのソースコードを変更する必要がある。 通常はコード内の決まった箇所にデバッガーを起動する特殊な呼び出しを書く必要がある。
• 複雑なアプリケーションでは利便性が低下するほどの顕著なパフォーマンスオーバーヘッドがある。

2. debug gem

• Ruby バージョン 2.7 以降のみをサポートしている。
• サポート対象の Ruby バージョンではパフォーマンスオーバーヘッドがない。
• Rails アプリケーションの場合、byebug と同様に debug ではアプリケーションのソースコードを変更する必要がある。
• Ruby バージョン 3.1 以降にバンドルされている。

3. RubyMine デバッガー

• Ruby バージョン 2.3 以降をサポートしている。アプリケーションが使用する可能性のあるほぼすべての Ruby バージョンをサポートしている。
• サポート対象のすべての Ruby バージョンでパフォーマンスオーバーヘッドがない。
• コードを変更せずにデバッガーを使用できる。
• デバッグを合理化する使いやすい UI が初期状態で備わっている。

デバッガーには広範な機能セットが備わっていますが、一部の特定の構成では使いにくい場合があります。 デバッガーは強力ですが、他のデバッグ手法と併用すると最大限の効果を得られます。 多くの場合、デバッガーの選択は特定のプロジェクトと構成要件、Ruby のバージョン、および個人の好みによって決まります。

まとめ

Ruby でのデバッグはスキルと科学であり、適切なツールで克服できる課題があります。 この記事で取り上げたように、単純な puts ステートメントから高性能なデバッガーまで、Ruby 開発者には使用可能なツールキットが豊富に提供されています。

ここで説明したデバッグ手法にはそれぞれに長所があります。

• puts ステートメントは明確なインサイトを素早く提供するため、単純な問題や他のツールを使用できない場合に最適です。
• IRB や Pry などの対話型コンソールではより動的な環境を得られるため、深いコンテキストのイントロスペクションや複雑な式の評価が可能です。
• byebug gem や debug gem、RubyMine デバッガーなどのフル機能搭載のデバッガーではプログラムの実行を包括的に制御できるため、開発者はどんなに複雑なバグでも解析できます。

予期しないバグを発見して正確な原因を特定するまでは、このようなツールを組み合わせて使用して体系的な調査を行うのが一般的で、時には創造力を駆使して問題を解決する必要があります。 各デバッグツールの長所と制限を理解することで、それぞれの固有の状況に最適な手法を選ぶことができます。

RubyMine チームは、弊社のデバッグツールが Ruby コミュニティでどのように活用されているかに特に関心を持っています。 ぜひ RubyMine デバッガーを詳しくお試しになり、下のコメント欄で体験を共有していただくか、課題トラッカーに課題を作成してください。 あなたのインサイトは他の開発者の役に立つはずです。

次回の記事では、デバッガーの内部の処理についてさらに詳しく説明します。 内部の仕組みを詳しく見ながら、基本的なデバッガーをゼロから作成するという刺激的なチャレンジにも取り組みます。 その説明を通じてデバッグツールの理解を強化し、Ruby の内部処理に関するより深いインサイトを得られるでしょう。

それまでは、RubyMine の高度なデバッガーを活用してください。 最新の RubyMine バージョンは弊社ウェブサイトか無料の Toolbox App からダウンロードできます。

単にエラーを見つけて修正するだけでは効果的なデバッグは行えません。基礎レベルのコードを理解することが重要です。 各デバッグセッションは、学習、改善、およびより堅牢な Ruby コードを書くための機会です。

好奇心を保ち、探究し続け、デバッグを楽しみましょう！

RubyMine チーム一同より

オリジナル（英語）ブログ投稿記事の作者：

Dmitry Pogrebnoy

Subscribe to RubyMine Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

このフォームを送信することにより、私は JetBrains s.r.o.（以下「JetBrains」）が私宛のニュースレターの送信や営利目的の連絡などで私の名前、メールアドレス、および位置情報データを使用し、この目的のために私の個人データを処理することに同意します。私は、JetBrains がこの目的のために JetBrains プライバシーポリシーに従ってサードパーティのサービスを使用して当該データを処理する場合があることを承諾します。私は私のプロファイルでいつでも同意を取り消すことができることを理解しています。また、各メールには配信停止リンクが含まれています。

Submit

ありがとうございます。受け付けました！