  |
こんな前提条件が成立しうるなら、バグの少ない高品質なプログラムに労働力をつぎ込むのではなくて、同じ動作をするプログラムを複数重ねて、動作判定をするプログラムを追加するという戦略を取ることはできないだろうか?
具体的には以下のとおり。
大きなアプリケーションの中で、もっとも大切な部分はコンペ型式で作って、一番まともに動いたものを「一軍」、それ以外を「控え」にする。
これらとは別に、「正しい結果を出したかどうか?」を判定するプログラムを別に作って、「正しく動いていない」と判断された場合、同じデータを控えに回して、その結果を出力するようにする。
動作判定は素朴なもの、たとえば結果が出てくるまでの時間とか、得られたデータの桁数とか、そんなもので判定して、ちょっとでもおかしかったら次々に「控え」を前に出して、とにかくまともそうな結果が出るまで選手を入れ替えていく。
ひとつのデータの処理と出力が終了したら、また一軍が元の位置に戻って、次のデータの処理にかかる。
デバッグに地獄を見た話とか、エクストリームプログラミングの話とか、みんなバグを取るための方法論を語るけれど、バグを内包したまんま動きつづけるものを想定する発想、あんまりないんだろうか。
人間の頭なんかは、どちらかというとこんな構造をしているように思うんだけれど。
http://anond.hatelabo.jp/20070119141655 デバッグに地獄を見た話とか、エクストリームプログラミングの話とか、みんなバグを取るための方法論を語るけれど、バグを内包したまんま動きつづける..
http://anond.hatelabo.jp/20070119152239 「バグだらけだから運用でカバーしてね。」 ということかな。 究極には人間というソフトでカバーというやり方だと思う。 バグを内包してないプログラム..
小規模精鋭でサービス速度重視向きな開発方法だな。 はてな向きというべきか。 ミッションクリティカル系ではあまり歓迎されなさそう。
いやいやいや。 http://anond.hatelabo.jp/20070119163438 フォールトトレラントシステム - Wikipedia 言ってるのはこれじゃないのか？普通は信頼性を上げる為に使うが、その分手を抜いてコストを下げよ
http://anond.hatelabo.jp/20070119164720 http://anond.hatelabo.jp/20070119165858 すまない、元のやつをちゃんと読み込まないままに返してしまった。 プログラミングだけの話かと思ってしまったんだが、実..
http://anond.hatelabo.jp/20070119141655 http://anond.hatelabo.jp/20070119152239 入力と関数と出力があって、同じ入力を複数のアルゴリズムで実装された関数に与え、出力結果が異なれば異常発生と見なし..
http://anond.hatelabo.jp/20070119165858 処理コスト・時間コストを使っても安全性が欲しい部分でなら使えるかもね。 金融関係あたりとか？ 一時期、新聞にたくさん載ってたなあｗ
12
