Firebaseでバグ対策！？

Firebaseでバグ対策！？

Firebaseの話を中心にお届けしていますが、今日はバグの話です。 WebサービスやWebアプリに限った話ではありませんが、ソフトウエアには「バグ」はつきものです。

設計通りに動作しない設計上の不具合を「バグ」と呼んでいますが、恐らくバグのないソフトウエアはないと言われるくらい全てのバグ（不具合）を無くすことはほぼ不可能に近いと考えられています。

この記事ではソフトウエアのバグについて考えてみました。

バグの分類

最初にどんなバグ（不具合）があるかを考えてみます。

最初にここでお話するバグ（不具合）は、プログラムの文法上のミスは含みません。ソフトウエアをコンパイルする際の文法のチェックなどで見つかるものは、基本的にはプログラムの書き方上で間違った書き方をしているものなのでここでは別の問題として扱うことにします。

それ以外のバグは幾つかの種類に分けることができます。

大きく分けると以下の２つに分類できます

＊　プログラムの論理（ロジック）のエラー（間違い）

＊　想定外の動作による不具合

プログラムの論理（ロジック）のエラー（間違い）

簡単に言うと思った通りの動作をしない場合です。現在主流のコンピュータは、「プログラム」と呼ばれる処理の手順を書いたものを実行することで必要な仕事をやっています。

この手順が間違っていれば、想定した結果は得られません。

コンピュータがやっていることは、簡単に言えば3種類に分けられます

＊　計算 / 計算結果の評価（チェック）

＊　分岐

＊　処理結果の出し入れ

の３つです。

このそれぞれで間違いがある可能性があります。

計算　／　計算結果の評価（チェック）

足し算や引き算のような数値の計算から、条件の判定（論理）などのデータ処理をここでは「計算」としてまとめています。実際の計算は、計算を行う装置（CPU）のハードウエア（チップ）に問題がない場合は、計算結果自体は正しいと考えることができます。

しかし、元の式が間違っている場合は、期待した処理と違う結果がでます。例えば、本来は足し算をしなければいけないのに、引き算をしていたりする場合です。

計算だけではなく、計算結果を評価したりすることも一応計算の一種として考えます。

いずれにしても、式や計算結果の扱いが間違っていてもプログラムの文法上に問題がなければ、プログラムは動作します。コンピュータは言われた事をやるだけなので指示が間違っている場合は、間違った結果を出すという事です。

分岐

コンピュータの処理は、いろいろな処理の「流れです」この流れは基本的には順番に行うのですが、処理結果などの条件によって、同じような処理を繰り返したり、結果や条件によって違う処理を行ったりします。そうした処理の流れをコントロールしているのが「分岐」です。

この分岐を決める条件の設定や分岐先が正しくない場合は、当たり前ですが期待された結果になりません。

処理結果の出し入れ

処理するデータや、処理した結果をどこかに保存する必要があります。 これは、コンピュータが処理できるデータは限られていて、処理していないデータは別の場所に置いておく必要があるからです。処理のやり方（流れ）は正しくても、処理するデータが違っている場合期待した結果が出ないのも当然ですよね？

処理したデータを間違う大きな原因は、データを取り出したり、保存する場所を間違えてしまう場合に多く起きます。

想定外の動作による不具合

別のタイプのバグ（不具合）としてよくある問題がこの、想定外の動作をした場合の不具合です。 想定していないので、それが起きた場合何が起きるかわかりません！

東日本大震災で原発の事故があった時によく耳にした言葉ですが「想定外」というのが曲者です。

想定されていないので、実際にそれが起きてしまうと何が起きるかわからない場合が多く厄介な問題を引き起こす場合が多くなります。

バグの見つけ方

機械学習などを活用した、AI技術などを応用してソフトウエアを検証する方法もあります。そうした新しい検証によってバグを事前に見つけて対策を取ることは可能になってきています。

しかし、この記事では自分で書いたプログラム（ソフトウエア）をいかにバグの少ないものにしていくかを考えて行くことにします。

最初に、「プログラムの論理のエラー」ですが、これは比較的簡単に検証できます。

要するに、想定した「機能」の試験を行えば殆どのこのタイプのバグは見つけることが可能です。 もともと、プログラムは「機能の実現」のために書かれているので、その機能が想定通りに動作するかをテストすれば、必要な機能が想定道理に動いているかは検証できるというのはお分かりになるかと思います。

特に、設計者（プログラムを書いた人）は一連の動作の流れ、データの流れはよくわかっているので、頭で描いたように動いているかをチェックするのは比較的簡単です。あとは、機能に漏れがないように、体系立てた検証（テスト）計画を立てて、それを順番に実行していけば検証は可能です。

この検証（テスト）は、時間をかければ基本的に１００％近い検証が可能な分野です。必要な機能を細部までリストにして一つ一つ確認する作業をすれば、かなりの確率で「普通に使った場合」の不具合は発見できるといえます。

難しい「想定外」の検証

バグを完全に無くすことができない大きな理由は、「想定外」の使われ方です。

実は「想定していない」事をテストするのは非常に難しいからです。実はテストするには「想定」する必要があるからです。特に設計者や実際にプログラムを書いた人には難しい検証になります。

多くの設計者は、ある「仮定」の元に、必要な機能をプログラムとして実装します。当然、想定した通に使えば、期待通りの結果になるように作るので、多くの場合はきちんと動作する場合も多くなります。また、期待通りの動作をしない場合でも、検証が簡単にできるので不具合を発見することも比較的簡単です。

これが、設計者以外の人も検証に参加させる大きな理由です。設計者自身が気づかないようなケースでも気づいてテストできる可能性が増えるからです。

例えば、自動販売機を設計する場合です。自動販売機で使うお金は、日本に設置する場合は普通の人が考えるのは、「日本のお金」を入れて使うと考えるのが普通です。ところが、実際には外国のお金を入れる場合や、お金に似た形状の物を入れる可能性はあります。

例えば、日本のお金以外の物を入れたらどうなるのか？想定している場合は、ある程度予測されているので対策を立てることができます。

この場合考えられる動作は

＊　日本の形状の似たお金と誤認して動作

＊　お金は受け付けるけれども返金は不可能

＊　お金を受け付けずにそのまま返金

＊　詰まって使えなくなってしまう

など他にもあるかもしれませんが、考えられることがいくつかあります。

この中で、「使えなくなってしまう」は問題です。しかし、事前に可能性に気づいていれば、ある程度対策をして不具合を事前に防ぐことも可能です。しかし、事前に気づかずに検証もされない場合は問題が大きくなるまで放置される可能性もあります。

想像力を鍛える！

ある程度プログラミングの勉強をすれば、誰でもプログラムを書くことはできるようになります。しかし、プログラマーやエンジニアの実力は以下に「想定外」を減らすかが実は重要です。

経験者が優遇される一つの理由は経験により、よく起こる「想定外」を知っている場合が多く、事前に対策を取れる可能性が高くなる事も大きな要因です。

未経験者はその経験や知識が少ないので、その部分を「想像力」でカバーする必要があります。

これをカバーできるかできないかでその、評価は大きく変わってきます。

実は「コツ」があります

これは、利用する人、使う人をよく見るとよく知る事です。 プログラムをする場合、どうしてもプログラムに目が行ってしまいますが、大切なことは実はプログラムではなくて、それを使う利用者です。その人たちが、どのようにそのプログラムを使うか、なんのためにつかうか、どんな人が使うかを考えたり見るようにすると、そうした「想定外」の使われ方も見えてくるものです。

そうして、その一つ一つに対策を考えてプログラムを作ることが実は大切です。

まとめ

プログラムのバグはいろいろな原因があります。しかし、想定した機能が動かないようなバグはきちんとテストをすると大抵のものが見つかりますし、事前に修正できる場合がほとんどです。

厄介なバグは、「想定外」で起きる不具合です。

どうしても検証（テスト）から抜けやすい想定外の問題はなかなか事前には対策ができない場合が多くなります。多くのバグの正体はこの「想定外」の問題です。

こうしたバグに立ち向かうには、設計者（プログラマ）が利用者目線で実際の使われる様子を想像して作ることが一番大切です。どうしても、プログラムに目が行きがちになりますが、見るのは利用者です！

Firebaseとは直接関係のない話ですが、Firebaseを使うと想定外も減らすことができます。多くの人が医療しているパッケージは、いろいろな人が既に使っているので、多くの想定外が既に対策されている場合が多いからです。実装は簡単そうでも、想定外を潰すのは思っているより大変です。そう考えると、既存のパッケージの利用はフリーランスにはありがたい武器になります。