  |
入力と関数と出力があって、同じ入力を複数のアルゴリズムで実装された各関数に与え、出力結果が異なるものがあれば異常発生と見なし、システムを停止するなり多数決を行うなり、って話？
朴訥に実装した関数と、こりこりに最適化した関数に、それぞれデータを食わして……みたいな話は既に行われてるよ。朴訥な方は速度が遅いから、テスト段階で、って話だけど。
逆だ逆。無料Ｗｅｂサービスは量で勝負（客数/鯖代）なんだから、実装の冗長化なんて無理（一番遅い実装に速度が引き摺られることになるし、結果の照合を行うプログラムのオーバーヘッドもある）。どうしたって「確実で早い唯一の実装」が求められる。だからテストケースを増やしたり、目を増やしたりするわけだ。
処理コスト・時間コストを使っても安全性が欲しい部分でなら使えるんじゃね？
っていうか前提がおかしいんだな
これはＹｅｓだけど
これはＮｏだなぁ。
「ちゃんと書ける人がちゃんと書く」ならテストとデバッグに掛かるコストは大幅に減少する。
Ｎｏ．比例するに決まってるじゃん。
例外は「労働力」を「時間」と捉えた場合か。「まともな技術者を1ヶ月使う」「まともでない技術者を６ヶ月使う」を同じだと思った場合とか。
測定はできるかもしれん。だけど、前2項がＹｅｓであるような酷いプロジェクトでは、余計な混乱を招くだけだろう。
4番目がYesなら2番目3番目はNoだろうから、前提全てが満たされることはない。
何があっても動きつづけるプログラムに需要がある プログラムをスクラッチするコストよりも、テストとデバッグに要するコストのほうが莫大 プログラムに要した労働力と、バグの...
http://anond.hatelabo.jp/20070119141655 http://anond.hatelabo.jp/20070119152239 入力と関数と出力があって、同じ入力を複数のアルゴリズムで実装された関数に与え、出力結果が異なれば異常発生と見なし..
http://anond.hatelabo.jp/20070119165858 処理コスト・時間コストを使っても安全性が欲しい部分でなら使えるかもね。 金融関係あたりとか？ 一時期、新聞にたくさん載ってたなあｗ
http://anond.hatelabo.jp/20070119164720 http://anond.hatelabo.jp/20070119165858 すまない、元のやつをちゃんと読み込まないままに返してしまった。 プログラミングだけの話かと思ってしまったんだが、実..
http://anond.hatelabo.jp/20070119141655 デバッグに地獄を見た話とか、エクストリームプログラミングの話とか、みんなバグを取るための方法論を語るけれど、バグを内包したまんま動きつづける..
http://anond.hatelabo.jp/20070119152239 「バグだらけだから運用でカバーしてね。」 ということかな。 究極には人間というソフトでカバーというやり方だと思う。 バグを内包してないプログラム..
小規模精鋭でサービス速度重視向きな開発方法だな。 はてな向きというべきか。 ミッションクリティカル系ではあまり歓迎されなさそう。
いやいやいや。 http://anond.hatelabo.jp/20070119163438 フォールトトレラントシステム - Wikipedia 言ってるのはこれじゃないのか？普通は信頼性を上げる為に使うが、その分手を抜いてコストを下げよ
15
