VB のたまご

作成日: 2017/07/26, 更新日: 2017/07/27


泥だらけのコールツリー

  •  あまり詳しくないソースコードを理解しなければいけなくなった時には、 クラス構造(クラス内に定義した公開メンバー)と、処理構造(メソッドの処理内容、呼び出し順序(コールツリー)など)をたくさん覚えて、処理の流れを読み取らなくてはいけません。 あ、その前に、ターゲットのプログラムがどういう動き方をするのか、実際のプログラムを動作させてみたり、仕様書を見て、あらかじめ把握している必要がありますね。

  •  最低限、仕様を知っていないと、デバッグしてステップイン・ステップアウトしながら1行ずつ読み進めても、 あっちに飛んだりこっちに飛んだり...を眺めていても、頭の中がごちゃごちゃでいっぱいになるだけで、理解へのステップが1つも進んでいないのでは?と感じてしまいます。 (「0」だったのが「意味不明だ、逃げたい」に変わっただけ?)。 つまり、【メソッドを追う作業】が一番ネックなのではと見ています。

  •  どうすれば、この【理解するための作業】を楽してパスできるのか、あまり疲れずに攻略できるのか、考えてみました。 本記事は例によってネタの位置づけですが、もし自分に合ってそうだなと思われた方はトライしてみてください。 逆に分かりづらいわー!と思われた方は見逃してください。

  • スポンサーリンク



思いついたアイディアを説明するための前振り

  •  よくバグ調査する際、古くからある調査方法で、print 出力(.NET 的には、Console.WriteLine, Debug.WriteLine, File.Write ~系)するやり方があります。 バグ発生している場所の可能性の範囲を、少しずつ狭めていく方法ですね。 どこまで正常に動作しているのか、どこで例外が飛ぶのか、どのデータがおかしいのか、を見るために使います。 ついでに言うと、Visual Studio 経由でのデバッグができない場合にも有効です。

  •  メソッド名なり何らかの目印なりが出力タブなどに表示されれば、そこが通った=OK、通っていない=NG、とか、 出力されたデータの値がおかしいな、とか、モニタリングしながらの調査方法です。

  •  ただし、製品コードを書き換える必要がある、実行ファイルを差し替える必要がある、という煩わしさがあり、 あまりやりたくない、積極的には乗り気しない調査方法でもあります。 まあ、それは置いておいて。

  •  ポイントは、【メソッド定義内に、メソッド名を出力する処理】を書くことで、実行時に【実行中の処理順序順に、メソッド名が出力される】という特徴です。 これって、コールツリーとか呼び出し履歴とか言われるやつです。 一番身近な例では、例外発生した際 Try-Catch 句で捕まえた例外を ex.ToString() した時に逆順でメソッドの呼び出し履歴が表示されますが、あれな感じです。 これを利用すれば、実行時に何のメソッドを通ったのか、後からじっくりメソッド呼び出し順序を確認することができます。

  •  理解する方法はいろいろあると思いますが、メソッドの内容をじっくり見ながら、同時に新たな呼び出し履歴を追うのは大変です。 まずは、メソッド内容は知らなくていいからメソッドの飛び先順序だけを追う、これを繰り返して見慣れる。 この時、あっちこっちに振り回されるのではなく、事前に飛び先の情報を知っておく、そのために print 出力を利用する。というわけです。


思いついたアイディア

  •  【メソッドを追う作業】をする際、以下のように「ある処理」をした場合に、呼び出された全メソッドが表示してくれれば、分かりやすいんじゃないかと考えた次第です。 WinForms なアプリケーションでは、「ある処理」は、ほぼイベント処理の事です。

  •  デバッグで、ステップイン・ステップアウトしながら、処理を追うのもいいですが・・・

  • イメージ
  •  横並びで、メソッド呼び出しの流れが横断できると、見やすい・理解しやすいのでは(→ ソースタブ間の行ったり来たりが無いから)。

  • イメージ
  •  print 出力をすると実行時のメソッド履歴(コールツリー)が分かるので、処理を追いやすい。 しかし、製品コードを修正しなければいけなくなる(汚れてしまう、再テストしないといけない?)。

  •  この2つを攻略するため、以下の構成を考えました。

  • イメージ
  •  オリジナルソースはそのまま変更せずに、調査用処理を組み込んだソースでコールツリーを作成します。 出力処理のみを追加した修正なので、既存処理への副作用的な影響は無いはずですが、謎の2次災害による影響が出ないとも限りません。 こればっかりは致し方なしでの前提です。多分無いと思うのですが。

  •  出力処理には、メソッドを通過した時の時刻、ソースファイルのパスやメソッド定義の行位置情報などを含めておきます。 調査用プログラムを動かすとテキストファイルが出力されるので、そのテキストファイルを簡易ビューアで読み込んで、コールツリーを確認します。

  • イメージ
    スポンサーリンク



作成したプログラム

  •  上記を実現したソース一式を GitHub に上げています。 一応内部資料と、ビルド済みの実行ファイルも含めています。
  • https://github.com/sutefu7/DebugTools
    


本当に楽になったか検証

  •  私の独断と偏見な意見なので参考にならないと思いますが、使ってみての感想として、 (良い)メソッドを横断して同時に診れるのは分かりやすい、(悪い)Visual Studio ならマウスオーバーすると説明が表示されるのに、表示されない。 という感じです。

  •  エディタコントロールには、Azuki コントロールを採用させていただきました。 WinForms で使える素晴らしいエディタコントロールです。

  •  でも、正直、このエディタが Visual Studio 相当な機能だったらな、と欲張ってみました。 欲しいならソースは公開されているので自分で改良すればいいのですが、ヘタレなので妥協しましたorz。

  •  目が悪いので、各コントロールの背景色をダークな色合いに切り替える機能を付けたいし、目が悪いので、エディタのフォントサイズの切り替え機能も付けたいし、 まだまだ改良の余地ありです。

  •  最後までこの記事を読んでいただき、ありがとうございました。

  • スポンサーリンク