アカウント名:
パスワード:
ビルド寸前までコードを書く行為はすべて設計です。設計を外部に任せるためには、相応の信頼と権限の委譲が必要です。納得行くものが出来上がらずに細かな指示をしていくというのは、自分で設計する部分を増やしているだけです。
同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質です
と宣言してたバカがいたな
あなたには品質を担保できる試験仕様を書く能力がないということですね。あなたの能力ではできないことでも、普通にこなせる人が世の中にはいるんですよ。
そうそう、「仕様を書く能力」は重要。この能力がないのに口でアレコレ言えば下が理想のモノを作ってくれると思い込んでる上司に当たるとサイアク。そいつが思い描いていないものができるとヒス起こすし。
another side:懇切丁寧に説明しててもろくなもん作らない、今度来た奴ヒドイわ。
#どっちもあるな。
ちょっと疑問。なぜこの流れでここで皮肉を書く必要が。
じゃ、試験仕様書を作るための要求品質を定義する能力がないってことですね。
または、作られた製品が過剰品質ってことかな
>あなたには品質を担保できる試験仕様を書く能力がないということですね。>あなたの能力ではできないことでも、普通にこなせる人が世の中にはいるんですよ。
むしろ、あなたが、試験仕様で(有限のリソースの中で)全ての状態を網羅できるという幻想を持っているバカとしか思えないのですが。
コードカバレッジという言葉はご存知ですか?
はい、コードカバレッジという言葉もそれが完全な試験手法ではないことも知ってるけど。
そして、チューリング言語で書かれたプログラムを完全に試験する一般的な術はないことも知ってる。
ああ、チューリングマシンの停止性問題を聞きかじってるって事ですね。チューリングマシンの停止性問題と、そのプログラムが仕様を満たしているか判断できるかという問題は別物ですよ。いい感じにまとまっているのが以下。http://d.hatena.ne.jp/noopable/20090528/1243503981 [hatena.ne.jp]
元コメの人間ではないけれど、自ら墓穴を掘ってどうするのかなぁ?
コードカバレッジで大丈夫、とか思っているようですが、お勧めの URL には以下のように記述されてますね。
| 実際、実務上、バグがないことを証明しろと言われれば、| 「現状でそれは無理」もしくは、「証明費用が開発費用の| 数倍かかり、なおかつ、厳密な証明ではなく近似的なもの| になりますよ」という話をすると思います。| それはすなわち実務上は限りなく不可能に近いと言っても| いいかもしれません。
とはいえ、ご紹介の URL も詭弁ではないですか。以下の証明とやらですが、「バグのないプログラムは作れない」という
カバレッジが100%で、仮にバグが0であったとしても、スパゲッティプログラムは書けるんだな。コードの品質と現在残っているバグの個数とテストのカバレッジに相関はあってもイコールではない。
>同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質ですと言った奴はそんな初歩的なことも知らないのだから、大馬鹿者としか言いようがないのです。
この業界、何が怖いって、こういう基地外がときどきいる事なんだよな。頼むから、近づかないでください。
うーん。カバレッジで網羅できればいいんですけどねー。たとえば
・既知の脆弱性が存在しない・絶対にリソースリークが発生しない
ことを、試験仕様にすべて表現できますかね?
それは・チェックすべき既知の脆弱性を挙げる事ができない・リソースリークが発生しないという事を判断する条件を規定できない
とみなしていいかな?3以上を数えられない土人かおまえは。
品質を担保するのが試験の役目なんだから、試験しない項目は品質とは関係ないと言ってるのと同じなんだよ。
つーてもまあ、ソースの全システム機能呼び出しが発生する(かもしれない)箇所すべてで、システムにも相応の負荷をさまざまなパターンでかけるとか、難しいよ。
# OSやライブラリ側がある負荷以上になると、問題になりうる挙動をしめす。とかあるだろうし。
個々の事例というか箇所を指摘するのは、たぶんできるんだろうけど。それの組合せになると事実上試験しきれなくなるんじゃないかな?# 規模が中以上を想定しています。
とはいえ、実装の子細の違いとかは試験仕様を通るなら問題ない、で通るだろうし、状況しだいかなぁ。
>コードカバレッジという言葉はご存知ですか?
全ての「状態」を網羅できるか、と書いたのですが?コードカバレッジが100%だったとして、それが満たせているとでも思っているのかな?
コードを網羅できて、状態を網羅できないと考える根拠は?たくさんあるからわかりませんか?
既に証明されてるし、計算機屋なら常識。
学校で書くようなHelloWorldレベルの小作とか真の意味での純粋関数型言語とかならともかく、コードカバレッジで全ての状態を網羅できると思うのは浅はか過ぎないかい?
横から参加するけど、ここでいう「状態」は単にそこを通過するってだけじゃなくて、性能要件も含んでると思って読んでた。機能要件でカバレッジ100%ってのは前提で、その上で問題になる品質ってのは高負荷時の挙動とかそのへんじゃないのかなって。
C0 C1 C2 という言葉をご存知ですか?
最近、久しぶりに歯医者に行って聞きました。
「俺様にできないことがお前ごときにできるわけがない」まで読んだ。
すべての品質を担保する試験を書いてる暇があれば、それを実装する時間は、コミュニケーションにかかるコストを考えれば大した差は無いとおもうよ。細かく仕様を出すということは、プログラムを書く行為と同等だからね。信頼と委譲が必要という意見に同意。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
プログラミングは設計 (スコア:3)
ビルド寸前までコードを書く行為はすべて設計です。
設計を外部に任せるためには、相応の信頼と権限の委譲が必要です。
納得行くものが出来上がらずに細かな指示をしていくというのは、自分で設計する部分を増やしているだけです。
Re: (スコア:0)
同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質です
と宣言してたバカがいたな
Re:プログラミングは設計 (スコア:0)
あなたには品質を担保できる試験仕様を書く能力がないということですね。
あなたの能力ではできないことでも、普通にこなせる人が世の中にはいるんですよ。
Re:プログラミングは設計 (スコア:1)
そうそう、「仕様を書く能力」は重要。
この能力がないのに口でアレコレ言えば下が理想のモノを作ってくれると思い込んでる上司に当たるとサイアク。
そいつが思い描いていないものができるとヒス起こすし。
another side:
懇切丁寧に説明しててもろくなもん作らない、今度来た奴ヒドイわ。
#どっちもあるな。
Re: (スコア:0)
ちょっと疑問。
なぜこの流れでここで皮肉を書く必要が。
Re: (スコア:0)
じゃ、試験仕様書を作るための要求品質を定義する能力がないってことですね。
または、作られた製品が過剰品質ってことかな
Re: (スコア:0)
>あなたには品質を担保できる試験仕様を書く能力がないということですね。
>あなたの能力ではできないことでも、普通にこなせる人が世の中にはいるんですよ。
むしろ、あなたが、試験仕様で(有限のリソースの中で)全ての状態を網羅できるという幻想を持っているバカとしか思えないのですが。
Re: (スコア:0)
コードカバレッジという言葉はご存知ですか?
Re:プログラミングは設計 (スコア:2)
はい、コードカバレッジという言葉も
それが完全な試験手法ではないことも
知ってるけど。
そして、チューリング言語で書かれたプログラムを
完全に試験する一般的な術はないことも知ってる。
Re: (スコア:0)
ああ、チューリングマシンの停止性問題を聞きかじってるって事ですね。
チューリングマシンの停止性問題と、そのプログラムが仕様を満たしているか判断できるかという問題は別物ですよ。
いい感じにまとまっているのが以下。
http://d.hatena.ne.jp/noopable/20090528/1243503981 [hatena.ne.jp]
Re: (スコア:0)
元コメの人間ではないけれど、自ら墓穴を掘ってどうするのかなぁ?
コードカバレッジで大丈夫、とか思っているようですが、
お勧めの URL には以下のように記述されてますね。
| 実際、実務上、バグがないことを証明しろと言われれば、
| 「現状でそれは無理」もしくは、「証明費用が開発費用の
| 数倍かかり、なおかつ、厳密な証明ではなく近似的なもの
| になりますよ」という話をすると思います。
| それはすなわち実務上は限りなく不可能に近いと言っても
| いいかもしれません。
とはいえ、ご紹介の URL も詭弁ではないですか。
以下の証明とやらですが、「バグのないプログラムは作れない」
という
Re:プログラミングは設計 (スコア:1)
カバレッジが100%で、仮にバグが0であったとしても、スパゲッティプログラムは書けるんだな。
コードの品質と現在残っているバグの個数とテストのカバレッジに相関はあってもイコールではない。
>同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質です
と言った奴はそんな初歩的なことも知らないのだから、大馬鹿者としか言いようがないのです。
Re: (スコア:0)
この業界、何が怖いって、こういう基地外がときどきいる事なんだよな。
頼むから、近づかないでください。
Re: (スコア:0)
うーん。カバレッジで網羅できればいいんですけどねー。たとえば
・既知の脆弱性が存在しない
・絶対にリソースリークが発生しない
ことを、試験仕様にすべて表現できますかね?
Re: (スコア:0)
それは
・チェックすべき既知の脆弱性を挙げる事ができない
・リソースリークが発生しないという事を判断する条件を規定できない
とみなしていいかな?
3以上を数えられない土人かおまえは。
品質を担保するのが試験の役目なんだから、試験しない項目は品質とは関係ないと言ってるのと同じなんだよ。
Re:プログラミングは設計 (スコア:1)
つーてもまあ、ソースの全システム機能呼び出しが発生する(かもしれない)箇所すべてで、システムにも相応の負荷をさまざまなパターンでかけるとか、難しいよ。
# OSやライブラリ側がある負荷以上になると、問題になりうる挙動をしめす。とかあるだろうし。
個々の事例というか箇所を指摘するのは、たぶんできるんだろうけど。それの組合せになると事実上試験しきれなくなるんじゃないかな?
# 規模が中以上を想定しています。
とはいえ、実装の子細の違いとかは試験仕様を通るなら問題ない、で通るだろうし、状況しだいかなぁ。
M-FalconSky (暑いか寒い)
Re: (スコア:0)
>コードカバレッジという言葉はご存知ですか?
全ての「状態」を網羅できるか、と書いたのですが?
コードカバレッジが100%だったとして、それが満たせているとでも思っているのかな?
Re: (スコア:0)
コードを網羅できて、状態を網羅できないと考える根拠は?
たくさんあるからわかりませんか?
Re: (スコア:0)
既に証明されてるし、計算機屋なら常識。
Re: (スコア:0)
学校で書くようなHelloWorldレベルの小作とか真の意味での純粋関数型言語とかならともかく、
コードカバレッジで全ての状態を網羅できると思うのは浅はか過ぎないかい?
Re: (スコア:0)
横から参加するけど、ここでいう「状態」は単にそこを通過するってだけじゃなくて、性能要件も含んでると思って読んでた。
機能要件でカバレッジ100%ってのは前提で、その上で問題になる品質ってのは高負荷時の挙動とかそのへんじゃないのかなって。
Re: (スコア:0)
C0 C1 C2 という言葉をご存知ですか?
Re: (スコア:0)
最近、久しぶりに歯医者に行って聞きました。
Re: (スコア:0)
「俺様にできないことがお前ごときにできるわけがない」まで読んだ。
Re: (スコア:0)
すべての品質を担保する試験を書いてる暇があれば、それを実装する時間は、コミュニケーションにかかるコストを考えれば大した差は無いとおもうよ。細かく仕様を出すということは、プログラムを書く行為と同等だからね。信頼と委譲が必要という意見に同意。