よくあるプログラミングの想定外とは？

よくあるプログラミングの想定外とは？

2021年12月30日

よくあるプログラミングの想定外

前回は、仮説を立ててプログラムのテストをすると良いと言う話でしたが、仮説を立てる場合でも、よくあるミスを知っていると効率よく仮説（＝テストケース）を考える事ができます。この記事では、よくある想定外のケースを紹介します。

基本は設計者が余り予期していない操作です

想定外の最も多いのは設計者が予測していない操作です。だから、想定外になるわけですが、良く起きるのも事実です。
例えば、渡すデータがない場合などです。そんな事あるの？と思うかもしれませんが、例えばファイルを入力データとして指定する場合を考えてください。入力に使うファイルを指定する方法はいろいろありますが、ファイル名をタイプして入力するようなユーザーインターフェースの場合、タイプミスをする事が考えられます。その場合、本来指定したかったファイル名とは別の名前という事になるので、ファイルが存在しないと言う事が考えられます。ファイルが存在しないので、ファイルからデータの取得はできません。
しかし、存在するファイルのリストを表示して選択するようなユーザーインターフェースにすると、上で挙げたような入力ミスは防げます。そう考えると、存在しないファイルを選択する可能性は低くなります。
いかがでしょう、上の説明だけを見ると、ユーザーインターフェースを工夫すれば、ファイルが存在しないと言う想定外のイベントも防げるように見えませんか？
実は、これでもファイルが存在しないケースは起こり得ます。
どう言う場合かというと、プログラムがファイルの一覧を表示するためにあるフォルダのファイルのリストを取得した後に、プログラムとは関係ない操作で、そのファイルが削除されたり移動する場合です。確かに可能性は低いと言えますが、起こる可能性はゼロではありません。コンピュータに保存されているファイルは、基本的に他のプログラムや操作の対象となる事は十分に起こり得るケースと言う事になります。
プログラムのテストには、このように重箱の隅を突くような考え方をする必要があります。
これ以外にも、フォームの一部のデータが空白になっているなども考えられます。

予期していないケースの処理はどうするか？

予期していないケース、上で挙げた例では、データがないケースですが、このような場合はその後の処理をすることはできません。処理するデータがないわけですから当たり前ですが、その場合はプログラムとしてどうしたら良いでしょうか？
一番良く使われる方法は、エラーメッセージや警告を表示すると言う処理です。俗に言うエラー処理と呼ばれる物ですが、一般的なのは利用者にメッセージで何がおかしいのか知らせると言う方法です。その上で、プログラムはデータが入力されるのを待つ状態にすれば、データ（ファイル）を用意して指定すれば、処理を再開できます。利用者はファイルが無いことや、指定されていない事を通知されるので、その部分を改めて処理をすれば良いのがわかるので対処ができるというわけです。
テストでは、こうしたケースを作って実際にエラーメッセージが表示されるかを調べるという事になります。設計者は通常こうしたエラー処理をドキュメントに残すのが普通なので、テストの担当者は実際の動作がドキュメント通りになっているかを確認します。しかし、こうしたエラー処理がドキュメントに記されていない場合は、動作がどうなるか設計者以外の人はわかりません。したがって、テスト担当者は、「この場合の動作が分からない」と言う事になるので、まずはやってみてどのような動作になるか確認する必要があります。その上で、実際の動作を確認してこれで良いのかを設計者に確認するという流れになります。キチンとエラー処理がされている場合は、その旨をドキュメントに書きます。プログラムが暴走したり、途中で固まってしまう場合は、そうした不具合を修正する事になります。
テストがキチンと行われると、こうしたドキュメント不備や不足が改善できます。

良くあるケースとは？

これまでに挙げた例は、「処理するデータがない場合」でしたが、これ以外にも良くある想定外のイベントには以下のような事があります。
意図していない型のデータが入力される
必要なデータが全て揃っていない（幾つかのデータがない）
想定していない順序の操作（処理）
以前のデータが残っている
データの範囲、大きさが違う
非同期で動作している処理がある
など、考えると結構ある物です。意図していない型というのは、本来は数値（整数や実数）であるべきデータが文字列になっている場合や、本来は三つのデータを渡すはずが、二つしか渡されていない場合。ある決まった順序で操作する前提で作っているが、利用者の操作のやり方によっては、別の順序での操作・処理が可能になる場合。続けて別のデータを処理する場合、以前処理したデータをクリアしてから行うのが普通ですが、例えば、前の処理を途中でやめた場合、前のデータが残っていて予期しない動作になる場合があります。データの範囲は、本来は正の整数であるべきデータが、負の数や「０」の場合などです。
また、Javascript などで多く起きる例ですが、一部の処理が非同期で行われているため、処理の順序が単純に上から下ではなく、必要なデータが準備できていない例なども良くある想定外です。

対策は？

では、どのようにこうした想定外に対応したら良いでしょうか？
幾つか対策がありますが、効果的な対策は
複数の人で検証する（設計者と設計者以外の人など）
想定外のケースを蓄積して次回の開発・テストに生かす（同じ失敗をしないようにする）
テストプランの標準化（想定外データを蓄積に近い方法ですが、実際のテストプランに反映させることで確実に検証できるようにする）
一言で言うと「経験を増やす」と言う事に他なりません。実は、プログラミングで経験者が優遇されるのは、こうした経験を積むことによって、想定外の出来事が減っていくからです。実際に、目的の機能が動作するプログラムはプログラミングの学習をすると短期間で書けるようになりますが、こうした想定外のケースは経験を積まないと中々カバーできない空です。誰が使っても「安定して動作する」プログラムに仕上げるには、検証を含めて経験がものを言うからです。

まとめ

プログラミングは一通り学習すると、機能の実現は比較的短期間で出来るようになります。しかし、想定外の操作を想定した「製品レベル」のプログラムに仕上げるにはどうしても、予め基本操作以外で起こり得るイベントに対応して行く必要があります。つまり、予め考えられる「予期しない操作」を想定してプログラムを作る必要があります。これには経験が必要で、これがプログラムの世界で経験者が優遇される大きな理由です。
こうした経験を積むには、自分でプログラムを使うだけではなく、他の人にも使ってもらって、実際に何が起こるかを知る必要があります。会社ではこうした機会が比較的たくさんありますが、フリーランスの場合は、実際の仕事（案件）以外では機会が少ないのが現実です。
そうした意味で、フリーランス間での情報の交換や経験の共有ができるとこうした分野でも短時間で成長していく事が可能です。
今年の投稿はこれが最後になります。新年は 1 月５日（日本時間）より再開します。来年もよろしくお願いいたします。

コメント