プログラムのバグを減らすコツ
プログラムのバグを減らすコツ
2021年12月27日
プログラムのバグを減らすコツ
プログラムのバグ（不具合）の原因は色々あります。単純な記述の間違い（typo）から複雑なものまで色々あります。その中で、意識すると効果の高い物の一つを紹介します。
きちんと考えた処理は大抵動く！
プログラムで行なっている処理の中で、プログラムを設計した人がきちんと考えて作られた処理は多くの場合きちんと動作します。
例えば、要求されている機能に関しては殆どの場合動作します。それは、プログラムを書く人の頭の中に処理の流れ（フロー）がきちんとできているのが大きな理由です。 基本的にプログラムはこの流れに従って書かれているからです。処理するデータの変化のイメージもほぼ頭の中にあって、そのイメージを元にプログラムを書くので、そのイメージから逸脱しない限りは基本的に問題なく動くという事になります。
所謂、これが以前から何度かお届けしている「想定内」の動作です。
プログラムで行なっている処理の中で、プログラムを設計した人がきちんと考えて作られた処理は多くの場合きちんと動作します。
例えば、要求されている機能に関しては殆どの場合動作します。それは、プログラムを書く人の頭の中に処理の流れ（フロー）がきちんとできているのが大きな理由です。 基本的にプログラムはこの流れに従って書かれているからです。処理するデータの変化のイメージもほぼ頭の中にあって、そのイメージを元にプログラムを書くので、そのイメージから逸脱しない限りは基本的に問題なく動くという事になります。
所謂、これが以前から何度かお届けしている「想定内」の動作です。
問題は想定外の状況
上に挙げた理由で「想定内」の処理は多くの場合、きちんと動作します。
一方で、プログラムを書く人が想定していない動作に関してはバグを作り出す可能性が高くなります。当たり前ですが、「想定していない」ものをきちんと書くのは至難の技だからです。結構な場合、その「想定していない」場合の処理は、書かれていない場合が多いのです。
プログラムに書かれていない状況が起きた場合には、その後の処理がどうなるかわからない場合が多く、これが予想外の動作の原因に繋がる場合が非常に多くなっています。
上に挙げた理由で「想定内」の処理は多くの場合、きちんと動作します。
一方で、プログラムを書く人が想定していない動作に関してはバグを作り出す可能性が高くなります。当たり前ですが、「想定していない」ものをきちんと書くのは至難の技だからです。結構な場合、その「想定していない」場合の処理は、書かれていない場合が多いのです。
プログラムに書かれていない状況が起きた場合には、その後の処理がどうなるかわからない場合が多く、これが予想外の動作の原因に繋がる場合が非常に多くなっています。
想定外の状況がバグに繋がる理由
実は、想定内の処理でもバグは発生します。 しかし、想定内の処理のバグは、殆どの場合、プログラムを書いた人が行うテストで殆どの場合修正されるので、実際にバグとして残るケースが少ないので問題になりにくくなっています。
理由は簡単で、想定内の動作というのは基本的に求められている基本的な機能に関わる処理になります。こうした機能は、プログラムを書き終えた後で真っ先にテストされる機能になります。当然、プログラムを作成した人がほぼ確実に行うテストで、この機能に問題があれば、書いたプログラムを修正して問題を早期に解決してしまいます。
しかし、想定外の事項の場合は、テスト自体が行われないケースがどうしても多くなります。当然、すでに上で書いたように、コード自体がそうした状況に対応する物が存在しない場合が多くなります。加えて、想定していないのでテストをしていないケースも当然多くなります。そうすると、当然ですが、テストをしていないので問題点が発覚する事なく、プログラムがリリースされてしまう可能性が高くなります。
これが、バグとして利用者の問題となる場合が多くなっています。
実は、想定内の処理でもバグは発生します。 しかし、想定内の処理のバグは、殆どの場合、プログラムを書いた人が行うテストで殆どの場合修正されるので、実際にバグとして残るケースが少ないので問題になりにくくなっています。
理由は簡単で、想定内の動作というのは基本的に求められている基本的な機能に関わる処理になります。こうした機能は、プログラムを書き終えた後で真っ先にテストされる機能になります。当然、プログラムを作成した人がほぼ確実に行うテストで、この機能に問題があれば、書いたプログラムを修正して問題を早期に解決してしまいます。
しかし、想定外の事項の場合は、テスト自体が行われないケースがどうしても多くなります。当然、すでに上で書いたように、コード自体がそうした状況に対応する物が存在しない場合が多くなります。加えて、想定していないのでテストをしていないケースも当然多くなります。そうすると、当然ですが、テストをしていないので問題点が発覚する事なく、プログラムがリリースされてしまう可能性が高くなります。
これが、バグとして利用者の問題となる場合が多くなっています。
想定外を減らすコツ
そうなると、対策は想定外を減らせば良いという事になります。
もちろん簡単な対策ではありませんが、確実に想定外の項目を減らす上手い方法があります。
これも以前紹介した事ですが、プログラムの基本はデータの処理です。基本的にプログラムの処理は上から下に順番に行われます。例外はありますが、この基本に従えばこの処理の流れがシンプルに上から下に流れるようなケースは殆ど問題があります。
条件別に処理を行うためには「分岐」が必要になります。
プログラミングでは、この分岐は大きく分けて三つ程度の記述で書きます。
- if 文（if-else）で分岐させる
- switch 文
- ループを抜ける（for 文や while 分から抜ける条件）
があります。
プログラムを書く場合にこの条件に注意をすると想定外を減らす事ができます。
- 条件を全部書いているかを確認する
- if 文や switch 文で、「else」と「default」を必ず入れる
- ループを抜ける条件に関する検討
実は条件を全部書くというのは意外に難しいのですが、想定していない条件になることを知るだけでもデバッグのやり方は変わってきます。従って、「else」や「default」が発生したら、メッセージを出力するなど、わかるような仕組みを作っておくと想定外の事が発生したことがわかります。
その上で「ホワイトボックステスト」を行うとバグの早期発見が可能になります。
ホワイトボックステストは、プログラムで記述したすべての部分を実行するようにテストを行います。つまり、if 文で「else if/else」、switch 文では、全ての「case」と「default」を含めた全ての条件になるようなテストのケースを作って確認します。こうすることで、意図的に色々な条件を検討する事になるので、見落としを減らす事が可能になります。
勿論、これで完璧になる訳ではありませんが、色々な状況を考える機会を作ることになるので、想定外のケースは確実に減ります。
また、シンプルに１本の処理と思っている場合でも、想定外の条件がある場合があります。想定外の条件がある場合は、プログラムで暗黙のうちに行なっている仮定がある場合があります。そうしたケースをチェックすると想定外を減らす事ができます。
よくある仮定には以下のような物があります
- 計算に使用している数が「０」でない
- 使っている変数に値がない（初期化していない状態で利用）
他にも、値が負の値（マイナス）にならないなどもありますが、これはプログラムの処理を考えて個別に検討する必要があります。
上に挙げたケースは、基本的にプログラムの記述上のエラーになります。「０」で割るという計算は基本的にプログラム上はエラーになりますし、値を入れる（変数を初期化）する前にその変数を利用するのもプログラム記述上のエラーです。最近は、コンパイラや文法チェックのプログラムが発達しているのでこうしたエラーをチェックできる場合も多いですが、こうした項目を意識してチェックするだけで想定外のケースを防ぐ事ができます。
そうなると、対策は想定外を減らせば良いという事になります。
もちろん簡単な対策ではありませんが、確実に想定外の項目を減らす上手い方法があります。
これも以前紹介した事ですが、プログラムの基本はデータの処理です。基本的にプログラムの処理は上から下に順番に行われます。例外はありますが、この基本に従えばこの処理の流れがシンプルに上から下に流れるようなケースは殆ど問題があります。
条件別に処理を行うためには「分岐」が必要になります。
プログラミングでは、この分岐は大きく分けて三つ程度の記述で書きます。
- if 文（if-else）で分岐させる
- switch 文
- ループを抜ける（for 文や while 分から抜ける条件）
があります。
プログラムを書く場合にこの条件に注意をすると想定外を減らす事ができます。
- 条件を全部書いているかを確認する
- if 文や switch 文で、「else」と「default」を必ず入れる
- ループを抜ける条件に関する検討
実は条件を全部書くというのは意外に難しいのですが、想定していない条件になることを知るだけでもデバッグのやり方は変わってきます。従って、「else」や「default」が発生したら、メッセージを出力するなど、わかるような仕組みを作っておくと想定外の事が発生したことがわかります。
その上で「ホワイトボックステスト」を行うとバグの早期発見が可能になります。
ホワイトボックステストは、プログラムで記述したすべての部分を実行するようにテストを行います。つまり、if 文で「else if/else」、switch 文では、全ての「case」と「default」を含めた全ての条件になるようなテストのケースを作って確認します。こうすることで、意図的に色々な条件を検討する事になるので、見落としを減らす事が可能になります。
勿論、これで完璧になる訳ではありませんが、色々な状況を考える機会を作ることになるので、想定外のケースは確実に減ります。
また、シンプルに１本の処理と思っている場合でも、想定外の条件がある場合があります。想定外の条件がある場合は、プログラムで暗黙のうちに行なっている仮定がある場合があります。そうしたケースをチェックすると想定外を減らす事ができます。
よくある仮定には以下のような物があります
- 計算に使用している数が「０」でない
- 使っている変数に値がない（初期化していない状態で利用）
他にも、値が負の値（マイナス）にならないなどもありますが、これはプログラムの処理を考えて個別に検討する必要があります。
上に挙げたケースは、基本的にプログラムの記述上のエラーになります。「０」で割るという計算は基本的にプログラム上はエラーになりますし、値を入れる（変数を初期化）する前にその変数を利用するのもプログラム記述上のエラーです。最近は、コンパイラや文法チェックのプログラムが発達しているのでこうしたエラーをチェックできる場合も多いですが、こうした項目を意識してチェックするだけで想定外のケースを防ぐ事ができます。
まとめ
プログラムのバグは多くの場合、想定外の処理が原因になる場合が多くなっています。 想定外の発生の原因の多くは「条件の抜け」や「記述のミス」が原因になる場合が多くなっているので、条件分岐の記述方法や、想定外の条件が発生した通知をコード上に入れて工夫するだけでもかなり改善する事ができます。
この記事で紹介した方法は、プログラムを書く人を中心に考えた対策になりますが、実際には複数の人がチェックをすることで、抜けを減らす事ができます。人によって前提条件が違うのでプログラムを書いた人と別の人がチェックすると、その抜けが少なくなります。これが、テストは別の人があらためて行う理由です。
想定外の事が起こる大きな原因には、こうした人による前提条件の違いによるものが多くなります。特に注意をしたいのが、利用者がデータを入力できるようなケースでは、想定外のデータが入力される場合があります。そうした最初の入力データをきちんと想定内かどうかチェックするだけでも想定外の動作を減らす事ができます。例えば、数値を期待しているのに文字が入力されなどはよく起きる問題です。
プログラムのバグは多くの場合、想定外の処理が原因になる場合が多くなっています。 想定外の発生の原因の多くは「条件の抜け」や「記述のミス」が原因になる場合が多くなっているので、条件分岐の記述方法や、想定外の条件が発生した通知をコード上に入れて工夫するだけでもかなり改善する事ができます。
この記事で紹介した方法は、プログラムを書く人を中心に考えた対策になりますが、実際には複数の人がチェックをすることで、抜けを減らす事ができます。人によって前提条件が違うのでプログラムを書いた人と別の人がチェックすると、その抜けが少なくなります。これが、テストは別の人があらためて行う理由です。
想定外の事が起こる大きな原因には、こうした人による前提条件の違いによるものが多くなります。特に注意をしたいのが、利用者がデータを入力できるようなケースでは、想定外のデータが入力される場合があります。そうした最初の入力データをきちんと想定内かどうかチェックするだけでも想定外の動作を減らす事ができます。例えば、数値を期待しているのに文字が入力されなどはよく起きる問題です。
コメント
コメントを投稿