デバッガーはバグ修正だけでなく、コードを読むための道具

はじめに

この記事では、プログラミングを学ぶときに、言語の知識と並行してデバッガーの使い方を早めに覚えるべき理由を整理します。

以前に公開した「プログラミング言語よりも先にデバッガーの使い方を覚えよう」を、今の考え方に合わせて整理し直した内容です。

実務では、新しいコードを書く時間だけでなく、既存コードを読み、原因を調べ、影響範囲を確認する時間が長くなります。文法を知っていても、実行中の値や処理の流れを確認できなければ、知らないコードを理解するのは難しいです。

デバッガーを使う目的は、バグを直すことだけではありません。コードが実際にどう動いているかを確認し、推測を事実に置き換えることです。

まず覚えたい4つの機能

最初からすべての機能を覚える必要はありません。まずは次の4つで十分です。

• ブレークポイント
• ステップ実行
• 変数の確認
• コールスタック

ブレークポイントは、指定した行でプログラムを止める機能です。止めた時点の値、どの分岐を通ったか、どこから呼ばれたかを確認できます。

ステップ実行は、処理を少しずつ進める機能です。メソッドの中に入る、次の行へ進む、呼び出し元へ戻る、といった操作を使い分けます。

変数の確認では、引数、戻り値、フィールド、条件式の値を見ます。「この値のはず」と考えるのではなく、実際の値を確認することが大切です。

コールスタックは、現在の処理に至るまでの呼び出し履歴です。問題の行だけでなく、なぜその行に到達したのかを追えます。

コールスタックで呼び出し元を確認する

例えば、thirdMethod にブレークポイントを置くとします。

public class CallStackExample {
    public static void main(String[] args) {
        firstMethod();
    }

    public static void firstMethod() {
        secondMethod();
    }

    public static void secondMethod() {
        thirdMethod();
    }

    public static void thirdMethod() {
        System.out.println("ここで停止します");
    }
}

停止したとき、コールスタックにはおおむね次の順番が表示されます。

thirdMethod
secondMethod
firstMethod
main

これを見ると、thirdMethod がどこから呼ばれたかを、コード全体を検索せずに把握できます。

既存システムでは、同じメソッドが複数の画面やバッチから呼ばれていることがあります。想定外の経路で呼ばれていないかを確認するには、コールスタックが有効です。

値がいつ変わったかを追う

デバッグでよくあるのは、「最終的な値はおかしいが、どこで変わったか分からない」問題です。

この場合は、値を設定するメソッドや代入箇所にブレークポイントを置きます。setterがあるコードなら、setterは有力な確認地点です。

public class User {
    private String name;

    public void setName(String name) {
        this.name = name;
    }
}

public class Main {
    public static void main(String[] args) {
        User user = new User();
        updateProfile(user, "Taro Yamada");
    }

    public static void updateProfile(User user, String name) {
        user.setName(name);
    }
}

setName で停止すると、次を確認できます。

• 渡された name は正しいか
• User は想定したインスタンスか
• どの処理が setName を呼んだか
• その呼び出しは想定した操作経路か

値がおかしくなった後の処理を追い続けるより、値が変わる境界で止める方が調査範囲を狭めやすくなります。

ただし、頻繁に呼ばれるsetterに無条件のブレークポイントを置くと、何度も止まって調査しにくくなります。その場合は、特定の値のときだけ止める条件付きブレークポイントを使います。

デバッガーを使ったコードリーディングの進め方

知らない機能を調べるときは、最初からすべてのコードを読もうとしない方が進めやすいです。次の順番で確認します。

1. 画面操作、API、バッチなど、調べる入口を1つ決める
2. 入口または重要な分岐にブレークポイントを置く
3. 引数と条件式を確認する
4. 処理がどのメソッドへ進むかを追う
5. 値が変わる地点と外部連携の境界を確認する
6. コールスタックで呼び出し元に戻る

例えば「保存したはずの値が画面に反映されない」なら、次の順で見ます。

• ボタンのイベントは発火しているか
• リクエストには期待した値が入っているか
• サーバー側は値を受け取っているか
• DB更新時の値は正しいか
• レスポンスには更新後の値が入っているか
• 画面側の状態は更新されているか

一度にすべてを確認する必要はありません。値が正しい地点とおかしい地点の境目を見つけると、調査対象を絞れます。

文法学習だけでは埋まりにくい実務の差

学習用の小さなプログラムでは、自分が書いたコードを上から順に読めます。しかし実務では、次のような条件が重なります。

• コード量が多い
• 複数人が変更している
• 呼び出し経路が複数ある
• 設定やDBデータで挙動が変わる
• フレームワークやライブラリの内部処理がある

この状態で、コード検索と目視だけで原因を探すと時間がかかります。デバッガーを使えば、実際に通った経路とそのときの値を確認できます。

言語の文法は重要です。ただし、知らないフレームワークやレガシーコードに入ったとき、最初からすべてを理解する必要はありません。まず動かし、止め、値とコールスタックを見る。この進め方があれば、理解の足場を作れます。

生成AIを使うときにも実行時の情報が必要になる

生成AIにバグの相談をするときも、実行時の情報があると調査を進めやすくなります。

「保存できません」だけでは、候補が広すぎます。次のような情報があると、問題を絞り込みやすくなります。

• 再現手順
• エラーメッセージとスタックトレース
• 期待した値と実際の値
• 問題が起きる直前の分岐条件
• 正常に動くケースとの差分

これらは、デバッガーやログで確認した事実です。AIに原因を当ててもらうためではなく、仮説を検証できる材料を増やすために共有します。

AIの回答を試す場合も、修正前後でブレークポイントを使い、値と経路がどう変わったかを確認します。提案されたコードが動いたとしても、なぜ直ったかを説明できる状態にしておくことが重要です。

デバッガーを身につける練習方法

普段の開発で、次の練習を繰り返すと使い方が定着します。

1. 小さな処理にブレークポイントを置く
2. 実行前に、引数と戻り値を予想する
3. 実行して実際の値を確認する
4. コールスタックで呼び出し元を確認する
5. 予想と違った理由をコードで確認する

エラーが起きたときだけ使う必要はありません。正常に動く処理を追うと、ブレークポイントやステップ実行の操作に慣れ、異常時にどこを見ればよいかも分かってきます。

最初は、既存コードの一部を1つ選び、入力から出力まで追うだけで十分です。難しいバグを解くことより、実行中の事実を確認する習慣を作ることを優先します。

まとめ

デバッガーは、バグを直すためだけの道具ではありません。既存コードを読み、実行経路と値を理解するための道具です。

まずは、ブレークポイント、ステップ実行、変数の確認、コールスタックを使えるようにします。そのうえで、値が変わる地点や処理の境界を確認できるようになると、知らないコードでも調査を進めやすくなります。

プログラミング言語の学習と並行して、早い段階からデバッガーに触れておくと、コードを読む力、バグを調べる力、生成AIに状況を伝える力をまとめて伸ばせます。