【体当たり開発】5分悩んで手がかりが無いなら全行にデバッグ文を仕込む

大丈夫かなこんなタイトルで。他のプログラマに怒られそうな気もしますが、初心者向けの泥臭いデバッグ方法を紹介します。

ある程度慣れてきている言語でのプログラミングでは、どの変数にどんな値が入っているのか見当がつきます。しかし、あまり慣れていない言語だと、どこがどうなっているやら、よく分からないんですよね。

慣れている言語であっても、他の人が書いたコードだとこれまた内容を掴むのに時間がかかったりと、変数の中身がイメージしづらいことがあります。

しかもだいたいその中でエラーが起きてしまって、どこから手をつけていいか分からなくなり、途方に暮れることも……。

そんな時には初心に返った体当たりデバッグがおすすめです。

1. ソースコードのバックアップを行う
2. ログファイルに出力があることを確かめる
3. 全部の変数の中身をログに出力する

の3ステップです。ね？　簡単でしょ？

前提 : スタックトレースはちゃんとみようね

これから紹介する体当たりデバッグはヒントが無い場合のデバッグ方法です。ここではUnityを想定して記事を書いていますが、Unityではエラーがあった場合には多くの場合コンソールにメッセージが出力されます。このとき、エラーの起きた箇所だけでなく呼び出し元の情報も出ているので、その辺りから追っていくと良いでしょう。

このようなヒントが全然見つからない場合は変数の中身を追っていくのが簡単なので、今回の体当たりデバッグを使ってみてください。慣れたらデバッガを使ってステップ実行してみるのもおすすめです。

UnityとVSCodeでブレークポイントを設定して変数の中身を確認する方法については以下の記事で紹介しています。

エクスプラボ

 

1 User

2 Pockets

UnityとVSCodeでブレークポイントを設定して変数をチェックする

https://ekulabo.com/unity-break-point

IDEやコードエディタに搭載されているデバッガーの機能を使ってステップ実行していくことでゲームのシステムの中身が把握しやすくなります。この記事ではブレークポイントを設定してその時点での変数の中身を確認する方法を紹介しています。

体当たりデバッグ

体当たりデバッグとは、その名の通り泥臭く全部の行にデバッグ文を仕込んでおかしな箇所を特定するデバッグ方法です。ヒントがなくてどこから手をつけていいか分からない時には、カッコよく修正するのを諦めて変数の中身を全部コンソールに出力しちゃってください。

問題を解決する場合は、問題が起きている箇所を特定するのが先決です。多くの場合、変数に想定していない値が入っているので、出力された値をもとに修正を行えばOKです。

ここから冒頭に紹介した3つのステップを詳しく解説します。

1.ソースコードのバックアップを行う

ソースコードの中にデバッグ文を仕込むので、ファイルのバックアップは必ず保存しておきます。

自分ではそんな意図はなくとも、マウスが急に跳ねたりして必要な処理まで消してしまい、焦って戻せなくなることもあるためバックアップは大切です。

多くの場合はGitなどでバージョン管理しているかと思いますが、初心者のうちはここまで手が回っていないこともあるかもしれないので、シンプルにスクリプトファイルをバックアップするのが簡単です。

2. ログファイルに出力があることを確かめる

デバッグ文を仕込んで、その文字列が意図した通りに出力されることを確かめます。

Unityだったらちゃんとコンソールにメッセージが出力されることを確かめましょう。

3. 全部の変数の中身をログに出力する

ここが一番の体当たりポイント。変数の中身を全て確認します。(「全行にデバッグ文」は盛りすぎでしたね。すみません)

UnityだったらDebug.Logをしこたま記載します。

そしてゲームを実行。出てきたメッセージを順番に確認していきましょう。

こういう泥臭いやり方は嫌いだ！というプログラマもいますが、これをやると一発でおかしい場所がわかります。

変数の中身をコンソールに出力する場合は、変数名も一緒に出力するようにしましょうね。変数の中身だけ出力されても「1」みたいに何の数字か分からないことが多いのです。

以下の例では$を使って文字列補間を使っています。慣れているなら「+」を使って文字列連結しても大丈夫です。問題が起きている箇所を特定するのが目的ですからね。

文字列補間についてはMicrosoft社のドキュメントもご参照ください。

docs.microsoft.com

C# における文字列補間

https://docs.microsoft.com/ja-jp/dotnet/csharp/tutorials/string-interpolation

C# の文字列補間を使用した結果文字列に書式設定された式の結果を含める方法について説明します。

トラブルシューティングの基本

何か問題が起きた時にそれを解決することを「トラブルシューティング」と呼びます。略して「トラシュー」とも呼ばれます。

当たり前っちゃ当たり前なんですけど、今どこで問題が起きているのかを確認するのがトラブルシューティングの基本なので、こうした情報収集を真っ先にやるようにしてください。

昔、会社の研修でトラブルシューティングの講座を受けたときの話ですが、マシンがネットワークにつながらないトラブルがありました。同期みんなであーでもない、こーでもないとPCの設定を確認しながら頭を捻っていたのですが、実はネットワーク機器のコンセントがいつの間にか講師によって外されていた、なんてことがありました。

このケースでは、まず機械に電顕が入っているか？　という基本中の基本から確認することの大切さを学んだわけですが、1つ1つ問題が起きそうな箇所を潰していくのがポイントです。

思わぬところでトラブルが起きていることがあるので、問題が起きていないことを確認する意味でも、デバッグ文を仕込んでいくのは有効です。

事象がはっきりと分かれば解決策を探すのも用意ですからね。

ググってから答えにたどり着くまでの早さも変わってきますよ。

まとめ

なにかエラーが起きているけど、全然手がかりがない！　とお嘆きの場合は、泥臭く全部の変数の中身をコンソールに出力しましょう。どこで問題が発生しているのかが分かれば解決までの時間も早くなります。

頭の中だけで解決するのは結構大変なので、手を動かして情報収集するのも時には大切です。