「経済的側面から言えば、「小さなバグ」は残しても良い ?」記事へのコメント

古い考え方

[Anonymous Coward]

完全を望めないのなら，効率的なやり方で完全を目指すというのは状況によっては妥当な考え方だが，それはソフトウェア開発の分野では古い。
今は仕様定義そのものから自動的にコードを生成する・コードの誤り（バグ）は仕様の誤りだから仕様定義そのもののミスを訂正してコードを再生成するという方向を目指しているはず。

以上が未来の理想論だとしても，現実にバグが見つかったということは，あらかじめそれを発見出来なかった検証作業にも問題があったということになるのだから何らかの組織的な対処が必要。　単に対症療法的に優先順位をつけてバグ取りをやれば良いというものでは無い。（末端のプログラマ・レベルでは綺麗事は言ってられないかもしれないが）

Re:古い考え方

[saitoh (10803)]

仕様を書いたらプログラムができるってのは、人工知能と同じくらい昔から「もうすぐ実用化される」と言われ続けてませんか？。100年先も言われ続けてたりして。

仕様のバグだって探すのは大変ですよ。 下手したらプログラムのバグより大変かも。 SCSI規格に違反していないコンピュータとSCSI規格に違反していないHDDをつないだら1か月に1回くらい固まるとかね。困難を極めた探究作業のあげく結局「どちらも悪くない。強いていうならSCSI規格のこれこれこの部分の規定に曖昧性があった」が結論。「S社に納入するHDDだけファームウェアを変更する」ってことで手打ちしたとか。

それに、ここで言ってるのは検証作業で見つかったバグの話なんじゃないの？「if they want to ship software with bugs」ってことだから。 だからバグが見つかったのは検証作業が悪いからだというのは違う。

Re:

[Anonymous Coward]

逆に考えるんだ。

ソースコードこそが唯一完璧な仕様書だと考えれば、仕様を書いた時点でプログラムは出来上がっている。

Re:古い考え方

[nekopon (1483)]

そしてコンパイラのバグに引っかかる。

# 懊悩