バグ検出ドリル（17）「よくある単純なバグ」だからこそ見つけにくい：山浦恒央の“くみこみ”な話（117）（1/3 ページ）
バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第17回の問題は、前回と同じ音楽プレーヤーのプログラムから出題します。「よくある単純なバグ」が潜んでいますが、見つけ出せますか？
1．はじめに
本連載では、エンジニアのバグ検出力の向上を目指し、バグ入りの問題を出題して読者のみなさんに見つけていただいています。気楽な気持ちで問題に取り組み、明日のソフト開発つなげてください。
2．前回の訂正
前回は、音楽プレーヤーを題材に出題しましたが、問題文に誤りがありました。問題文では、「リスト2に示す通り、本来は、再生モードで停止指令を出すと、アイドルモードに遷移するはずが、再生モードのままとなっている。なぜ遷移しないか、推察せよ」と書いていますが、間違いがありました。実際にリスト2の実行結果⑤を見ると、「⑤再生モードで、「1（再生指令）」を入力、Enterを押し、一時停止モードに遷移するはずが、再生モードのままとなっている」となっており、問題文と一致しません。以下のように訂正いたします。
- 誤：リスト2に示す通り、本来は、再生モードで停止指令を出すと、アイドルモードに遷移するはずが、再生モードのままとなっている。なぜ遷移しないか、推察せよ。
- 正：リスト2に示す通り、本来は、再生モードで再生指令を出すと、一時停止モードに遷移するはずが、再生モードのままとなっている。なぜ遷移しないか、推察せよ。
本シリーズでは、まず大枠の題材を決め、仕様、プログラム、実行結果などを少しずつ修正して、作成しています。プログラムは修正したのですが、問題文を修正し忘れてしまいました。「プログラムは修正したが、仕様に反映していない」という典型的な思い込みのバグでした。掲載前に十分、確認すべきでした。問題にチャレンジいただいた方には、大変申し訳なく思います。修正版自己採点シートを以下に示します。
| 問題 | 内容 | 配点（点） |
|---|---|---|
| 音楽プレーヤープログラム | 問題を一通り読んだ | 30 |
| 問題と実行結果の食い違いに気が付いた | 20 | |
| 正しく代入処理をしていないバグを見つけた | 50 | |
| リスト3（前回のリスト番号） 自己採点シート | ||
3．単純バグはなくならない
コンピュータは、人間が一生かけてもできない高速な処理を実行できますが、バグなしでプログラミングするのは非常に大変です。コンピュータは人間と異なり、プログラマーの指示通りしか動作しないため、バグにより想定外の動作をします。
バグが発生すると、標準出力やログなどからエンジニアは何が原因なのか推察します。バグを探している最中は、事象は複雑なので、広範囲で大掛かりな修正が必要と考えがちですが、実際は「初歩的なミスだった」は、よくありますね。例えば、「a = bとすべきところをa == bにしてしまった」などです。
誰しも、こんなバグを作るはずがないと思っていますが、そうはいきません。本コラムの100行程度のプログラムならまだしも、数千行のプログラムを作成すると、ファイルがさまざまなところにまたがるため、小さなミスでも気付きません※1）。原因を見つけると、「このバグは、特別の作り方をしないと防げない」と考えるより、「なんてバカなミスをしたのだろう」と溜息をつくことが多いように思います。
※1）私の個人的な考えですが、ソースコードの行数が40KLOC（LOC：Lines Of Code＝行数の単位で、エル・オー・シーと読む。40KLOCだと4万行に相当する）を越えると、バグなしで作れないと思っています。で、どうするかですが、「それでもバグなしの高品質プログラムを目指す」か、「バグがあるのは仕方ない」と諦めるかで、開発方針が大きく異なります。
「バグなしの高品質ソフトウェアを目指す」方式を取り入れているのが米国航空宇宙局（NASA）です。有人ロケットの制御というミッションを考えると（しかも、多額の税金を投入しています）、超高品質でなければなりませんね。NASAでは、開発のコストと時間の90％をテストにかけています。超高品質は、タダでは実現できません。超高品質の代償が低生産性で、通常の新規開発の平均生産性は、1人1カ月で1000LOCですが、NASAではその10分の1に当たる100ステップです。
一方、「バグがあるのは仕方ない」との考え方でソフトウェアを開発する場合、テストにかける時間と予算（通常は、全体の30％から40％）に優先順位をつけることになります。表示メッセージのスペルミスのような「軽微なバグ」の検出に時間を使うのはもったいない。システムダウンや、生命の危機に直結する重大なバグの摘出に時間と予算を重点的に使うべきです。
大規模災害が発生した場合、被害者救助で「トリアージュ（トリアージ）」という考え方があります。今すぐ手当てをしないと助からない重症の被害者から優先的に「医者」「医療薬」「ベッド」というリソースを割り当てる方式です。これだけソフトウェアが肥大化し、しかも、超短期開発が求められている今、トリアージュ的な発想で品質を確保すべきだと思います。
前回は、音楽プレーヤーのバグを題材としたプログラムを出題しました。この問題は「a = b;」とするべきところを、「a == b;」としてしまう非常に単純なバグでした。今回も、ほぼ同様の内容で、初歩的なバグを出題します。分かる人なら一瞬で分かりますので、気楽に挑戦してください。なお、仕様とプログラムは、多少変わっていますから、前回の内容はいったん忘れて取り組んでください。
Copyright © ITmedia, Inc. All Rights Reserved.