探し物を見つけると、人は探すのをやめる。
シャーロックホームズのセリフとか何とか。
相場のことばかり書いているのもナニなので、たまにはまとも風なことを書いてみます。
バグの多くはプログラムミスなわけです。時には、ケンタウリから飛んできた宇宙線がメモリを1ビット書き換えてしまったり、フォッサマグナの奥深くから湧き出した放射線がHDDの記録面を破壊したりすることもあるでしょうがね。
ユーザから見るとバグは現象です。プログラムがどのようにミスられたのかは関係ありません。
例えば二つのバグが同時に発動したときに画面が"バグる"とします。ユーザにとってバグはひとつです。
ですが、開発者は二つのバグを取り除かないとなりません。片方だけを取り除いて終了にしてしまっていることが多いかもしれません。
急いでいるときにわざとそうするのはアリだと思いますが、多くの場合一つ目の「原因らしきもの」を見つけた途端それを直すのに夢中になり、もう一つ隠れているとはユメユメ考えなくなってしまうようです。
「2つのバグが同時に発動したときに」と書いたように、一つを直せば現象としてのバグは収まりますから、それはそれでよいのかもしれません。
別のケース。
"論理的な"考え方に囚われすぎると、"量的な"考え方を忘れがちになる気がします。組み込みでは量的なものは、限られたりソースであったり、タイミングであったりします。
バグが二つあり、それぞれ別のリソースを無駄に食いつぶします。例えばメモリ断片化とバス帯域。メモリの断片化はメモリの空き容量の総量はそれほど消費しませんが、取得できる最大メモリサイズを制限してしまうだけでなく、メモリ確保/開放というシステムの根幹のパフォーマンスを劣化させます。
装置の動作がもっさりして遅いという"バグ"に対して、いくらバス帯域の浪費を抑え込んでもなかなかシステム全体のパフォーマンスは向上しません。ですが、対策によって確かに改善はするので、いつまでもバス帯域の調整が繰り返されます。
しかしながら、メモリの問題由来のパフォーマンス低下が50％、バス帯域由来の低下が50％のとき、バス帯域の調整で到達できるの50％の改善までです。しかも最初の10%改善は1週間くらいの手間で得られるものが、最後の10％ではプログラム全体に修正が及んだりして、そりゃ大変なことになるでしょう。
パフォーマンス改善のための修正がエンバグを引き起こし、仕事が増えて営業さんはウハウハですな。
さて、当事者もだんだんとこりゃ大変だと気づき始め、途中からメモリにスポットライトが当たるかもしれません。しかしその頃には、使い果たされた工数と疲弊した開発者しか残っていないかもしれません。
修正の前にアセスメントをおこない、適切に開発リソースを振り分ければ、投下する修正工数と得られるパフォーマンスの改善の最適化が待っているかも知れません。
ここでは二つという簡単なケースを考えましたが、実際のシステムではその手のバグが10や20はあって当たり前です。それぞれ数％しかパフォーマンス低下を引き起こさなくても、全体では恐ろしい結果を生みます。
行き当たりばったりで、そんな20変数の最適化問題を解けると考える方がどうかしているのです。
作る前なら、ある程度なんとかなるかもしれません。作ってしまってから無い知恵を絞るよりはマシな結果が待っていると考えるべきと考えます。
コメント