【机上デバッグの方法】ソースコードを読めると得られるメリット

机上デバッグをご存知でしょうか。机上デバッグとは、プログラムを実行してテストする方法ではなく、人間の目でコードを読んで、プログラムをテストする方法です。
机上デバッグができるようになると、テストデータの作成が不要で、バグを短時間で見つけやすくなります。

この記事では、机上デバッグの方法と、ソースコードを読めるようになると得られるメリットについて紹介します。

机上デバッグのメリット

  • テストデータの作成が不要
  • プログラムを実行しなくていい
  • 本番環境系のバグ原因調査時に効果を発揮

机上デバッグのメリットの1つは、テストデータの作成が不要だということです。
テストデータはテストケースごとに作成していく必要があり、プログラムが変わると入力するデータも変わります。テストケースの数だけデータを作成するのは少し面倒です。

簡単なコードであれば、テストケースを作成するだけでプログラムのテストを開始することができます。工数削減に繋がります。

メリット2つ目は、プログラムを実行する必要が無いということです。すべて頭の中で確認していくため、実行する必要がありません。

これは、本番環境系で発生したバグ原因の調査時に効果を発揮します。本番環境では本番処理用のデータでプログラムが実行されています。そこでバグが発生した際、プログラム実行で原因を突き止めていくには、関連するデータをすべてテスト環境にコピーしないと、テストができません。

一方で、不具合が発生したプログラムの直接的な入力データのみ取得し、机上デバッグで原因調査を進めていけば、高い確率でアタリをつけることができます。

机上デバッグのデメリット

  • 読み間違いの懸念
  • 読むコード量が多いと疲れる

机上デバッグは頭の中でシミュレーションして行うテストですので、読み間違いの懸念があります。

そのため、潜在バグがあると思われる場合、実際にプログラムを実行して確かめることが必要不可欠です。机上デバッグの結果だけで判断しないようにしましょう。

また、ソースコードの量が多いと、疲れます。そのため、ソースコードはできるだけ少なくしましょう。

目安としては、以下のとおりです。

  • プログラム1本あたりのソースコードの行数を、1,000行以下にする(ロジック部分)
  • 関数1つあたりのソースコードの行数を 100行 以下にする

また、ソースコードを読みやすくする方法としては、以下のような方法もあります。

  • 設定される値が想像しやすい変数名にする
  • 処理が想像しやすい関数名にする
  • 関数の中では、早めに Return して呼び出し元ルーチンに返してあげる

ソースコードを読みやすくする方法は、以下に書いていますので、参考にしてみてください。

ソースコードを読みやすくするためのアイデア

テストケース・テスト観点を決める

机上デバッグを始める前に、テストケース・テスト観点を決めましょう。

例えば、0件データがインプットされた場合、プログラムがどのような動きをするか確認する、という感じです。

テストケースは、単体テストのイメージで作成すればいいでしょう。

  • 0件入力
  • 1件入力
  • 境界値テスト・限界値テスト
  • 通常データ
  • 異常データ
  • C0/C1カバレッジを満たすデータ

机上デバッグでは、実際にはテストデータは作成せず、頭の中でデータをイメージして、頭の中でプログラムの実行をイメージします。

すべて頭の中でシミュレーションするため、データ作成や実行の手間が省けます。

決められたテストケースの視点でソースコードを読む

テストケースが決まれば、次はソースコードを読んでいきます。

1行ずつソースコードを読み、変数に何が入るのか想像します。最終的なアウトプットが出たら、想定したテスト結果と突き合わせ、正しいかチェックします。

この1行ずつソースコードを読んで変数に何が入るか想像する、という作業が、机上デバッグの根幹です。

すべて頭の中でシミュレーションしますので、かなりの体力を消耗しますが、プログラマーとして、自分のコードだけでなく、他人が書いたコードも読めるということはかなりのスキルアップにつながります。

ソースコードを読めるようになると得られるメリット

  • どこでどのような処理をしているか見つけやすくなる

ソースコードが読めるようになると、どこでどのような処理をしているのか、見つけやすくなります。

例えばGitHubなどのオープンソースリポジトリで、真似したいロジックを実装しているソースコードを見つけたとします。

しかし、そのソースコードがコードスニペットでない場合、システムとして動作するための他の機能が数多く実装されており、行数が多いはずです。

その中から、目的のコードを見つけ出すためには、ソースコードが読めるようになっていると早いですね。

開発環境を構築すればデバッグができるようになりますが、DLLやクラスなどの依存関係をすべて準備していては時間がかかります。

アタリをつけるだけでも、ソースコードが読めるとメリットが多いです。

コメント

タイトルとURLをコピーしました