バグが直った。
2008年05月20日14:39
今、僕はプログラムを作っている。 作り始めてもう２年経って、プログラムも随分と巨大に高性能になってきた。 すると、どうしてもバグが出てきてしまう。 それで、今回、非常にしつこいバグに出会った。 先々月ぐらいの話だ。 ドイツに行く前だった。 このバグが今さっき、ようやっと直ったのだ。 長かった。 とにかく何週間もこのバグだけのために、連日連夜・何時間も時間を費やした。 本当に疲れた。
なんというか、開発が進むにつれ、バグ修正がどんどん難しくなってる。 もしこれが納期のある仕事だったら、爆死していたと思う。 とにかく、物凄く発見が困難なバグだった。 直ったけど正直、まだ他にいくつか可能性が残っていて、再発の可能性も否定できない。 だけど、とにかく直ったように見えるので、今はこれで満足しようと思う。
これの難しさ。 どうやったら説明できるだろう。
これって超難解版『ウォーリーを探せ』 みたいな感じだ。
昔、ウォーリーを探せっていう遊びがあった。 街を見下ろすような絵の中にたくさんの人が歩いていて、その中にたった一人だけ赤白のしましまセーターを着た「ウォーリー」がまぎれている。 僕が今作っているような並列処理プログラムのバグ修正って、ウォーリーを探せの難しさと似てる。
しかも、ただのウォーリーを探せと、一味も二味も違う超難解版だ。 街の中に居る無数の人は、なんと、みんなウォーリーと同じ格好をしている。 設問は 「そのなかで、ウォーリーだけが、腕時計をしています。 さてウォーリーはどこでしょう。」 となっている。 これは細かい。 死ぬほど細かい。 これは、気が狂いそうなほど難しい。
腕時計が見える場所にあるならまだいい。 たまに絵自体が間違っていて、腕時計がないことすらある。 そうすると、自分で絵を見て、文脈から論理的に考えて「本当はどこに腕時計が見えるはずだ！」 「だから、絵のここを修正しなければ、おかしいはずだ！」というような事まで考えなければいけない。
ヘタをすると、もっと難しいウォーリーを探せになることもある。
「この中のウォーリーと同じ格好をした人たちは、みな２０人のグループで行動をしています。 しかし！ ウォーリーだけが２１人のグループに入って行動しています！ さぁウォーリーはどこでしょうか！」
こんなの、ムチャムチャだ。 これは、絵を探すだけでなく、絵の中の人たちのしぐさを見て、誰と誰が同じグループ同士なのか、といった全ての関連を洗い出さなければいけない。 次にそこにどのようなグループが存在するのか、数え上げる必要がある。 それはすなわち、全ての人に、一意な名前をつけていく必要があるということを意味している。 問題は、簡単じゃない。
でも、並列プログラミングをしていると、本当にそんなような作業を強いられる事がある。
◇
しかし、思うんだけど、こういうこと、普通の会社で仕事としては絶対に出来なかったと思う。 まず、問題の本質がどれくらい難しいのか説明しないといけない。 次に「何とかごまかしで直す事って出来ないの～？」という誘惑的な意見を言う上司をなだめなければいけない。 次に開発費用と売り上げが立つまでの期間を説明しろ、という上司と闘う必要もある。 精神集中して無愛想になった自分が、上司を不安がらせないように、定期的に飲みに誘う必要もある。
こういうプログラミング以外のことにたくさん時間をかけなければいけない。
とにかく、プログラムというのは、出来上がるまでわからない。 出来上がるまで、どれくらいの期間で出来上がるのかわからない。 出来上がるまで、それがどういう動作をするものなのかわからない。 それがどれくらいの売り上げを出すものなのか、わからない。 それが人にどういう役に立つのか、わからない。
もちろん、つくっている当人は、漠然と、こういう風に動いたら、面白いだろうな、ぐらいのことは思っている。 だけど、なにぶん、これから描くマンガが、こんなに面白いんだよ、っていうことを、そのマンガを見せることなく説明するのが難しいのと同じ様に、現物が無い事には、そのよさを理解してもらうことは難しいものだ。
さて、次の直すバグは... なんだっけ。 もう忘れてるし。
◇
バグ修正ってある意味面白い。 問題が難しければ難しいほど、面白い。 問題を理解できると、何ヶ月もかかって修正したバグであっても、次から２時間程度で修正できるようになったりもするし。
そうすると、キャリアの短いプログラマからは、正に「神業」の様にすさまじいスピードに見えるので、開いた口が閉まらなくなるぐらい驚かせる事ができる。 だから、余計面白くなる。
なんというか、開発が進むにつれ、バグ修正がどんどん難しくなってる。 もしこれが納期のある仕事だったら、爆死していたと思う。 とにかく、物凄く発見が困難なバグだった。 直ったけど正直、まだ他にいくつか可能性が残っていて、再発の可能性も否定できない。 だけど、とにかく直ったように見えるので、今はこれで満足しようと思う。
これの難しさ。 どうやったら説明できるだろう。
これって超難解版『ウォーリーを探せ』 みたいな感じだ。
昔、ウォーリーを探せっていう遊びがあった。 街を見下ろすような絵の中にたくさんの人が歩いていて、その中にたった一人だけ赤白のしましまセーターを着た「ウォーリー」がまぎれている。 僕が今作っているような並列処理プログラムのバグ修正って、ウォーリーを探せの難しさと似てる。
しかも、ただのウォーリーを探せと、一味も二味も違う超難解版だ。 街の中に居る無数の人は、なんと、みんなウォーリーと同じ格好をしている。 設問は 「そのなかで、ウォーリーだけが、腕時計をしています。 さてウォーリーはどこでしょう。」 となっている。 これは細かい。 死ぬほど細かい。 これは、気が狂いそうなほど難しい。
腕時計が見える場所にあるならまだいい。 たまに絵自体が間違っていて、腕時計がないことすらある。 そうすると、自分で絵を見て、文脈から論理的に考えて「本当はどこに腕時計が見えるはずだ！」 「だから、絵のここを修正しなければ、おかしいはずだ！」というような事まで考えなければいけない。
ヘタをすると、もっと難しいウォーリーを探せになることもある。
「この中のウォーリーと同じ格好をした人たちは、みな２０人のグループで行動をしています。 しかし！ ウォーリーだけが２１人のグループに入って行動しています！ さぁウォーリーはどこでしょうか！」
こんなの、ムチャムチャだ。 これは、絵を探すだけでなく、絵の中の人たちのしぐさを見て、誰と誰が同じグループ同士なのか、といった全ての関連を洗い出さなければいけない。 次にそこにどのようなグループが存在するのか、数え上げる必要がある。 それはすなわち、全ての人に、一意な名前をつけていく必要があるということを意味している。 問題は、簡単じゃない。
でも、並列プログラミングをしていると、本当にそんなような作業を強いられる事がある。
◇
しかし、思うんだけど、こういうこと、普通の会社で仕事としては絶対に出来なかったと思う。 まず、問題の本質がどれくらい難しいのか説明しないといけない。 次に「何とかごまかしで直す事って出来ないの～？」という誘惑的な意見を言う上司をなだめなければいけない。 次に開発費用と売り上げが立つまでの期間を説明しろ、という上司と闘う必要もある。 精神集中して無愛想になった自分が、上司を不安がらせないように、定期的に飲みに誘う必要もある。
こういうプログラミング以外のことにたくさん時間をかけなければいけない。
とにかく、プログラムというのは、出来上がるまでわからない。 出来上がるまで、どれくらいの期間で出来上がるのかわからない。 出来上がるまで、それがどういう動作をするものなのかわからない。 それがどれくらいの売り上げを出すものなのか、わからない。 それが人にどういう役に立つのか、わからない。
もちろん、つくっている当人は、漠然と、こういう風に動いたら、面白いだろうな、ぐらいのことは思っている。 だけど、なにぶん、これから描くマンガが、こんなに面白いんだよ、っていうことを、そのマンガを見せることなく説明するのが難しいのと同じ様に、現物が無い事には、そのよさを理解してもらうことは難しいものだ。
さて、次の直すバグは... なんだっけ。 もう忘れてるし。
◇
バグ修正ってある意味面白い。 問題が難しければ難しいほど、面白い。 問題を理解できると、何ヶ月もかかって修正したバグであっても、次から２時間程度で修正できるようになったりもするし。
そうすると、キャリアの短いプログラマからは、正に「神業」の様にすさまじいスピードに見えるので、開いた口が閉まらなくなるぐらい驚かせる事ができる。 だから、余計面白くなる。
コメント一覧
這いよる謎の犬ピース 2008年05月20日 15:28
大きなプログラムのデバックは砂漠の中でアリを探すようなイメージがありました。ウォーリーの例え、わかりやすいです。 関連付けを洗い出していく…まるで事件を調べる刑事のようです。
ナム 2008年05月20日 21:47
素人です。
バグを見つけるソフトとかはないんですか？
バグを見つけるソフトとかはないんですか？
クレ 2008年05月20日 23:52
今作っているプログラムは近い将来おかあつさんの生活の糧になるものなのでしょうか？他のプログラムと同時進行ということもあるのでしょうか？
おかあつ 2008年05月21日 05:40
＞のぶさん
＞関連付けを洗い出していく…まるで事件を調べる刑事のようです。
... のようです、じゃなくて、そのものだと思うよ。
Flashでアプリをつくるのも最終的には同じ。 考える事が大切。
ナムさん、
＞バグを見つけるソフトとかはないんですか？
最終的には、もう人間の目で追跡は出来ないので、結局ソフト的に検査することになるんですが、そのソフトは、既存のものをつかうわけではなく毎回毎回自分自身の手でオーダーメイド的に作っていきます。
コンピューター将棋棋士を作る時、将棋の戦法に詳しくなければ作れないのと同じで、バグが何故起こるのかある程度はっきりと理解してないと、バグを追跡するソフトも作れないので、結局、難しいのです。
クレさん、
＞今作っているプログラムは近い将来おかあつさんの生活の糧になるものなのでしょうか？
なります。 これによって、僕は近年稀に見る莫大な財産を築き上げます。
.... なんてことにならないとも限らないので、とりあえず出来る事をコツコツやっていきます。 僕が思ったとおりに作る事ができればの話ですが、このプログラムは FaceBookと mixi をあわせて、PayPalの機能を足したような、Skypeと同じ分散型のプログラムになるはずです。
＞関連付けを洗い出していく…まるで事件を調べる刑事のようです。
... のようです、じゃなくて、そのものだと思うよ。
Flashでアプリをつくるのも最終的には同じ。 考える事が大切。
ナムさん、
＞バグを見つけるソフトとかはないんですか？
最終的には、もう人間の目で追跡は出来ないので、結局ソフト的に検査することになるんですが、そのソフトは、既存のものをつかうわけではなく毎回毎回自分自身の手でオーダーメイド的に作っていきます。
コンピューター将棋棋士を作る時、将棋の戦法に詳しくなければ作れないのと同じで、バグが何故起こるのかある程度はっきりと理解してないと、バグを追跡するソフトも作れないので、結局、難しいのです。
クレさん、
＞今作っているプログラムは近い将来おかあつさんの生活の糧になるものなのでしょうか？
なります。 これによって、僕は近年稀に見る莫大な財産を築き上げます。
.... なんてことにならないとも限らないので、とりあえず出来る事をコツコツやっていきます。 僕が思ったとおりに作る事ができればの話ですが、このプログラムは FaceBookと mixi をあわせて、PayPalの機能を足したような、Skypeと同じ分散型のプログラムになるはずです。
