今日の知見

Toshが諸々で得た知見を雑に書きます。

2019年1日目: Tosh式(というほどでもない)デバッグ法

始めに

遅ればせながら、あけましておめでとうございます。
今年こそはブログを継続しようかと存じておりますので、何卒何卒。
※どうせ三日坊主なのでタイトルのナンバリングを変えてみました

ブログを再開した事の発端は業務中にメンバーから「(デバッガの使用方法などではない)デバッグ方法を教えてほしい」と言われたはいいけれどうまく答えられなかった・・・というものです。

なので、今回はToshが日ごろ行っているデバッグ手順を整理してみようかと。
経験者からすればごく当たり前のことと存じますが、お付き合いいただけますと幸いです。
(長くなりますので、「ノーサンキューだ!」という方は今すぐyoutubeにでも)

前提条件

Webフレームワークの使用を想定しておりますが、GUIのアプリケーション全般に応用できるように心がけます。

デバッガを使わないデバッグ

正直無意識にやってますが、大体下記の手順を踏んでるかと。
デバッガがあれば変数の中身を調べる際にデバッグ用のコードを埋め込まなくてよく、
楽にステップ実行できるのですが・・・orz

  1. エラーとなる箇所の直前にデバッグ用のコードを埋め込み、変数の中身を調べる
    • 慣れてる人はここで原因が判明する
  2. 変数の中身から仮説を立て、整理する
    • この段階でおおよそ見当がつくようであればその部分を中心に調べる
  3. 遷移先のページに対応する受け口となる処理を探す
  4. 上記の処理からビジネスロジックに該当する処理への流れを把握する
  5. ビジネスロジック上でデバッグ用のコードを埋め込み、変数の(以下略)
    • おおよそここで原因が判明する
  6. ビジネスロジック上で原因が判明しない場合、遷移先のページを表示する直前にデバッグ用のコードを埋め込み(以下略)
  7. それでも原因が判明しなければ画面上で何かしら処理しているはずなので、デバッグ用のコードを(以下略)

地道極まりなくて申し訳ございませんが、順を追って説明させて頂きます。

1. エラーとなる箇所の直前にデバッグ用のコードを埋め込み、変数の中身を調べる

まずはエラーなどの不具合が発生している箇所がどうなっているかを調べます。

具体的にはその部分で使用されている変数(ローカル変数、インスタンス変数、環境変数など)をつぶさにチェックします。

ここでしくじれば泥沼にハマるのでご注意をorz

2. 変数の中身から仮説を立て、整理する

変数名から変数の中身から「この部分にはこのデータが入るはず」などという仮説を立て、整理します。

慣れてる方であれば仮説を立てずにほぼ解決しますが、デバッグに慣れてない方は

  1. 調査
  2. 仮説 (← 今ここ)
  3. 検証
  4. 再調査

という流れを意識すると手早く正確にデバッグができるようになると存じます。

3. 遷移先のページに対応する受け口となる処理を探す

Webフレームワークでいうコントローラ、GUIアプリケーションでいうイベント処理を画面名やURLなどから判断し、デバッグ用のコードを埋め込みます。

もし埋め込んだコードが実行されなければやり直しですorz

4. 上記の処理からビジネスロジックに該当する処理への流れを把握する

3.の処理から他のメソッドやビジネスロジック(WebフレームワークでいうModel)などを読んでいるかと存じますので、メソッドの呼び出しや返り値の流れを大まかに確認します。

5. ビジネスロジック上でデバッグ用のコードを埋め込み、変数の(以下略)

エラーの原因の大半はビジネスロジック上で起きるので(※Toshの体感上)、ここでの変数の状態を確認すればほぼ解決します。

6. ビジネスロジック上で原因が判明しない場合、遷移先のページを表示する直前にデバッグ用のコードを埋め込み(以下略)

5.と同様ですが、ビジネスロジックが処理される気配がなければここは「ビジネスロジックに入る前に(以下略)」となります。

7. それでも原因が判明しなければ画面上で何かしら処理しているはずなので、デバッグ用のコードを(以下略)

5.や6.と同様ですが、具体的にはWebフレームワークでいうViewに相当する部分で行います。

最後に

慣れてなければ「どういったものが各々の変数に入るべきか」というものを判断するのは難しいと存じますが、こればかりは自分で場数をこなすか先輩方に伺うか以外の解決法を思いつきません・・・(;´Д`)

あと、Toshは「ビジネスロジック→遷移先の画面」という流れでデバッグしますが、「遷移先の画面→ビジネスロジック」というやり方もあります。
その辺は好みによるかと。

ユニットテスト(xUnit)を自分で組むと変数の中身やメソッドの呼び出しを意識せざるを得ないので、
デバッグを手早く済ませたい方はユニットテストに触れてみることをお勧めします。

ちなみにToshはJUnitPHPUnitを扱いますので、必要とあればどこかの機会にまとめます。

ではでは、ここまでお付き合い頂きありがとうございました(/・ω・)/