アカウント名:
パスワード:
バグという言葉について、コーディングレベルのものを前提にしている人が多いような気がするけど、仕様からして間違ってるもの(私は仕様のバグと呼んでます)についての意見も聞きたいな。
別にMSをたたくのが目的じゃないけど、MSの製品に多いよね。
いかに早い段階から計算機上でデバッグできる形(現代の技術ではそれは実装そのものである)にするか?が勝負だという。
仕様に問題があれば、デバッグ中に発覚したとしても仕様のレ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
仕様のバグ (スコア:1, 興味深い)
別にMSをたたくのが目的じゃないけど、MSの製品に多いよね。
Re:仕様のバグ (スコア:2, 参考になる)
コーディングのバグか仕様のバグかというのは常に明確に分かれるものではないと思いますが、ソフトウェアのセキュリティホールの中には、仕様のバグによるものもけっこうあります。 IE や Opera で、 Content-Type: text/plain でもスクリプトが動く弱点 [srad.jp]は典型的な仕様のバグでしょう。しかも、 IE はいったんそういう仕様で作ってしまった以上、簡単には変えられないようです。 そうですか? Windows や IE には仕様のバグと思われる問題点がいろいろありますが、ほかのソフトウェアについても挙げればいろいろあるような気がします。
……と書いたので例を挙げてみようと思っても面白い例が思いつかないのですが。 :) 最近、使っているソフトウェアのうち大規模なものがほとんど Microsoft 製だからなあ……。(不健全?)
鵜呑みにしてみる?
Re:仕様のバグ (スコア:1)
全力って何なんだろう?ってのが有ったりします(^^;
卑近な言いかたをすれば、「レビュー」とやらをなんべんやったところで
ほんとうに良くなるの?と疑問に思ってみたりとか。
猟師プログラマとか名乗る人も言ってましたが、
仕様のバグは、実装のように計算機の上で走らせて確認することが
(たいてい)困難ないしは不可能なので、そう簡単にバグを取れない、という面が。
#こっちとしては、そういう不確かなものなんだから、「仕様書いてやったんだぞ」的な、デカい面するなよなとは思う。
やりかたをよほど選ばない限り、全力といっても空回りしまくるんじゃないかと思うんですよね。
そういう意味では、いわゆる仕様書をかなりの割合で追放しちゃったXPは、慧眼かも。
いかに早い段階から計算機上でデバッグできる形(現代の技術ではそれは実装そのものである)にするか?が勝負だという。
実装詳細仕様書なんてものを(実装言語以外で)書いちゃった時点で、敗北なのかも知れない。
よだん:
企業内の「偉い人」ほど、仕様というものにたいして躍起になっているような気がする…のは被害妄想か?
Re:仕様のバグ (スコア:1)
ただ、ソフトウェアというものが、全体像を一人で理解できないくらい複雑になってしまった現在、仕様策定というステップでいくら慎重になってもうまい仕様など決められないのかもしれません。ぼくは、そうは思いたくないですが……。
鵜呑みにしてみる?
Re:仕様のバグ (スコア:1)
> に気付いたら、また実装からやり直すわけですよね。素人考えで
> は、それでは逆に時間がかかるのではないかと思います。
だからこそカプセル化して部分部分は仕様変更に耐えられるようにしよう、
という OOP の発想が出て来るわけ。
そうすれば再実装する部分はごくわずかでいい。
# mishimaは本田透先生を熱烈に応援しています
Re:仕様のバグ (スコア:1)
<おふとぴ>
「~罠」の用法って、これでいいんですか?>識者
</おふとぴ>
Re:仕様のバグ (スコア:0)
Re:仕様のバグ (スコア:1)
スパイラル(ぐるぐる周り)開発と呼ばれる手法では、そのために、
「やりなおしの単位」を最初から小さくなるように設定するようです。
で、たとえばOOPは、それ以前の手法より、その小ささを実現しやすいという面が有るので、
そっち方面で(も)重宝であるらしいです。
OOPって、「小プログラム」を組みあわせてアプリを作るようなものですから。
(従来もそうしていましたが、ルーチンの単位だけじゃなく状態の単位も小分けしやすいのが、OOP。)
小さい部品を作りなおすわけです。大きい全体ではなく。
>仕様策定というステップでいくら慎重になってもうまい仕様など決められないのかもしれません。
木を見て森見ずと言いますが、俺が想うに、大掴みならばともかく
詳細に至るまでについては、がっちり策定しにくいんじゃないかと。
ただ、詳細かどうかとは直交の軸として、メタ度が高い視点か低い視点か、という問題が有りまして、
高いメタ度で、かつ詳細に直結するような部分、を策定するってのは色々できるかなと。
平たくいえば、「全体に共通する詳細」を把握することは、できるかも。
個々の個所に固有な詳細は、きりがなくて手に負えないかなと。
>ぼくは、そうは思いたくない
どっちにせよ、万能支配主義に傾倒するのは、危険かなと。
把握しやすい部分とそうでない部分が有るんで、それの区別、見極め、が重要ということなのじゃないかと。
てゆーか、その区別を「間違う」とデスマーチしやすいと思います。
人はしばしば、簡単なものと困難なものとを取り違える生き物ですので。
あと前述したように、仕様のコンパイラ(笑いごとじゃなく)が存在しないのがイタイ、ってのも有ります。
機械的にその確かさを確認する手段の不在、です。
Re:仕様のバグ (スコア:1)
なんつーか、仕様だしからデバッグまで一人とか数名で近い所でやってる場合は多少無茶な仕様でも時間さえあれば何とか出来るのですが(後は有能な営業:-)、
そうでなくて営業ががちがちだったり、「何でも出来る」と勘違いしてる人だったり、孫請け以下まであるような大規模プロジェクトだったりすると、机上で仕様をこねられると大抵破綻するようですね。
破綻しているのを無理に商品にするから、バグがてんこもりになるような感じがするのですが、実感として。
猟師プログラマ (スコア:1)
細かいことですが、SDで連載されている方なら、「漁師」です。その意味は私には理解できていませんが。
Re:仕様のバグ (スコア:0)
出来たものが正しいのかどうかも判定できないし。
仕様に問題があれば、デバッグ中に発覚したとしても仕様のレ
Re:仕様のバグ (スコア:1)
うーん。まあそれもそうなのかも知れないけど、
大まかにせよ詳細にせよどっちにせよ、「仕様コンパイラ」「仕様インタプリタ」が無いかぎりは、
その仕様書の記述が「ほんとに動くものにすることができるのか」を
確かめる術が無いって事情は同じなわけです。
漠然とした仕様が常に、実装し動かし得るモデルのいずれかにマッピングできる、という保証は、無いです。
逆に言えば、そのマッピング可能性を素朴に信じて疑ってない人が、そういうイタい仕様書を書くわけです。
そういう意味では、そういう人ほど、(迷惑であること(としばしば横暴であること)をさておけば)「かわいい」んですよね…(遠い目…
#まあ、仕様書が詳細に言及すればするほど、イタい「個所の数」が多くなるのは、確かでしょうけども。