🔍

デバッグで意識していること

に公開
it
idea

どこまでデータが来ているか確認する

データの流れを意識します。
例えば、データベースの接続より前で止まっているのか、データベースの接続完了後の値を渡すロジックで止まっているのかなどです。
どの処理で止まってしまっているのかを詳細に見ていきます。

「正常or異常」のどちらのルートを通っているか確認する

プログラムの処理で大きく分けると正常終了と異常終了があります。
どちらの処理を通ってエラーが吐き出されているのかを確認します。
ExcelのIF文に例えると・・・

  • 真の処理⇒正常終了
  • 偽の処理⇒異常終了

単純なプログラムに置き換えてみる

入力データが現在通っているルートのプログラムが複雑な場合、一部を修正して単純なロジックに置き換えてみます。
そうすることでデータの流れが見えやすくなります。

違う文法に変えてみる

使用しているメソッドがサポートされていないなどでエラーが生じることもあります。
ダブルクォーテーションだとエラーになるがシングルクォーテーションだと正常終了するパターンもありました。
動作しないなら別のアプローチをすることも大切です。

型を意識する

現在見ている変数の型が何になっているかに注目し、その型の渡し方などが合っているか確認します。
例えば、VBAではDATE型は#をつけたり、format()関数で定義してみたりします。
その他にも文字列型ならダブルクォーテーションが必要なケースがほとんどです。

エラーの原因だと思う部分を消してみる

エラーの部分の見当をつけて消してみます。
そこでエラーが解消すれば、今消した部分にエラーの原因があります。
プログラムの構成に必要な宣言文など一緒に消してしまわないよう注意です。

変数の中身をDISPLAYに表示してみる

変数の中身を見ることでどこまで正常にデータが流れているか確認できます。
それでエラーのキッカケが掴めることもあります。
オブジェクト型を表示させようとすると上手くいかないので注意です。

プログラムの構成に必要な宣言文を確認する

自分自身が組んだロジックだけに着目しがちですが、宣言文も確認します。
下記は一部の例です。

  • COBOLならDIVISIONの終了タグが消えていないか
  • SQLなら最後のカラムの後にカンマがついていないか
  • ダブルクォーテーションの閉じがあるか
  • 最後のセミコロンがあるか
    などです。

入力データが妥当か確認する

見当違いの入力データを入れた結果、データベースから値を取得できないケースもあります。
具体的には・・・

  • データ種別が1でしか登録されていないのに、データ種別7を指定している
  • 店番号123は存在しないのに、入力データとして指定している

俯瞰して見る

単体だとエラーになるが全体として見るとエラーにならないケースがあります。
上のプログラムでフィルターされてエラーの原因となるデータが落ちてこないケースなどです。
具体的には下記のようなケースです。

  • プログラムBには店番号123を処理するロジックがないが、上のプログラムAで店番号123はフィルターされるため落ちてこない

この場合、プログラムBの単体テストで店番号123を入れるとエラーになりますが、気にしなくて大丈夫です。

コンパイルしたか確認する

ソースコードを修正したが、コンパイルしていなくて最新になっていないことでエラーになることもあります。

自分と同じ状況の記事を参考にする

例えばTailwindCSSの適用についても下記の２つでは状況ややり方が異なります。

  • TailwindCSS単体でインストールする
  • Vue.jsにTailwindCSSを導入する
    まずは、自分の状況を考えることが大事です。

GREPしてみる

パスや関数名を置き換える際はGREPして全体のどこに対象箇所があるか洗い出しを行います。
文字列を変更することによる影響を調べることができます。
また、GREPは使われていない関数などを調べるのにも有効です。

ログを見る

エラーの手がかりを掴むのにログは非常に重要です。
ログの出力レベルを上げたり工夫しながらログと向き合います。
開発中だけでなく、運用中の突然の不具合対応などでも、まずはログを見ます。
ソースコードにいきがちですが、イレギュラーな操作が行われたのではないかと考えます。
ログがない場合はユーザーにどんな操作をしたか詳細に聞く必要があります。

エラー文はちゃんと読む

エラー文に問題解決のヒントがあることも多いです。
エラー文が出てこない時はログが出力されているファイルがないか探します。
エラー文は下記のメッセージと一緒になっていることがあります。

  • Exception
  • Caused by
  • Error

新旧コンペア

動くコードと動かないコードを比較することで見えてくるものがあります。
また、ドキュメントも同様にAIが生成したコードと、ネット記事に公開されているコードを比較し差分を見ることで、信頼性も評価できます。
さらに、手順書のやり方と自分のやり方を比較と差分を意識して見るとミスに気がつきやすいです。

既存の関数にも目を通す

リプレイスなどで処理内容や処理順序を大きく変更したりすると既存の関数でも想定外の動作になることがあります。
そのため、既存の処理がどんなロジックなのか目を通すことも重要です。

依存関係がすべて入っているか確認する

プログラムや入力データが揃っていても下記のようなことが原因でエラーになることもあります。

  • 依存関係やリソースがまだまだ足りていない
  • ビルドしていない

0件やnullの可能性があるか確認する

戻り値が必ず値を返すのか、もしくは返さない場合があるのか確認をします。
0件やnullの可能性があるのならセーフティーを入れる必要があります。
0件やnullだった場合、その行をスキップするのか、全体の処理自体をエラーにするのかも考える必要があります。

最後に（落とし穴）

完璧にプログラムを組んだと思っていても想定外の出力になることがあります。
そのような場合、下記のようなこともあります。

  • ソフトウェアの設定
  • 入力データがIF文やINCLUDE文でフィルターされ弾かれている
  • 横にスクロールしてみると文末にゴミがある
  • 決まり文句宣言文のミス
  • 修正したものの最新のファイルに置き換え忘れている

Discussion