アカウント名:
パスワード:
ビルド寸前までコードを書く行為はすべて設計です。設計を外部に任せるためには、相応の信頼と権限の委譲が必要です。納得行くものが出来上がらずに細かな指示をしていくというのは、自分で設計する部分を増やしているだけです。
同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質です
と宣言してたバカがいたな
あなたには品質を担保できる試験仕様を書く能力がないということですね。あなたの能力ではできないことでも、普通にこなせる人が世の中にはいるんですよ。
そうそう、「仕様を書く能力」は重要。この能力がないのに口でアレコレ言えば下が理想のモノを作ってくれると思い込んでる上司に当たるとサイアク。そいつが思い描いていないものができるとヒス起こすし。
another side:懇切丁寧に説明しててもろくなもん作らない、今度来た奴ヒドイわ。
#どっちもあるな。
ちょっと疑問。なぜこの流れでここで皮肉を書く必要が。
じゃ、試験仕様書を作るための要求品質を定義する能力がないってことですね。
または、作られた製品が過剰品質ってことかな
>あなたには品質を担保できる試験仕様を書く能力がないということですね。>あなたの能力ではできないことでも、普通にこなせる人が世の中にはいるんですよ。
むしろ、あなたが、試験仕様で(有限のリソースの中で)全ての状態を網羅できるという幻想を持っているバカとしか思えないのですが。
コードカバレッジという言葉はご存知ですか?
はい、コードカバレッジという言葉もそれが完全な試験手法ではないことも知ってるけど。
そして、チューリング言語で書かれたプログラムを完全に試験する一般的な術はないことも知ってる。
カバレッジが100%で、仮にバグが0であったとしても、スパゲッティプログラムは書けるんだな。コードの品質と現在残っているバグの個数とテストのカバレッジに相関はあってもイコールではない。
>同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質ですと言った奴はそんな初歩的なことも知らないのだから、大馬鹿者としか言いようがないのです。
うーん。カバレッジで網羅できればいいんですけどねー。たとえば
・既知の脆弱性が存在しない・絶対にリソースリークが発生しない
ことを、試験仕様にすべて表現できますかね?
それは・チェックすべき既知の脆弱性を挙げる事ができない・リソースリークが発生しないという事を判断する条件を規定できない
とみなしていいかな?3以上を数えられない土人かおまえは。
品質を担保するのが試験の役目なんだから、試験しない項目は品質とは関係ないと言ってるのと同じなんだよ。
つーてもまあ、ソースの全システム機能呼び出しが発生する(かもしれない)箇所すべてで、システムにも相応の負荷をさまざまなパターンでかけるとか、難しいよ。
# OSやライブラリ側がある負荷以上になると、問題になりうる挙動をしめす。とかあるだろうし。
個々の事例というか箇所を指摘するのは、たぶんできるんだろうけど。それの組合せになると事実上試験しきれなくなるんじゃないかな?# 規模が中以上を想定しています。
とはいえ、実装の子細の違いとかは試験仕様を通るなら問題ない、で通るだろうし、状況しだいかなぁ。
>コードカバレッジという言葉はご存知ですか?
全ての「状態」を網羅できるか、と書いたのですが?コードカバレッジが100%だったとして、それが満たせているとでも思っているのかな?
学校で書くようなHelloWorldレベルの小作とか真の意味での純粋関数型言語とかならともかく、コードカバレッジで全ての状態を網羅できると思うのは浅はか過ぎないかい?
横から参加するけど、ここでいう「状態」は単にそこを通過するってだけじゃなくて、性能要件も含んでると思って読んでた。機能要件でカバレッジ100%ってのは前提で、その上で問題になる品質ってのは高負荷時の挙動とかそのへんじゃないのかなって。
C0 C1 C2 という言葉をご存知ですか?
「俺様にできないことがお前ごときにできるわけがない」まで読んだ。
すべての品質を担保する試験を書いてる暇があれば、それを実装する時間は、コミュニケーションにかかるコストを考えれば大した差は無いとおもうよ。細かく仕様を出すということは、プログラムを書く行為と同等だからね。信頼と委譲が必要という意見に同意。
逆でしょう?同じ試験仕様書を通ればどのソフトも同じ品質です。は正しいです。試験仕様書から漏れた項目があってAでは対応しているがBでは対応していなかった場合それは「試験仕様書の品質」が悪かっただけでソフトウェアの品質としては同じですよ。
ソフトウェアの品質とはテストの結果で得られるものであって書いてあるから得られるものじゃないです。
そうでしょうか?
定量的に測れるところだけで勝負ということは、結局コスト競争だけに終始して構わない、という宣言でもある。そういうのって作り捨て(あとで増強・改良しようとも思わない)のアプリではいいかもしれませんが、のちのち拡張して使うことを考えていれば、テストでは測りきれない「品質」というものもある。
そういうものをアウトソースするな、という意見ならわからなくもないですが。
機能実現性やバグ数という意味ならそうでしょうねー
しっかし100行で表現できるコードを5000行に膨らまされた時にはどーしようかと思った orz
>機能実現性やバグ数
それ以外のものをどう評価する?評価する意味ある?確かに頭悪いなーというときはあるけど、どっかで割り切らないとしょうがないんだよね。
試験仕様に表しにくい抽象的にしか評価できない品質項目はありますよね
それをワリキリでやるか、ガチガチルールで抑えるか、どんぶり指標で抑えるかの方法論はともかく何かしら実践しないと
アウトソースに出して納められた物を将来に渡ってメンテするのは誰?になっちゃいます
まぁ、パフォーマンステストとかにも現れないならソレは受け入れるしかないわな
いまどき行数で価格なんか量らないしね
>しっかし100行で表現できるコードを5000行に膨らまされた時にはどーしようかと思った orz
最終的に生成されるオブジェクトの許容サイズなども仕様書に含めておけばよかったのでは?
非機能項目で差が出ることはよくありますよ。ソースの可読性は代表的な非機能項目。しかし品質としては重要。
ならばそれも試験仕様に加えればよろし。
受け入れテスト工数が膨らんでアウトソースにする意味がなくなる。
つまり、全てを網羅した試験でない限り、通ったからと言って同じ品質とは言えない。でも、「同じ試験仕様書を通れば」という記述はその試験仕様書が全てを網羅していると表現していない。ソースの全てのルートを通るとかいう単純な話ではなく、全てを想定した試験仕様があれば、通れば同じ品質と言えるが、それは即ち、そうやって試験を通ったプログラムは無謬であることに他ならない。
さて、そんな試験仕様を書ける奴が、世の中に一体どんだけいるかな?
お前以外は全員できるよ。
例えば、非負整数nについて必ずn+1を返す関数であることはどうやって確かめるの?ほかにも、複数のスレッドによる加算が必ずアトミックに行われることなど
ブラックボックステストしかやったことない人?
>ブラックボックステストしかやったことない人?
もしかして、>>コードカバレッジという言葉はご存知ですか?という寝言を書いた人と同じ人?
あまりに低レベルなので、もう出てこないでほしいのですが。あなたのレベルだと、とりあえず「バグのないことを証明」あたりでぐぐると良いかも。
自分の理解力を越えているものは低レベルですか。簡単そうな生き方ですね。
1.想定される入力の最小値と最大値で戻り値が正常である事を確認する。最大値は無限とか言うなよ。 馬鹿なら最小値-最大値でループを回せ。 (想定されない入力についての動作はまた別のテストで確認)2.問題が想定される条件を網羅してその条件でスレッドを実行する
上にもでてるけど、基本的にさ、「俺様にできないことがお前ごときにできるわけがない」って言い張ってるだけでしょ。で、「お前以外は全員できるよ」という事なんだよ。
1.最小値-最大値でループを回さなかったとしたら、想定される入力の最小値と最大値の間の値で、戻り値が正常である事を確認したわけじゃなくて、単なる期待に過ぎないのでは?2.たまたま正常に動作したとしても、正しい同期制御ができているとは限らないのでは?
>上にもでてるけど、基本的にさ、「俺様にできないことがお前ごときにできるわけがない」って言い張ってるだけでしょ。>で、「お前以外は全員できるよ」という事なんだよ。上の文と下の文の論理に飛躍があるようですよ。私にできないことがあなたにできても何の不思議もないですが、それは私とあなたとを入れ替えても同じことが言えるのですよ。
そこまでいくと試験という行為範囲に収まらずに、設計するという行為と不可分なんじゃないかなあ。
外注先をそのへんで信用できないなら、作成中コードのレビュー工数はマネージメント工数として積むべきものよね。
>ソースの可読性そういう項目は評価に客観性が欠けるんだよね。客観性を持たせるならば、最初に規約でガチガチにして、規約に反しているかどうかしかでしか判断できない。そうすると、100行ですむところが5000行になったりするんですよ。
で、「ぬるぬる動く」とかいう数値化できない指標は一顧だにされないからAppleはおろかサムスンにすら完敗すると。
Appleはともかく、サムスンを引き合いに出すのは疑問。googleじゃね?そうすると、ほら、あんまりくやしくない。
googleだと「ぬるぬる動く」という項目も自動で評価可能にしているかも。
まあ正直言って一連の流れは「開発作業は複数で分担しなければならない」という観念から生じているので正直、クソだとは思っています。
それはソースコードの品質であって動作に影響がでないのならばソフトウェアの品質に影響はないよ
ソフトウェアの品質にソースの品質が含まれない世界なんてあるんですかね?ゲームのパッケージを買うんならともかく、アウトソースで。
アウトソースだからこそ、ソースの品質程度の事は割り切るべきだと思うけどね。割り切れないか、品質を管理できないなら、それはアウトソースすべきものじゃなかったという事だ。それこそ、ゲームのパッケージを買うのと同じ事なんだからさ。
アウトソースだからこそ、そういう部分の品質の体験談を共有しておくことが重要なのでは? と逆方向に思いますが。
このスレッドを見てると、日本の「IT産業」がダメな理由が凝縮されている気がする
(a) テスト仕様もまともに書かず、常識的な品質として○○すべきだ(b) テスト仕様を満たしていれば、どんなソフトウェアも同じ品質だ
aについては同質幻想であって論外。bについては十分条件しか述べておらず、これで品質を議論するのもエンジニアとして不見識と言いたいですね。
> このスレッドを見てると、日本の「IT産業」がダメな理由が凝縮されている気がする
今まで見たことがある中国 (上海周辺) 、北米 (西海岸) のIT産業の大半の企業は同じような問題を抱えていますし、これらの問題を抱えていない企業は数えるほどしか知りませんが、日本のIT産業だけに限定しているのはなぜでしょう。この手の問題がまれな国や地域をご存知でしたらぜひ教えて下さい。
いや、外部に出すってのはそういう事なんだよ。ただね、現実にそれが出来るだけの情報と裁量を与えている例が実は少ない。他人事みたいに考えているけど、ちょっと前のスレに有った在宅勤務でも大まかにはいっしょ。
サイズや速度の要件があるならとうぜんそれも要求に入れる必要はある。で、「わたしはこういうモノなら満足できます」と渡して後は相手に任せる。そして上がったものを受け入れ時に判断して、OKなら今後も使いNGなら契約を切る。オフショア開発で気に入らなからと言って、国内下請けの様にデスマを押し付けるのは難しいから、その覚悟と体制を組めないなら最初から手を出すべきじゃない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
プログラミングは設計 (スコア:3)
ビルド寸前までコードを書く行為はすべて設計です。
設計を外部に任せるためには、相応の信頼と権限の委譲が必要です。
納得行くものが出来上がらずに細かな指示をしていくというのは、自分で設計する部分を増やしているだけです。
Re:プログラミングは設計 (スコア:0)
同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質です
と宣言してたバカがいたな
Re: (スコア:0)
あなたには品質を担保できる試験仕様を書く能力がないということですね。
あなたの能力ではできないことでも、普通にこなせる人が世の中にはいるんですよ。
Re:プログラミングは設計 (スコア:1)
そうそう、「仕様を書く能力」は重要。
この能力がないのに口でアレコレ言えば下が理想のモノを作ってくれると思い込んでる上司に当たるとサイアク。
そいつが思い描いていないものができるとヒス起こすし。
another side:
懇切丁寧に説明しててもろくなもん作らない、今度来た奴ヒドイわ。
#どっちもあるな。
Re: (スコア:0)
ちょっと疑問。
なぜこの流れでここで皮肉を書く必要が。
Re: (スコア:0)
じゃ、試験仕様書を作るための要求品質を定義する能力がないってことですね。
または、作られた製品が過剰品質ってことかな
Re: (スコア:0)
>あなたには品質を担保できる試験仕様を書く能力がないということですね。
>あなたの能力ではできないことでも、普通にこなせる人が世の中にはいるんですよ。
むしろ、あなたが、試験仕様で(有限のリソースの中で)全ての状態を網羅できるという幻想を持っているバカとしか思えないのですが。
Re: (スコア:0)
コードカバレッジという言葉はご存知ですか?
Re:プログラミングは設計 (スコア:2)
はい、コードカバレッジという言葉も
それが完全な試験手法ではないことも
知ってるけど。
そして、チューリング言語で書かれたプログラムを
完全に試験する一般的な術はないことも知ってる。
Re:プログラミングは設計 (スコア:1)
カバレッジが100%で、仮にバグが0であったとしても、スパゲッティプログラムは書けるんだな。
コードの品質と現在残っているバグの個数とテストのカバレッジに相関はあってもイコールではない。
>同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質です
と言った奴はそんな初歩的なことも知らないのだから、大馬鹿者としか言いようがないのです。
Re: (スコア:0)
うーん。カバレッジで網羅できればいいんですけどねー。たとえば
・既知の脆弱性が存在しない
・絶対にリソースリークが発生しない
ことを、試験仕様にすべて表現できますかね?
Re: (スコア:0)
それは
・チェックすべき既知の脆弱性を挙げる事ができない
・リソースリークが発生しないという事を判断する条件を規定できない
とみなしていいかな?
3以上を数えられない土人かおまえは。
品質を担保するのが試験の役目なんだから、試験しない項目は品質とは関係ないと言ってるのと同じなんだよ。
Re:プログラミングは設計 (スコア:1)
つーてもまあ、ソースの全システム機能呼び出しが発生する(かもしれない)箇所すべてで、システムにも相応の負荷をさまざまなパターンでかけるとか、難しいよ。
# OSやライブラリ側がある負荷以上になると、問題になりうる挙動をしめす。とかあるだろうし。
個々の事例というか箇所を指摘するのは、たぶんできるんだろうけど。それの組合せになると事実上試験しきれなくなるんじゃないかな?
# 規模が中以上を想定しています。
とはいえ、実装の子細の違いとかは試験仕様を通るなら問題ない、で通るだろうし、状況しだいかなぁ。
M-FalconSky (暑いか寒い)
Re: (スコア:0)
>コードカバレッジという言葉はご存知ですか?
全ての「状態」を網羅できるか、と書いたのですが?
コードカバレッジが100%だったとして、それが満たせているとでも思っているのかな?
Re: (スコア:0)
学校で書くようなHelloWorldレベルの小作とか真の意味での純粋関数型言語とかならともかく、
コードカバレッジで全ての状態を網羅できると思うのは浅はか過ぎないかい?
Re: (スコア:0)
横から参加するけど、ここでいう「状態」は単にそこを通過するってだけじゃなくて、性能要件も含んでると思って読んでた。
機能要件でカバレッジ100%ってのは前提で、その上で問題になる品質ってのは高負荷時の挙動とかそのへんじゃないのかなって。
Re: (スコア:0)
C0 C1 C2 という言葉をご存知ですか?
Re: (スコア:0)
「俺様にできないことがお前ごときにできるわけがない」まで読んだ。
Re: (スコア:0)
すべての品質を担保する試験を書いてる暇があれば、それを実装する時間は、コミュニケーションにかかるコストを考えれば大した差は無いとおもうよ。細かく仕様を出すということは、プログラムを書く行為と同等だからね。信頼と委譲が必要という意見に同意。
Re: (スコア:0)
逆でしょう?
同じ試験仕様書を通ればどのソフトも同じ品質です。は正しいです。
試験仕様書から漏れた項目があってAでは対応しているがBでは対応していなかった場合
それは「試験仕様書の品質」が悪かっただけでソフトウェアの品質としては同じですよ。
ソフトウェアの品質とはテストの結果で得られるものであって書いてあるから得られるものじゃないです。
Re:プログラミングは設計 (スコア:1)
そうでしょうか?
定量的に測れるところだけで勝負ということは、結局コスト競争だけに終始して構わない、という宣言でもある。
そういうのって作り捨て(あとで増強・改良しようとも思わない)のアプリではいいかもしれませんが、のちのち拡張して使うことを考えていれば、テストでは測りきれない「品質」というものもある。
そういうものをアウトソースするな、という意見ならわからなくもないですが。
Re: (スコア:0)
機能実現性やバグ数という意味ならそうでしょうねー
しっかし100行で表現できるコードを5000行に膨らまされた時にはどーしようかと思った orz
Re: (スコア:0)
>機能実現性やバグ数
それ以外のものをどう評価する?評価する意味ある?
確かに頭悪いなーというときはあるけど、どっかで割り切らないとしょうがないんだよね。
Re: (スコア:0)
試験仕様に表しにくい抽象的にしか評価できない品質項目はありますよね
それをワリキリでやるか、ガチガチルールで抑えるか、どんぶり指標で抑えるかの方法論はともかく
何かしら実践しないと
アウトソースに出して納められた物を将来に渡ってメンテするのは誰?になっちゃいます
Re:プログラミングは設計 (スコア:2)
Re: (スコア:0)
まぁ、パフォーマンステストとかにも現れないならソレは受け入れるしかないわな
Re: (スコア:0)
いまどき行数で価格なんか量らないしね
Re: (スコア:0)
>しっかし100行で表現できるコードを5000行に膨らまされた時にはどーしようかと思った orz
最終的に生成されるオブジェクトの許容サイズなども仕様書に含めておけばよかったのでは?
Re: (スコア:0)
非機能項目で差が出ることはよくありますよ。
ソースの可読性は代表的な非機能項目。しかし品質としては重要。
Re: (スコア:0)
ならばそれも試験仕様に加えればよろし。
Re: (スコア:0)
受け入れテスト工数が膨らんでアウトソースにする意味がなくなる。
Re: (スコア:0)
つまり、全てを網羅した試験でない限り、通ったからと言って同じ品質とは言えない。
でも、「同じ試験仕様書を通れば」という記述はその試験仕様書が全てを網羅していると表現していない。
ソースの全てのルートを通るとかいう単純な話ではなく、全てを想定した試験仕様があれば、通れば同じ品質と言えるが、それは即ち、そうやって試験を通ったプログラムは無謬であることに他ならない。
さて、そんな試験仕様を書ける奴が、世の中に一体どんだけいるかな?
Re: (スコア:0)
お前以外は全員できるよ。
Re: (スコア:0)
例えば、非負整数nについて必ずn+1を返す関数であることはどうやって確かめるの?
ほかにも、複数のスレッドによる加算が必ずアトミックに行われることなど
Re: (スコア:0)
ブラックボックステストしかやったことない人?
Re: (スコア:0)
>ブラックボックステストしかやったことない人?
もしかして、
>>コードカバレッジという言葉はご存知ですか?
という寝言を書いた人と同じ人?
あまりに低レベルなので、もう出てこないでほしいのですが。
あなたのレベルだと、とりあえず「バグのないことを証明」あたりでぐぐると良いかも。
Re: (スコア:0)
自分の理解力を越えているものは低レベルですか。
簡単そうな生き方ですね。
Re: (スコア:0)
1.想定される入力の最小値と最大値で戻り値が正常である事を確認する。最大値は無限とか言うなよ。
馬鹿なら最小値-最大値でループを回せ。
(想定されない入力についての動作はまた別のテストで確認)
2.問題が想定される条件を網羅してその条件でスレッドを実行する
上にもでてるけど、基本的にさ、「俺様にできないことがお前ごときにできるわけがない」って言い張ってるだけでしょ。
で、「お前以外は全員できるよ」という事なんだよ。
Re: (スコア:0)
1.最小値-最大値でループを回さなかったとしたら、想定される入力の最小値と最大値の間の値で、戻り値が正常である事を確認したわけじゃなくて、単なる期待に過ぎないのでは?
2.たまたま正常に動作したとしても、正しい同期制御ができているとは限らないのでは?
>上にもでてるけど、基本的にさ、「俺様にできないことがお前ごときにできるわけがない」って言い張ってるだけでしょ。
>で、「お前以外は全員できるよ」という事なんだよ。
上の文と下の文の論理に飛躍があるようですよ。
私にできないことがあなたにできても何の不思議もないですが、それは私とあなたとを入れ替えても同じことが言えるのですよ。
Re: (スコア:0)
そこまでいくと試験という行為範囲に収まらずに、設計するという行為と不可分なんじゃないかなあ。
Re: (スコア:0)
外注先をそのへんで信用できないなら、作成中コードのレビュー工数はマネージメント工数として積むべきものよね。
Re: (スコア:0)
>ソースの可読性
そういう項目は評価に客観性が欠けるんだよね。客観性を持たせるならば、最初に規約でガチガチにして、規約に反しているかどうかしかでしか判断できない。
そうすると、100行ですむところが5000行になったりするんですよ。
Re: (スコア:0)
で、「ぬるぬる動く」とかいう数値化できない指標は一顧だにされないからAppleはおろかサムスンにすら完敗すると。
Re: (スコア:0)
Appleはともかく、サムスンを引き合いに出すのは疑問。googleじゃね?
そうすると、ほら、あんまりくやしくない。
googleだと「ぬるぬる動く」という項目も自動で評価可能にしているかも。
まあ正直言って一連の流れは「開発作業は複数で分担しなければならない」という観念から生じているので
正直、クソだとは思っています。
Re: (スコア:0)
それはソースコードの品質であって動作に影響がでないのならばソフトウェアの品質に影響はないよ
Re:プログラミングは設計 (スコア:2)
Re: (スコア:0)
ソフトウェアの品質にソースの品質が含まれない世界なんてあるんですかね?
ゲームのパッケージを買うんならともかく、アウトソースで。
Re:プログラミングは設計 (スコア:1)
アウトソースだからこそ、ソースの品質程度の事は割り切るべきだと思うけどね。
割り切れないか、品質を管理できないなら、それはアウトソースすべきものじゃなかったという事だ。
それこそ、ゲームのパッケージを買うのと同じ事なんだからさ。
#存在自体がホラー
Re: (スコア:0)
アウトソースだからこそ、そういう部分の品質の体験談を共有しておくことが重要なのでは? と逆方向に思いますが。
このスレッドを見てると、日本の「IT産業」がダメな理由が凝縮されている気がする
(a) テスト仕様もまともに書かず、常識的な品質として○○すべきだ
(b) テスト仕様を満たしていれば、どんなソフトウェアも同じ品質だ
aについては同質幻想であって論外。bについては十分条件しか述べておらず、これで品質を議論するのもエンジニアとして不見識と言いたいですね。
Re: (スコア:0)
> このスレッドを見てると、日本の「IT産業」がダメな理由が凝縮されている気がする
今まで見たことがある中国 (上海周辺) 、北米 (西海岸) のIT産業の大半の企業は同じような問題を抱えていますし、
これらの問題を抱えていない企業は数えるほどしか知りませんが、日本のIT産業だけに限定しているのはなぜでしょう。
この手の問題がまれな国や地域をご存知でしたらぜひ教えて下さい。
Re: (スコア:0)
いや、外部に出すってのはそういう事なんだよ。
ただね、現実にそれが出来るだけの情報と裁量を与えている例が実は少ない。
他人事みたいに考えているけど、ちょっと前のスレに有った在宅勤務でも大まかにはいっしょ。
サイズや速度の要件があるならとうぜんそれも要求に入れる必要はある。
で、「わたしはこういうモノなら満足できます」と渡して後は相手に任せる。
そして上がったものを受け入れ時に判断して、OKなら今後も使いNGなら契約を切る。
オフショア開発で気に入らなからと言って、国内下請けの様にデスマを押し付けるのは難しいから、
その覚悟と体制を組めないなら最初から手を出すべきじゃない。