本連載では、システムのバグを単純に紹介するだけではなく、そうしたバグがアプリケーション開発にどのように影響するのか？どのように対処して回避することが最善なのか？などについて、いくつかの例を取り上げて解説したいと思います。

システム、Framework API、SDK（開発キット）、開発ツールなどには必ずバグが潜んでいます。一般的な使用方法では表面化しないが、特別な環境下で出現して我々を悩ませるバグもあります。APIの実装時に、Apple社が提供するドキュメントや、Universal Interfacesのヘッダファイルのコメントを100%信じると、思いっきり痛い目に会う場合もあります（笑）。APIが期待どおり動かない程度ならまだ良いのですが、極端な例を上げると、APIが定義されているのに中身はまったくNOP（空）といったケースにも遭遇したことがあります（本当ですよ...）。

開発中のアプリケーションに、ある機能を実装しようとしたとします。そこで使っている主用APIにバグが存在するために機能がうまく実装できないとしても、職業プログラマであれば「じゃ機能の実装を止めます」と安易に逃げることはできません。代用のAPIを探すか、機能の内容を見直すか、とにかく何らかの逃げ道を見つけて対処しなければいけないのが宿命です。そのために、「バグ情報の収集」（聞き込み）「代用APIのピックアップと再勉強」（張り込み）「機能の仕様の再構築」「バグ回避処理の実装」などなど、多くの追加作業を見積もらなくてはいけなくなります。まあ、ハード寄りのソフトを開発されている方は、こうした「バグからの逃げ道」が非常に狭いわけでして、一番上位階層のアプリケーションを開発している筆者は、まだ幸せな方だと思ったりもするわけです...。

プログラムを始めたばかりのころは、締め切りぎりぎりの開発作業において、自分自身のソースコードならまだしも、本筋とはまったく別な個所で余分な時間を消費しなけれないけないことを、苦痛意外の何者でもないと感じていました。しかし、こうした経験を20年以上も積み重ねてくると、数多くのバグとの遭遇や格闘が、自分自身のプログラミングスキルを大きく上達させるのに一役買っていたことに気づきました。そんなわけで、そうした経験のいくつかをお話することは、きっと他の人の役にも立つのではないかと考えております。

さて、バグを見つけたら、まずはすみやかにApple社に報告する必要があります。次回はその方法を詳しく紹介します。

つづく