オブジェクト指向システムの設計 170

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net] オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ オブジェクト指向は役割でオブジェクトに分割するものであって 処理で分割するものではない。 175 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:12:26.96 ID:T7FoO03Y.net] 俺の理解 ID:qX3K4vQyの主張はコードからテストケース作る ID:IPFd2Mdrの主張は設計書からテストケース作る コードが設計書に書かれてることを満たしてるかどうかって コードから作ってたらわからないのでは……って疑問が…… なぜかコードだけ、設計書だけの0か100かに見えてしまってるので 勘違いしてたらごめん 176 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:13:23.53 ID:qX3K4vQy.net] >>170 > うん。だからコードを直そうね。 > テスト漏れじゃないね。 コードを直さないとどうなる？ 同じ品質を保つにはテストを増やす必要があるよね？ えーと、それがコーディングによってテスト項目は 変わるってことだよねｗ コーディングによってテスト項目が増えるから コーディングを直すんだよね？ｗ 177 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:14:50.74 ID:55Jnw5v7.net] >>169 どうにでも好きなように組んだらいいよ チェック項目は変わらない オブジェクト指向でも関数型でも これが設計の本質だ 単にソースコードに書く場所が違うだけ それがオブジェクト指向 こんなもんにマジになっちゃってどうするの? っていうIT業界の黒歴史 178 名前：デフォルトの名無しさん [2016/06/02(木) 01:16:20.73 ID:IPFd2Mdr.net] >>173 >>166 そりゃバグがあることが判明したらテストを追加すべきだろうね。 でも、そもそもテストが不足していたということじゃないね。 179 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:18:59.63 ID:qX3K4vQy.net] >>172 俺の意見としては、テストとは別にコードレビューが必須であるということ。 仕様書からテストをおこすのは問題ないんだが、 そのテストで品質が保てるかどうかは コードで左右される。 コードが汚ければいくらまともなテスト行ったとしても それで品質を保つことは出来ない。 俺は品質を保つことを第一に考えてるので コードを直さずに品質を保つならばテスト項目� 180 名前：ｪ増えてしまうという話をしてる。 だからテスト項目を増やさずに品質を保つために、コードを直しましょうという話をしている。 で、最初の疑問「コーディングによってテスト項目は変わるか？」の 答えは、（品質を保つことを前提にすると）コーディングによってテスト項目は変わる。 悪いコードだと（品質を保つために）テスト項目が増えてしまう。だからコーディングを直しましょう。 [] [ここ壊れてます] 181 名前：デフォルトの名無しさん [2016/06/02(木) 01:21:24.41 ID:IPFd2Mdr.net] >>176 コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。 そんなのテスト作成とは関係ない。 182 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:23:15.23 ID:qX3K4vQy.net] >>175 > そりゃバグがあることが判明したらテストを追加すべきだろうね。 リリースした後で、バグが有りました。すいません。ですむ会社なら それでもいいけどさぁｗ 「ちゃんとテストしたの？」の答えに テストは不足していません！ちゃんとテストしました！ ちゃんとテストしたのに、コードが悪かったんです！ ですむなら、それでもいいけどさぁｗ 理想の世界であれば、テストが不足してないのは事実だろうが、 そのテストで十分であるためには、コードが綺麗でなければならず、 コードが汚ければ、多くのテストが必要になるから コードレビューをして綺麗なコードにしましょうや。 それができて初めて、テストする意味が生まれる。 183 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:24:18.99 ID:qX3K4vQy.net] >>177 > コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。 だから何度もそう言ってるだろうが。 人の話聞けよｗ 184 名前：デフォルトの名無しさん [2016/06/02(木) 01:24:53.24 ID:IPFd2Mdr.net] >>178 だからさ、要件の境界とは違うところでコードがアホ過ぎるせいでバグがあったとして見つける手段は？ 見つける手段がないのに直そうと言っても意味ない。 185 名前：デフォルトの名無しさん [2016/06/02(木) 01:25:55.40 ID:IPFd2Mdr.net] >>179 ？？ だったらいちいち反論すんなよ。 186 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:26:39.31 ID:qX3K4vQy.net] 俺がはテストが足りないって言ってるんじゃないんだぜ？ 品質を保つことを前提にするならば、 コードが汚ければ、品質を保つために必要なテストが増えてしまうから、 まずコードレビューしてコードを綺麗にしましょうって話。 コードが綺麗な状態であって初めて、仕様書から起こしたテストで十分だと言える。 187 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:29:14.56 ID:qX3K4vQy.net] >>181 > だったらいちいち反論すんなよ。 お前が反論してるんだろｗ っていうかお前のは反論じゃない。 俺が言っていることと違うことをぶつけているだけ。 俺が言ってるのは、コードが汚いならば（品質を保つために） 必要なテストは増えるって話。 コードが汚くても、テストは増やさないで品質が保てるような 話をしているから、その発想は抜けがあるよってこと。 188 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:29:26.96 ID:soSMk704.net] そんなときこそユニットテスト コード改変の前後でエンバグしたかどうかがすぐわかります なおユニットテストそのものの品質を保つかが課題 189 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:30:23.03 ID:T7FoO03Y.net] >>176 了解 回答ありがとう 190 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:30:30.71 ID:qX3K4vQy.net] >>180 > 見つける手段は？ それもテスト前にコードレビューするって何度も言ったはずだが？ 汚いコードは直さないと、テストした所で効果は低い 191 名前：デフォルトの名無しさん [2016/06/02(木) 01:31:11.16 ID:IPFd2Mdr.net] >>183 本来的にはテストは要件にしたがって動作することを確認するためのもの。 コードがきれいか汚いかとか関係ない。 192 名前：デフォルトの名無しさん [2016/06/02(木) 01:32:06.67 ID:IPFd2Mdr.net] >>186 コードレビューで見つかったなら直せ。以上。 テストとの直接の関係はない。 193 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:33:09.51 ID:qX3K4vQy.net] >>187 > 本来的にはテストは要件にしたがって動作することを確認するためのもの。 その確認の手間がコードによって変わってしまうんだよ。 すでにコードで例示したけど？ 194 名前：デフォルトの名無しさん [2016/06/02(木) 01:33:30.12 ID:dD1ozz1q.net] Haskellならテスト要らないですよ？ コンパイルできた時点でバグが無いことが保証されるから。 195 名前：デフォルトの名無しさん [2016/06/02(木) 01:34:23.43 ID:IPFd2Mdr.net] >>189 コードがアホなだけ。テストではどうしようもない。 と結論が出てる。 196 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:34:39.66 ID:55Jnw5v7.net] >>189 だから変わらないって 本来は取りうる値の範囲をすべてチェックするんだから 197 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:34:52.13 ID:qX3K4vQy.net] >>188 「直接の関係はない」ってことは やっぱり間接的に関係があるって認めるんだｗ そりゃコードによって品質を保つための テストは変わりますからねｗ バグが有るかどうか知ったこっちゃない。 俺はテストをちゃんとやった。 テストしたのに漏れたのはコードが悪いんだ！ ですむなら良い世界だねｗ 198 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:35:31.60 ID:55Jnw5v7.net] 勝手に間引いてるのはテスターの責任 199 名前：デフォルトの名無しさん [2016/06/02(木) 01:36:12.80 ID:IPFd2Mdr.net] >>193 コードレビューで問題が見つかったらテストケースを追加してもいいよねってだけ。 200 名前：デフォルトの名無しさん [2016/06/02(木) 01:36:59.90 ID:dD1ozz1q.net] これからは関数型ですよ。 Haskell以外淘汰されます。 201 名前：デフォルトの名無しさん [2016/06/02(木) 01:37:36.91 ID:IPFd2Mdr.net] >>196 Haskellとか既に淘汰されてるんだが。 202 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:38:47.83 ID:qX3K4vQy.net] >>192 > 本来は取りうる値の範囲をすべてチェックするんだから うん、ネタなのは分かってるよ（笑） 分かってて聞くけど、ある数値を二乗する関数があったとして Rubyで取りうる値の範囲はどうなるかい？ なんでRubyと言ったかというと、RubyではIntの範囲を超えると 自動的にBignumに拡張されるからとても大きな整数を扱えるんだぜ！ 203 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:39:44.45 ID:qX3K4vQy.net] >>195 > コードレビューで問題が見つかったらテストケースを追加してもいいよねってだけ。 誰がやんの？ テスターのお仕事？ 204 名前：デフォルトの名無しさん [2016/06/02(木) 01:40:36.22 ID:IPFd2Mdr.net] >>199 コードレビューって自分で言ったんだから知ってるだろ。 分かってることをいちいち聞くな。 205 名前：デフォルトの名無しさん [2016/06/02(木) 01:40:47.43 ID:dD1ozz1q.net] Haskell使えばテスト必要ないですよ？ 206 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:42:30.76 ID:55Jnw5v7.net] スレの本題にくっつけると コードの記述方法でチェック項目は変わらない つまりオブジェクト指向でも関数型でも品質は上がらない 言い換えればコードの記述方法で品質は上がらない 品質を上げるにはしっかり仕様書を書いて しっかり書いた仕様書からテスト仕様書を起こすこと ソースの記述方法は品質を決定する計算式に入ってません（笑） おｋ? 207 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:43:13.49 ID:qX3K4vQy.net] >>200 せやね。 コードが悪ければコードレビューで テスト項目が追加される。 コードが悪ければ、テスト項目が追加される。 おや？ コーディングによってテスト項目が変わるって話に戻ったか。 208 名前：デフォルトの名無しさん [2016/06/02(木) 01:44:21.91 ID:IPFd2Mdr.net] >>203 「追加してもいい」 この意味が分からんの？ 日本語からやり直せ。 209 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:46:16.79 ID:55Jnw5v7.net] 今回もオブジェクト指向が幻想技術ということが決定したな 210 名前：デフォルトの名無しさん [2016/06/02(木) 01:46:33.24 ID:IPFd2Mdr.net] >>205 基地外 211 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:47:36.18 ID:3RkkmY6H.net] さて、スレが流れた所で話を戻すかｗ >>140 > どう組んでもチェック項目は絶対同じ数と内容になる そうでもないというか、その発想は抜けがあるよ。 たとえば数値が偶数か奇数かを文字列で返す関数があったとしよう。 function foo(value) { 　　return (value % 2 == 0) ? 'even' : odd'; } これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。 だけどさ、関数の中身がこうなっていたらどうする？ （1レスに収めるためにわざと改行せずに一行にしたけどそこは無視して） function foo(value) { 　　var i = value % 10; 　　if (i == 0) return 'even'; if (i == 1) return 'odd'; 　　if (i == 2) return 'even'; if (i == 3) return 'odd'; 　　if (i == 4) return 'even'; if (i == 5) return 'odd'; 　　if (i == 6) return 'odd'; if (i == 7) return 'odd'; 　　if (i == 8) return 'even'; if (i == 9) return 'odd'; } わざとバグを入れたけど、バグが無ければこの関数は仕様どおりに動くしfoo(0)とfoo(1)のテストにも通る。 だけどこの関数にはバグがあるし、だからチェック項目は2つでは十分ではないということになる。 コーディングの仕方でチェック項目数は変わらないっていうのは、半分は正しい。 もし2つあるコードのどちらも同じぐらい正しい品質であればその通り。 だけどこの例の場合は違う。2つのテストでは足りないということになっている。 この例のあるべき姿はチェック項目数を増やすのではなくて、コードをリファクタリングしてシンプルにすること。 そうすることでチェック項目は2つになるわけだが、ここまでの話で明らかなように 「コーディングの仕方でテスト項目は変わる」というか「悪いコードだとバグがないことを担保するためのテスト項目は増える」 212 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:49:05.94 ID:3RkkmY6H.net] 何だ俺、最初から一貫して同じこと言ってるやんｗ 213 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:50:22.82 ID:55Jnw5v7.net] >>207 だからvalの取りうる範囲チェックするだろ 中間値だけとか間引くのはテスターが勝手にやってるだけの話 チェック項目は変わらない 214 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:51:43.92 ID:3RkkmY6H.net] >>209 だから、そのvalの取りうる値ってなんだよ？ｗ >>198の質問にも答えてないぞお前ｗ 215 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:53:10.76 ID:ehI/NdEG.net] >>176 完全に横だが、、、 そちらの意見自体に文句はない。つまり、コード品質最優先で同意だ。 付け加えるとしたら、>>143の例ならカバレッジで確認できる。 つまりC1(方言かもしれんが各分岐）まで含めれば例示されたバグは落とせる。 あと、仕様から起こしたテストを一通りやらないと「実装忘れ」を検出できない。 例えば、関数電卓を作ったとして、色々ある関数の一つを実装し忘れたとか。 実装漏れをテストではなくコードレビューで落とすことは出来るが、これはポリシーの問題となる。 仕様から起こしたテストで品質が上がるかというと、多分無理だ。これは競合を落とせない。 各競合を全部コードレビュー時にテストに追加するという手もあるが、これは追加漏れが発生する。 だから品質を上げるためには結局ランダムテストしかないと俺は思っている。 216 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:55:40.16 ID:55Jnw5v7.net] >>210 仕様書に書いてあるだろ? ないの? そしたら不具合ですらないんじゃない? 217 名前：デフォルトの名無しさん [2016/06/02(木) 02:01:57.34 ID:IPFd2Mdr.net] >>211 カバーできてないことが判明 コードを直す テストを追加するかは任意 218 名前：デフォルトの名無しさん [2016/06/02(木) 02:03:26.51 ID:IPFd2Mdr.net] >>211 ランダムテストって謎。 ランダムテストでアホなコードが漏れたらって話だろ。 なんでランダムテストさえすればアホなコードがすべて網羅できるって前提なんだよ？ 219 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 02:25:10.08 ID:ehI/NdEG.net] >>213-214 いや、複数箇所に冗長に記述があった時、それらが整合しているかだろ？ 見た瞬間分かればいいけど、クラスをまたいでいたりすると単純には削除できないケースもある。 この場合はカバレッジ100%なら整合している可能性が高い事は言える。 （ただし二重に冗長な場合は無理だが） ランダムテストは動作の確認とカバレッジを稼ぐため。つまりバグの検出。 ランダムテスト自体では「品質の高い＝美しいコード」は得られない。 ただ、コードの品質って大前提として「バグがないこと」だろ？(コードが美しいことではなくて) これについてはランダムテストが一番だと思っている。 すまんがもう寝る。 220 名前：デフォルトの名無しさん [2016/06/02(木) 03:00:45.20 ID:dD1ozz1q.net] あ、逃げた。 221 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 04:13:03.69 ID:soSMk704.net] マジレスするとECPで大抵のテスト分けは解決できる あとは重箱の隅をつつく価値があるかどうか 222 名前：デフォルトの名無しさん [2016/06/02(木) 04:24:49.52 ID:dD1ozz1q.net] マジレスするとHaskell使えばテストは必要ない。 テストでバグを発見できるというのは甘え。 223 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 06:09:23.71 ID:a5hqyyy7.net] そう Haskellを使っていれば交通事故を起こさない自動車だって作れた なお完成は２４世紀ごろを予定しております 224 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 06:54:53.87 ID:ehI/NdEG.net] すまぬ。「ランダムテスト」は方言で、標準語ではどうやら「自動テスト」と呼ばれるようだ。 (モデルを作成し、ランダムな入力を食わせて出力をチェックする） 混乱させてすまん。 225 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 08:36:32.58 ID:jj0I32l4.net] >>207 ＞たとえば数値が偶数か奇数かを文字列で返す関数があったとしよう。 ＞これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。 充分じゃない、テスト仕様書がそうなってたらテスト仕様書書いた奴氏ねって言っていい、コードがどうなっているかはこの時点では関係ない 226 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 09:21:14.08 ID:qVro3+K+.net] >>218 あんたHaskell信者に見せかけたアンチだろｗ HaskellにはHaskellの良さがあるけど、俺は結局C++に戻ってきた。 最近はCまで戻ろうかと検討してる。 もしくはLispを試してみようかなと。 227 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 09:59:19.16 ID:9Sgsnltg.net] 設計=仕様書から書けるテストはブラックボックステストで、 コードから書けるテストはホワイトボックステスト。 ブラックボックステストで全ての取りうる値を入力するなんて非現実的だから、境界条件を考慮してテストセットを作る。 ホワイトボックステストはどれだけ網羅するかにもよるけど、条件分岐があったらその全てを通るテストセットを作る。 テストで得られる保証の度合いで言うならホワイトボックス>ブラックボックスなのは確かだけど、 中身まで見れる状態になっていないとホワイトボックステストは書けない。 開発プロセスがトップダウン方式だったりテスト駆動開発だと、書けるテストはブラックボックステストにならざるを得ない、という現実的な話。 そこで満足するか、更なる品質保証のためのホワイトボックステストを書くかはコストと相談しましょう。 Haskellでも同じ。テストを書く必要が無いのは依存型やRefinment typesを使える言語だけ。 228 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 10:42:12.02 ID:x8NBN55x.net] >>182 > コードが綺麗な状態であって初めて、仕様書から起こしたテストで十分だと言える。 その仕様書とやらが、コードをC0カバレッジできるレベルで書かれてるならそうだろうな。 229 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 10:43:30.50 ID:x8NBN55x.net] >>220 > すまぬ。「ランダムテスト」は方言で、標準語ではどうやら「自動テスト」と呼ばれるようだ。 いや、呼ばれない。自動テストとはマニュアルテストの反語。 230 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 10:58:37.56 ID:HMnON+Ay.net] >>220 QuickCheckって呼んでるわ 231 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 10:59:58.45 ID:qVro3+K+.net] 俺もそれのことかなと思った。 data-driven testing toolと呼ぶらしい。 232 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 11:24:00.72 ID:tJT0ttjQ.net] >>223 ある条件判定がfalseになったんだけど それが正しいか間違ってるかってどうやって判定すんの? ソースコードだけにその答えがあるの? 233 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 11:30:53.69 ID:x8NBN55x.net] >>228 > ある条件判定がfalseになったんだけど > それが正しいか間違ってるかってどうやって判定すんの? もっと具体的に。 234 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:11:08.77 ID:tJT0ttjQ.net] >>229 if（val==false） 235 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:34:31.31 ID:j1kGed0y.net] 朝。 さんさんと照り付ける太陽がS2715Hに映り込む。 純度100%のグレアモニター、S2715Hに自分の影がシャープに映り込むと、一日が始まる。 見ているものが正確で、映っているものは色が正確で、光量も正確。 よい生活はよい製品から得られる。 236 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:46:55.06 ID:x8NBN55x.net] >>230 それは一体どこの話なんだ？ そもそも、（単体/unit）テストが何なのか理解してるか？ 237 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:48:55.39 ID:tJT0ttjQ.net] >>232 unkoクラスのgetPPメソッド 238 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:50:25.29 ID:soSMk704.net] ifの中で真偽値と比較するコードなんて捨ててしまえ 239 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:54:33.11 ID:x8NBN55x.net] >>233 ということであれば、単体/unitテストでは、正しいも間違っているも判定しない。 240 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 14:26:28.50 ID:fuTkOmr9.net] このように意味のないことを堂々巡りに考えるのがOOP脳患者 無駄なことに時間を費やしたくない人は OOPが得意な部分だけを上手に利用することだけを考えておけばよい ほとんどの実用的な言語がマルチパラダイムを選択していることからもわかる通り 当たり前に得手不得手があるし 一つの考え方だけでうまくいくほど世の中単純ではないことは子供以外は誰でも知っている 241 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 16:51:41.22 ID:9Sgsnltg.net] >>228 コードだけ見て判断できるものもあるし、仕様書読まないと判断できないものもあるとしか言えない。 どっちを参照しても分からないなら作った人に聞くべきだけど、それはテストじゃなくてレビューになる。 それとも仕様書無しでソースあり、さあテストを書けって場合を考えている？ そんな苦役を振られたら、仕様書を作って欲しいのか確実に動かないバグを潰して欲しいのか確認するところから始めましょう。 242 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 18:22:00.20 ID:55Jnw5v7.net] >>237 いや、オブジェクト指向だとテストが減るとか言ってるアホがいたから 243 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 19:13:46.82 ID:IPFd2Mdr.net] >>238 オブジェクト指向の目的聞かれて回答しないままトンずらした奴だろ。 244 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 22:51:27.39 ID:3RkkmY6H.net] >>212 > 仕様書に書いてあるだろ? 仕様書には「整数」って書いてあるけど、 そしたら、無限にある整数を全部テストしろって話でしょう？ｗ 245 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:08:39.30 ID:soSMk704.net] そんなときこそFormal methods 複雑になるとUndecidableなのが玉に瑕 246 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:26:10.98 ID:55Jnw5v7.net] >>240 駄目な仕様書だな 上限も下限も定義されてないでモノなんて作れっかよ 全く仕事やってない証拠 オブジェクト指向なんかどうでもいいから 設計書きっちり書けよって話 247 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:37:42.96 ID:3RkkmY6H.net] >>242 > 駄目な仕様書だな > 上限も下限も定義されてないでモノなんて作れっかよ 作れるだろ？Pythonは無限リストを作れるのが特徴だ。 無限リストには上限も下限もない。 248 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:40:01.75 ID:3RkkmY6H.net] RubyのBigNumも上限も下限もないな。 docs.ruby-lang.org/ja/2.2.0/class/Bignum.html あえて言えばメモリサイズによる制限は受けるが、 じゃあメモリサイズいっぱいの桁数の数値（何桁だと思う？ｗ）を 全部テストするのかとｗ 249 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:58:48.20 ID:fuTkOmr9.net] ほら頭悪いでしょ 250 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:01:57.95 ID:57ESL53T.net] >>245 仕方ないんじゃないかな？ 馬鹿なんだからそういういちゃもんを付けるしかないんだと思うよ。 251 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:04:49.79 ID:fpUAqgyP.net] そもそもテストを行う実時間の問題だから 組合せ爆発でも起こしたら、本当に何万年とか かかってしまうのがテストなんだよね。 仕様書に上限や下限をつけた所でなんの対策にもなっていない。 252 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:08:30.87 ID:LbxBbQld.net] 下限や上限が決まっていたら、閾値界隈のテストできるでしょ 下限も上限も決まってなかったら本当にテストできない 下限も上限も決めないのは馬鹿 253 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:24:19.96 ID:4VbjelCP.net] 今話をしてるのはテストを行う実時間の話。 上限や下限が出てきたのは「整数」ではだめって文脈からだろ。 整数に上限や下限をつけた所でその範囲のすべての整数の 数は膨大なのだからテストに何万年もかかる。 そういう話をしてるのよ？わかる？ 254 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:34:26.00 ID:LbxBbQld.net] 閾値近辺だけテストすりゃよいだろ そりゃ君はクライアントに無限大を約束するらしいから無限のテストが必要なのかもしれないが それは君だけの話であって 我々は上限を設けて、その範囲内でだけ動くことを約束するって言ってるんだから 閾値のチェックだけで済むわけだ 255 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:42:42.22 ID:xWVfr+QL.net] ちょっとレベルが低過ぎる。 まったく意味がない話になってるからテストの話はいい加減にしろ。 オブジェクト指向設計と関係ないし。 256 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:55:16.41 ID:4VbjelCP.net] >>250 上限下限がないならば、閾値の内側だけを調べればいいんだよ。 257 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:57:20.52 ID:4VbjelCP.net] もう少し丁寧に書くわ 上限下限があるから、閾値近辺をテストしなければならないのであって、 上限下限がないならば、閾値近辺というのがそもそも存在しないので 任意の値でテストすれば十分 258 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 01:06:46.65 ID:LbxBbQld.net] そんで、メモリが足りなくて動かなかった時のクライアントへの説明はどうなるの？ 休日出勤するの？ 入力の段階で「数値が大きすぎます、100未満にしてください」って弾いとけば クライアントからしても何がダメだったか明確だろ 259 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 01:09:56.34 ID:4VbjelCP.net] > そんで、メモリが足りなくて動かなかった時のクライアントへの説明はどうなるの？ なんでメモリの話が関係してくるんだ？ いみわからんｗｗｗ 260 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 01:10:26.17 ID:4VbjelCP.net] > 入力の段階で「数値が大きすぎます、100未満にしてください」って弾いとけば ある数値を二乗する関数があったとして 「数値が大きすぎます、100未満にしてください」ｗｗｗｗｗ 261 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 01:11:03.14 ID:V5ojovFM.net] >>253 整数という条件だったら 0 とその前後、それから SCHAR_MIN, SCHAR_MAX, UCHAR_MAX, SHRT_MIN, SHRT_MAX, USHRT_MAX INT_MIN, INT_MAX, UINT_MAX, LONG_MIN, LONG_MAX, ULONG_MAX LLONG_MIN, LLONG_MAX, ULLONG_MAX とその前後の48パターンくらいはテストしとけ 262 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 01:13:46.42 ID:4VbjelCP.net] >>257 上限下限なくてもそれだけやればOKですよねｗｗｗ 263 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 01:42:13.61 ID:V5ojovFM.net] >>258 > 任意の値でテストすれば十分 こんな事言うより100倍マシ 264 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 01:56:10.56 ID:4VbjelCP.net] >>259 上限や下限がある場合は、その限界値で 動作を変えないといけないからテストする必要があるんだよ。 数学的に考えろ。nとn+1で何も違いがないならば、 そこはテストする必要ないんだよ。 265 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 02:08:57.65 ID:V5ojovFM.net] もういいよ 266 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 02:20:08.63 ID:4VbjelCP.net] いいならレスするなよｗ 267 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 02:53:40.31 ID:aDP5A1Yp.net] 結局>>217のECPと>>241のFormal methodsで済むところを 何レスも消費するんだから君たちはｗ 268 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 07:25:35.73 ID:G3tCMEbl.net] オブジェクト指向はなんの品質も上げないカス技術って現実を直視しろよ 269 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 10:24:41.45 ID:OvJcIN1K.net] >>264 じゃあ、どの技術が良いの？ 270 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 12:36:11.91 ID:PZUaPR2n.net] c++のオブジェクト機構をカス技術と言うのなら微妙にYes. 品質の向上≒自由度の制限って関係が成り立つので c++は自由度が大きすぎて使用者が意識して制限しないと 容易に巨大なウンコが出来上がる 271 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 13:01:13.49 ID:c8+13QXR.net] > オブジェクト指向はなんの品質も上げないカス技術って現実を直視しろよ >>264 みたいなバカが使うとね w 272 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 13:17:35.90 ID:LK0McYVX.net] >>264 煽るのもいい加減にしろ 己のキンタマでもかいて、糞して寝ろ 273 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 13:37:19.72 ID:TPst5vg3.net] >>265 プログラムを組める設計書や仕様書を書く技術 設計書や仕様書通りにプログラムを組む技術 雑誌やインターネットには載ってないけど 一番大事な技術です 274 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 13:39:23.11 ID:xWVfr+QL.net] 具体的な例で意見交換しようとしてもさぼってUMLすら書かない。 抽象的な話をすると言葉尻と曲解に基づいて無意味な言い争いをする。 なかなか意味のある会話にならないなあ。 少し前提に帰ると設計のときはUMLあるいはなんらかのモデリングをしてるよな？ モデリングすらしてないで書き込んでる中学生がちらほら見受けられるのは生暖かく見守るとして しっかりモデリングしてる印象を受けないんだが。 275 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 13:41:55.04 ID:xWVfr+QL.net] >>269 >>264-265のやり取りに対する回答になってない。 まともなコミュニケーションすらできない中学生がいきがってるのはかっこ悪いぞ。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef