プログラミングをやっている人にとって、うまく動くはずのコードが何故かエラーを吐いてくれたり、どう考えても成功するようなテストデータがうまく通らなかったりなんてことは、割と日常茶飯事だと思います。ええ、日常茶飯事ですとも。
思わず他人のせいにしたくなるようなこういう事態ですが、ほぼ９９％は自分のミスが原因で起こります。カンマとピリオドを間違えていたりとか、シングルクォーテーションが必要なところに付けていなかったりとか・・・フラグ設定が間違っていたりとか、そもそも仕様から外れた見当違いな処理をさせていたとか。
しかしながら、リファレンスマニュアルとどれだけにらめっこしても。業を煮やしてソースコードを全部打ち出し、一行ずつマーカーで線を引いていったとしても。どこにも間違いが無かったときという事が存在します。・・・つまり、OSとか、開発ツールにバグがある場合です。
そういう時は、バグフィックスが公開されていれば速やかにパッチを当て、何も無ければ、呪いの念を送りながらバグを回避したコードを書くと言う処置を執ることになりますが・・・当然、費やした時間は戻ってきません。
最近の開発環境は、それ自体が巨大なアプリケーションとなっていますので、当然数多くのバグを内包することになります。これは必然です。ですが、アプリケーションを開発するための環境にバグがあるというのは大変恐ろしいことですので、初期出荷の段階から、他の製品よりもいっそうのデバッグが求められるのですが・・・Microsoftは前回の出荷から、どうやら教訓を得たようですよ？
Visual Studioの「借金」を精算したMicrosoft ITmedia
「開発プロセスで採用した指標の1つが、製品を出荷するまでに修正しなければならないバグの数だった」とソマセガー氏は話す。「Visual Studio 2005の開発プロセスのピーク時には、製品出荷までに修正すべきバグのデータベースに3万2000個のバグが登録されていたときもあった。Visual Studio 2008では、ピーク時のバグの数は約5000個だった。つまり1桁も減ったのだ」とソマセガー氏は話す。
ここで言う「借金」とは、もちろんバグと、デバッグに係るコストのこと。VisualStudio2008の開発に係るとき、Microsoftは前バージョンの2005の「負債」を背負ってのスタートだったという内容。そして、VisualStudio2008の出荷の時には、ほぼ借金ゼロ、つまり既知のバグフィックスが無い状態で次のバージョンの開発に取りかかれると言うことです。
取られたのは、テストのやり方の見直し。その効果が如何に素晴らしいものであったかは、引用部分の数字が物語っている事でしょう。
ただ、開発工程が見直され、バグの発生率が下がっていると言っても、32000とか5000とか言う数字は結構なインパクトです。それらが製品版では残ってないとはいえ。
・・・世のプログラマは、この開発環境に命を預けて戦っているわけです。そして、世の中で動いているシステムは、こういう開発環境の上で作られているわけです。半ば分かっていることだったとは言え、今後もよりいっそう、安心して使える開発環境を作り出していって欲しいと願ってやみません。
