オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/09/26(火) 07:20:38.98

前スレ
オブジェクト指向システムの設計 172
http://mevius.2ch.net/test/read.cgi/tech/1467992113
オブジェクト指向システムの設計 173
http://mevius.2ch.net/test/read.cgi/tech/1502182334/

類似スレ
手続き型システムの設計 1
http://mevius.2ch.net/test/read.cgi/tech/1500282714

**デフォルトの名無しさん** · 2017/10/14(土) 17:02:08.30

>>554
だからerrorsオブジェクトの中に項目ごとにエラーが入ってるって言ったろ

> 背景色を変えるには入力項目のidとrubyオブジェクトのプロパティとのひも付けが必要だと思いますが
いらねーよ。

どうせエラー画面がでたら、エラーが出たその項目の値を表示するだろ？
その項目のすぐ下にでもエラー情報だせばいいだろ。

あ？id？エラー情報の表示にidなんていらねーからな。
まさかと思うが、CSSに全項目書いてたりしないよな。
それならclass使え。アホらしいから

**デフォルトの名無しさん** · 2017/10/14(土) 17:06:44.40

>>555
そこらへんはどうでもいいやｗ
重要なのはこの程度でカスタムコード書きまくらないと対応できないとか
思っていたことがはっきりしたってだけ

で、俺の意見はここからさらに先で、Railsのバリデーションコード
あの程度の情報量であれば、YAMLに簡単に外だしできるので、
外出して、客にもレビュー可能にして、価値の低いテストを減らしたい。
YAMLにすればフロントエンド側（JavaScript）でも再利用できるだろうし。
なんでもかんでもクラスに定義するのが良いとは思わないな。

**デフォルトの名無しさん** · 2017/10/14(土) 17:11:55.12

その先はないので程々にした方がいい
設定ファイルでバリデーションするアイデアはJavaとか他の言語が大昔にとっくに通過していて
世界中でこれは使い物にならんと判定されたものだよ

**デフォルトの名無しさん** · 2017/10/14(土) 17:15:32.80

バリデーションすなわち入力検証をプレゼンテーションから切り離して考えるのもバカバカしい
入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
ドメインモデルに入力検証をやらせるのは愚かとしか言いようがない

**デフォルトの名無しさん** · 2017/10/14(土) 17:16:00.23

> 設定ファイルでバリデーションするアイデアはJavaとか他の言語が大昔にとっくに通過していて

それはXMLが失敗の原因だった。
XMLにはタグや属性という技術者しか知らないものが
あるからだめだったんだよ。

**デフォルトの名無しさん** · 2017/10/14(土) 17:17:14.17

>>559
> 入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
YAMLにすることでそれも実現できる

バリデーションは、プレゼンテーションだけのものではない
プレゼンテーションでもドメインモデルでも使われるものだ

**デフォルトの名無しさん** · 2017/10/14(土) 17:20:06.76

更に言うならば、バリデーションはフレームワークではなく
言語仕様に組み込むべきものだよ。
本質的にはD言語の契約プログラミングと同じものなんだから

**デフォルトの名無しさん** · 2017/10/14(土) 17:21:48.23

>>560
違う

モデル定義とバリデーション定義が離れすぎていること
コンパイルできないから開発環境の恩恵をうまく得られないこと
バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること

これらが問題点

**デフォルトの名無しさん** · 2017/10/14(土) 17:24:16.70

>>563
> バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること

あんたはバリデーション処理とバリデーション定義をごっちゃにしてる。
バリデーション処理は動くコードで書くが、
バリデーション定義は動くコードではない。

JavaのXMLなんかも動くコードではないから
これは定義であり、定義の内容をJavaやC#で書く意味はない。
だってただのデータだぞ？ハッシュで持たせればいい程度の情報。

**デフォルトの名無しさん** · 2017/10/14(土) 17:25:05.23

>>559
俺もその意見に賛成かなぁ

画面が変わったら変わった画面用のチェックが必要になってる気がするわ

**デフォルトの名無しさん** · 2017/10/14(土) 17:25:21.74

>>561
違う

プレゼンテーションレイヤではオブジェクトが不正な状態を受け入れることが前提
不正な状態を検知する処理がバリデーション

ドメインレイヤではオブジェクトは不正な状態は受け入れない
プロパティの不正な値をセットしようとした瞬間に例外
メソッドに不正な引数を与えた瞬間に例外
これはバリデーションではない
ドメインレイヤでは契約を使う

**デフォルトの名無しさん** · 2017/10/14(土) 17:25:55.08

>>541の例で言えば

　validates :col2_value numericality: true, presence: true, if condition
　validates :col3_value numericality: true, presence: true, if condition
　validates :col2_plus_col3_number less_than_or_equal_to: 1000, if condition
　validates :col2_plus_col3_number less_than_or_equal_to: 10000, if condition

　validates :col4_text; maximun: 10, if condition
　validate :col4_registered

この部分がバリデーション定義。
簡単にYAMLにできるし、客が検証したい部分でも有る。

numericalityの内容とかconditionの内容がバリデーション処理（の一部）

**デフォルトの名無しさん** · 2017/10/14(土) 17:27:05.32

>>566
> ドメインレイヤではオブジェクトは不正な状態は受け入れない
> プロパティの不正な値をセットしようとした瞬間に例外
> メソッドに不正な引数を与えた瞬間に例外
> これはバリデーションではない

バリデーションに引っかかった結果をどう表示するか？が
プレゼンテーションでやるべきこと。

バリデーションそのものは使いまわすことができる。

**デフォルトの名無しさん** · 2017/10/14(土) 17:27:18.82

>>566
ctrl+vで貼った1GBテキストとかメモリに保持すんの？

**デフォルトの名無しさん** · 2017/10/14(土) 17:28:02.59

>>564
それはあなただけが感じる特殊な感覚だよ
世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった
XMLよりYAMLの方が多少マシという点は認めるが上記の手法に比べればどんぐりのせくらべといったところだ

**デフォルトの名無しさん** · 2017/10/14(土) 17:28:38.29

>>570
> 世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった

設定ファイルを捨ててYAMLにしたの間違いだろｗ

**デフォルトの名無しさん** · 2017/10/14(土) 17:29:02.43

設定をYAMLではなくソースコードに埋め込むのを見てみたいもんだがｗ

**デフォルトの名無しさん** · 2017/10/14(土) 17:30:30.98

お前ら、喧嘩するな
どこに持とうがチェック項目は増えても減ってもいないんだぜ

だったら一番やりやすい画面かな

**デフォルトの名無しさん** · 2017/10/14(土) 17:32:16.56

>>573
いや増えてる。画面でやると画面ごとにバリデーション処理が増えてしまう。
だから数を減らすにはより中心であるモデルで行う必要がある。

**デフォルトの名無しさん** · 2017/10/14(土) 17:32:52.58

ファイルに外だししたからチェックしなくていいですなんて
んなわけねぇだろ

今時エロ本の竿役だってそんなこと言わねぇよ

**デフォルトの名無しさん** · 2017/10/14(土) 17:34:49.45

>>574
チェックはしなきゃ駄目だよ

**デフォルトの名無しさん** · 2017/10/14(土) 17:35:14.23

>>572
JavaのBean ValidationやC#のDataAnnotationsを調べてみればいい
モデルとバリデーション設定を分離して管理する意味がないとわかるはずだ

**デフォルトの名無しさん** · 2017/10/14(土) 17:39:42.15

>>552
低能相手ならそうかもな
御愁傷様としか言えないけど w

**デフォルトの名無しさん** · 2017/10/14(土) 18:20:50.90

>>575
> ファイルに外だししたからチェックしなくていいですなんて
> んなわけねぇだろ

そんなこと言ってないよｗ
バリデーションという単純な部分を
外だしすると誰でもチェックできるようになるよ。

そもそもExcelでやっていたことだからね。
Excelという使いづらい形式がYAMLに変わっただけ
誰でもチェックできるってことの意味がわかったかな？

あ、YAMLに変わってプログラムからそれを
そのまま使うってところも違うか。

**デフォルトの名無しさん** · 2017/10/14(土) 19:06:29.37

YAMLが誰でも読み書きできると主張しているのはプログラマだけという事実について考える必要があるようだ
エクセルは誰でも読み書きできる
これはプログラマ以外のステークホルダーも同意している

**デフォルトの名無しさん** · 2017/10/14(土) 19:35:21.74

xmlはパンピーには無理
スコープなんて意識できるわけねーし

っていうか俺でも辛い
xmlを編集できるツールがそもそもねーじゃん
責任持ってお前作って配れよ

**デフォルトの名無しさん** · 2017/10/14(土) 21:47:43.86

結局のところフレームワーク無しだとif文書きまくるのが最強ということですか？
いわゆるKISSに原則ってやつですね

**デフォルトの名無しさん** · 2017/10/14(土) 21:59:38.46

>>582
if文以外は不要

**デフォルトの名無しさん** · 2017/10/14(土) 22:36:04.01

データからソースコード吐き出すツールでも作ったらどうか？

**デフォルトの名無しさん** · 2017/10/15(日) 00:42:30.20

データはRDBMSでもテキストでもなんでもいいだろ
DAOで抽象化しとけば後から変えられる
メンテできるものにしろ

**デフォルトの名無しさん** · 2017/10/15(日) 00:48:50.64

>>584
それやるとメンテが大変になるから辞めたほうが良いよ。
変換などせずそのまま使う方がいい

**デフォルトの名無しさん** · 2017/10/15(日) 18:02:34.88

なんか盛り上がってるようだがとりあえず
>>533
に賛成票。
設定が正しいか目視で済ませずテストすべき。
目視チェックで済ませたところが往々にしてトラブルの元。

**デフォルトの名無しさん** · 2017/10/15(日) 18:26:45.76

> 設定が正しいか目視で済ませずテストすべき。

そのテストって実行結果を目視で調べるんだろ？

それか、テストのテストのテストのテストを書くわけないだろうから、
テスト書いて目視でそのテストが正しいか調べるんだろ？

どうせ最後は目視するしかないんだよ。
コードレビューとも言うね。

そんなのをやるぐらいなら
「十分な目ん玉があれば、全てのバグは洗い出される」方式を
利用した方がいいよ。

オープンソースでない場合、コードだと「十分な目ん玉」は集められない。
だから技術者ではない人でも検証可能な形にして「十分な目ん玉」を集めたほうが良い

これはコストのかけ方の問題だよ。重要かつ難しい所には技術者を割り当て
バリデーションとかいう単純な所は、誰でもできるようにして十分な数の目ん玉で対応する

**デフォルトの名無しさん** · 2017/10/15(日) 18:43:04.37

バグってるかどうかはリリースすればわかる
瑕疵期間でも人件費はタダじゃねえからな
別にテストで全部見つける必要はない
瑕疵期間なしって契約ならテストで全部チェックするけどね

**デフォルトの名無しさん** · 2017/10/15(日) 18:57:53.15

>>588
コードレビューとテストは目的も確認の手段も違うじゃん
正しいメールアドレスの形式かどうかをチェックする場合とかを考えたら分かるだろ

それに仕様に間違いがないかどうかを誰もが確認できるようにすることと
コードがその仕様通りに動いているかどうかを確認することは
確認する対象が全く違う

自己正当化の論理に聞こえる

**デフォルトの名無しさん** · 2017/10/15(日) 19:04:24.38

>>590
> 正しいメールアドレスの形式かどうかをチェックする場合とかを考えたら分かるだろ

その場合だと「ある文字列が正しいメールアドレスの形式か？」という
ロジックは技術者が入念にチェックすべき重要なロジック。
そしてこれはisMailAddressみたいな名前の関数となる。

そしてユーザーが入力したある項目のバリデーションが
isMailAddressになっているか？は目視で確認すれば良い
これは技術者でなくてもできる。

何でもかんでもコストがかかる技術者を使うなっていうのはこういう話だよ。
バカは項目が存在する数だけ、漢字が使えないこと、@の前は.になってないこと
.を連続して２つ以上使わないこと、みたいなチェックをするからな。

メールアドレスのバリデーションが正しく動いているならば、
そのバリデーションを使う場所がいくつあろうが、
そのバリデーションが使われていることだけを確かめれば良いんだよ。

**デフォルトの名無しさん** · 2017/10/15(日) 19:22:46.86

「社員に対して給料を振り込む」という文章を
「ooをxxする」という1文にしたいときって、
「社員」と「給料」の2つの目的語があるからどうすればいいの?

**デフォルトの名無しさん** · 2017/10/15(日) 19:28:58.58

>>591
>>メールアドレスのバリデーションが正しく動いているならば、
>>そのバリデーションを使う場所がいくつあろうが、
>>そのバリデーションが使われていることだけを確かめれば良いんだよ。

確める内容はそれでOK
でも確める方法が設定ファイルの目視チェックでは不十分。
設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。

まあシステム間結合テストとか言われるようなテストフェーズでやる場合、実装担当はあまり関係ないことかもしれないが。
誰かがそのテストをする必要はある。

**デフォルトの名無しさん** · 2017/10/15(日) 19:39:32.38

設定ファイルに書いてあればOK
笑えないけど笑っちまった
設定ファイルの記述ミスは存在しない前提かよ

**デフォルトの名無しさん** · 2017/10/15(日) 19:43:52.74

>>593
> 設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
それは画面やAPIごとに、ここではこの項目が使われていますって
画面に表示するだけでOK。それを目視で確認すれば良い。

>>594
> 設定ファイルの記述ミスは存在しない前提かよ

記述ミスは目視で調べろって話だろｗ
何を聞いてるんだか

**デフォルトの名無しさん** · 2017/10/15(日) 19:49:40.01

>>595
見ただけじゃわかんねえよw

**デフォルトの名無しさん** · 2017/10/15(日) 20:00:30.48

というかさ、目視を軽視してないか？
動作確認を過大評価してないか？

動作確認っていうのは確かに動作させたものに関しは
その通り動くだろうけど、動作させてない所はわからないんだぞ。
偶数かどうかチェックする関数、2と4と6でテストしてOKだからといって
8がOKになるとは限らない。コードのロジックを "目視" して
問題ないことを確認しているはずなんだが？

永遠の時間があれば全て動作確認すればいいだろうけど
実際にはそんな時間はない。だから動作させずに目視で確認できるように
そういう仕組を作っていくことが重要なんだよ。

時間をかけて努力をすることは偉くもなんともない。
なるべく時間をかけずに成果を上げるようにしないと
生産性は上がらないぞ

**デフォルトの名無しさん** · 2017/10/15(日) 20:03:20.76

>>596
それは見ただけでわかるような仕組みを作ってないから。

ゲームでよくあるデバッグモードみたいなものを
本気で実装した方がいいよ。
通常のプレイで見えないパラメータを、デバッグする人も見えないまま
デバッグするのは、時間を無駄に消費するだけ

デバッグモードを有効にしたら、見えないパラメータ
例えばこの項目のバリデーションは○○です～みたいなものを
表示するようにすれば、見ただけでわかるようになる。

**デフォルトの名無しさん** · 2017/10/15(日) 20:04:45.78

テストも目視も要らないよ
とりあえずリリースしちゃいなよ
問題があればそれではっきりするだろ
説得するより怒られる方が楽って昔の偉いプログラマも言ってたぞ

**デフォルトの名無しさん** · 2017/10/15(日) 20:09:59.40

>>599
ベータ版リリースとか有るからね。

でも、それはちゃんと発生した問題を自動で
検出して通知する仕組みが必要だよ。
それがないと問題があっても教えてくれないし、
発生した問題の詳細もわからない。
言うほど簡単じゃない。

**デフォルトの名無しさん** · 2017/10/15(日) 20:21:11.07

>>597
なんかお前もうヤケクソじゃね？ｗ
お前の主張は誰が見てもありえねーからｗ

**デフォルトの名無しさん** · 2017/10/15(日) 20:25:02.63

>>601
反論は、文句じゃなくて、理屈で返してください

**デフォルトの名無しさん** · 2017/10/15(日) 20:27:43.57

>>602
だってそんなん
社会で通用しねーのわかってるし
相手にしてお前の馬鹿が伝染ったら嫌だし

**デフォルトの名無しさん** · 2017/10/15(日) 20:58:42.66

>>603
理屈で返せない理由がそれ？

**デフォルトの名無しさん** · 2017/10/15(日) 21:03:02.20

>>602
でかいソフトを書いたことないだろうな...
コードは正しくても実行するとうまく動かないとか経験したことないだろ

**デフォルトの名無しさん** · 2017/10/15(日) 21:06:15.70

>>605
その質問に、

あると答えた場合
ないと答えた場合

それぞれあなたはなんて返してくるんですか？
いや、どうせどちらで答えても、的はずれな
文句言って終わるんだろうなと思いましてねｗ

**デフォルトの名無しさん** · 2017/10/15(日) 21:13:49.98

>>606
いや、もうただの屁理屈じゃんお前の
設定ファイルの読み込み処理がバグってるかもしんねーじゃん
最終的な動作の確認は絶対必要じゃん

お客からしたら設定値なんて
ファイルに出そうがソースに埋め込もうが知ったこっちゃないじゃん
ただ、お約束した機能が動いているかどうかはお客さんとの約束でしょ？
その確認をしないでどーすん？

**デフォルトの名無しさん** · 2017/10/15(日) 21:17:26.65

> 設定ファイルの読み込み処理がバグってるかもしんねーじゃん

ならそこだけをテストすりゃいーだろ。
仕事は減らす方向に向かって頑張れよ。

人海戦術で時間をかけたらからって
偉くもなんともないんだぞ

**デフォルトの名無しさん** · 2017/10/15(日) 21:21:47.27

>>606
まずはどっちなの？

**デフォルトの名無しさん** · 2017/10/15(日) 21:22:09.90

> ただ、お約束した機能が動いているかどうかはお客さんとの約束でしょ？
> その確認をしないでどーすん？

その確認をどーするって、お前は客にテストやりましたって
エクセルシートでも送りつけて、それが本当かもわからないのに
これ見て納得してくださいってやってるんだろ？何一つ証拠がねーよ。
それともテスト作業してる動画を何時間も見せてこれが証拠ですとでもやるつもりか？

コード見せたって客はその内容わからないかもしれないし、
テストコード見せたって、それがソースコードの形じゃやっぱりわからない。
エクセルファイル見せたって、それを本当にやったかどうかもわからない。
間違って記入しているかもしれない。何にもあてにならないよね。

俺が言ってるのは、客にも簡単にわかるような形でデータを作り
そのデータをそのままプログラムで使えって言ってるの。
客がそれみて納得すりゃそれでOKだし、そのファイルを
直接使うからもちろんその通りに動く。

客の検収作業が、そのまま目視による確認になってるんだが。

**デフォルトの名無しさん** · 2017/10/15(日) 21:36:21.23

>>591
メールアドレスじゃなく郵便番号くらいを例にしたほうがよかったかね
どういうメールアドレスを正しい形式とするかは要件によって変わってくるんだよ
RFCがあるからといって技術者が勝手に決められるものじゃないから

簡単な郵便番号の入力チェックでも
何をOKとして何をNGとするかは要件次第
その「目視の確認」で一体何が担保できるんだろうね？

1500001
150-0001
１５０－０００１
150　　　 (旧３桁)
150-01　　(旧５桁)
150-9999 (存在しない)

あらゆるケースをすべてテストできるわけでもないしするべきでもないが
仕様通りに動くと自信を持てるレベルのテストはすべき

**デフォルトの名無しさん** · 2017/10/15(日) 21:42:30.40

>>608
はぁ？馬鹿？
設定ファイルが間違ってる可能性は？
読み込みはうまく行っても
値が反映されてない可能性は？
それが設定ファイルのある特定の設定値だけバグる可能性は？

まあ、普通に仕様通りに動くこと確認した方が早いよね？

**デフォルトの名無しさん** · 2017/10/15(日) 21:43:34.59

> メールアドレスじゃなく郵便番号くらいを例にしたほうがよかったかね
> どういうメールアドレスを正しい形式とするかは要件によって変わってくるんだよ
> RFCがあるからといって技術者が勝手に決められるものじゃないから
>
> 簡単な郵便番号の入力チェックでも
> 何をOKとして何をNGとするかは要件次第
> その「目視の確認」で一体何が担保できるんだろうね？

メールアドレスや郵便番号でもなんでもいいが、
ある項目が「メールアドレス」や「郵便番号」であることが担保できる。

これにより仮にバグがあったとしても、一箇所を修正するだけで
すべてが修正されることが担保できる。

動かして確認する方法だと、ある箇所のバグが修正されたからといって
別の場所も同じように修正されるとは限らない。

目視の確認ができるようにしておくことで、工数が大幅に削減できた。

**デフォルトの名無しさん** · 2017/10/15(日) 21:44:37.83

>>612
ならばそこだけテストすればいいだろって
さっきも言った。

目視の確認ではない。テストだ。

**デフォルトの名無しさん** · 2017/10/15(日) 21:44:44.64

想像力が足りないから不具合が無いように見えるんだろうね
想像力足りなくてもこういうの経験ないのかな？
経験不足もあるのかな？
考えが幼いよ

**デフォルトの名無しさん** · 2017/10/15(日) 21:45:37.94

>>614
じゃあ、普通に全部テストするってレスしてるよね？ｗ

**デフォルトの名無しさん** · 2017/10/15(日) 21:48:35.14

>>616
お前関数って知らないのか？
共通化の基本テクニックだぞ？

全てのメールアドレスや郵便番号の項目で
同じ関数を使うんだよ。

テストをするのはその関数のみ。
バリデーションとしてその関数を使っているかどうかを
設定ファイルに書く。

何度も同じ話をさせるな

**デフォルトの名無しさん** · 2017/10/15(日) 21:53:28.83

>>617
かんけーねーんだよ
何度も言うけどファイルに出したのはテメーの勝手なんだよ
動くかどうかを証明しろって言ってるの

何が必要でしょうか？

**デフォルトの名無しさん** · 2017/10/15(日) 22:00:17.33

>>618
見えない情報がある時点で、動かした所で
どんな場合でも動くとは証明できないってのは理解できてる？

ソースコードを読めば動かさなくてもわかる問題でも
ソースコードを隠した状態だと動かした結果だけでは証明できなくなる。

**デフォルトの名無しさん** · 2017/10/15(日) 22:03:56.10

>>619
俺の質問に答える気はあるのかな？
もちろん答えは千差万別だが

お前のソフトが動くことの証明をして欲しいんだよ

一度でもソフトを納品したことがあるならわかるよね？
上司におんぶで抱っこでそんなこと気にしたことなかった？

**デフォルトの名無しさん** · 2017/10/15(日) 22:08:32.52

>>628
> お前のソフトが動くことの証明をして欲しいんだよ

なんでお前もできてないことを俺がやらんといけないの？
って言ってるんだが。

動くことの証明はソースコードを見せる以外に不可能なんだよ。

**デフォルトの名無しさん** · 2017/10/15(日) 22:09:42.31

ソフトウェアの納品は、動くことの証明じゃない。

これだけやりました。やったという証拠です。信じてください。
バグはないと思います（実際には有るだろ？）
という意味でしかない。

気にしたことなかった？

**デフォルトの名無しさん** · 2017/10/15(日) 22:10:40.16

いや、ソフトウェア納品でバグが１つもないと
証明するものを出したというのであれば、
それを言ってくれて良いんだが？

バグが有ることは証明できるが
バグがない（正しく動く）ことは証明できない
常識なんだがねぇ。

**デフォルトの名無しさん** · 2017/10/15(日) 22:16:36.59

>>622
おお、よくわかってんじゃん
じゃあ、それをお前はどうやってやるの？

**デフォルトの名無しさん** · 2017/10/15(日) 22:20:08.75

>>624
え？信用してくださいドキュメントの話なんかしてないじゃんｗ
今まで通りのやり方で適当にでっち上げれば？

俺は少ない手間で必要十分なテストをするだけの話

**デフォルトの名無しさん** · 2017/10/15(日) 22:26:02.41

>>625
いいや
ソフトウェアって上から下まで
さっきお前が言ったとおり
確実なものなんか何一つないよ
お前の十分だってお前の中の十分だろ？

俺等とは違うの
その差分を俺らとは違うお前は自分で埋めなければならない
そこに理屈はない
それが説得ってもんじゃん
人を見るのが嫌ならこの業界は向いてないね

**デフォルトの名無しさん** · 2017/10/15(日) 22:31:22.39

結局屁理屈でごまかしたかｗ

無能なお前らと違うと言っても
だから何としか言えんわｗ

**デフォルトの名無しさん** · 2017/10/15(日) 22:41:19.56

>>627
結局、テスト仕様書もテスト結果も
全ては説得なんだよ

理論に飛躍があり過ぎる
ウォーターフォールのV字開発で
設定ファイルに外だししたから
テスト項目減りますなんざ
あり得ない理論なんだよ

まあ、当然説得なんで可愛い女の子が交渉してくれば通る可能性も無きにしもあらずではあるけどね

**デフォルトの名無しさん** · 2017/10/15(日) 23:06:53.56

>>595
>>593
>>>> 設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
>>それは画面やAPIごとに、ここではこの項目が使われていますって
>>画面に表示するだけでOK。それを目視で確認すれば良い。

なるほど。
各項目のUIを一通り動作させて、
>>598 で書いてくれたようなデバッグモード的表示やデバッグログで、動いたバリデータの書類を出力するってことならよさそうだ。
それなら設定ファイルの内容および設定ファイルの配置の正当性が確認できる。

あ · 2017/10/16(月) 00:16:25.05

2008年くらいに.net FWの地雷踏みまくった事を鑑みると、
テスト仕様は要件定義から作成すべきだし、その実施も単体、結合レベルは機械的に掛けてもいいけど、総合は手でやるべきだろうなぁ。

「テスト対象はまともに動いていない」という仮説を、ケース毎に一つずつ潰していって、残るのが「正常に動いてる」って結果なのが試験で
「正常に動いてる」が先に立って「なぜならこう書いたから、こう動くはずで、現にそう動いてる」ってのは試験じゃなくて単なる確認では？
正直、単体テストでもテスト対象を作った言語を使わないでテストして欲しいところ。

**デフォルトの名無しさん** · 2017/10/16(月) 04:11:08.89

結局ID:/8UsyUgnは>>609にレスできずに逃げたのかよ w

**デフォルトの名無しさん** · 2017/10/16(月) 23:24:09.06

>>631
場合によるので「どちらも」が正解

**デフォルトの名無しさん** · 2017/10/17(火) 05:56:41.14

>>632
>>606個人の話なのに場合によるとか頭大丈夫？ w

**デフォルトの名無しさん** · 2017/10/17(火) 19:34:45.23

＞コードは正しくても実行するとうまく動かないとか経験したこと俺はマニュアルどおりやったからこのコードは動かないけど正しいんだ！

**デフォルトの名無しさん** · 2017/10/17(火) 20:15:05.57

「Object Oriented」は「オブジェクト指向」と訳されていますが、実はこれが大変な誤訳で、正しくは「目的志向」です。
つまり、何らかの目的があって、それを目指す（「指向」は向いているだけ）というわけです。

**デフォルトの名無しさん** · 2017/10/17(火) 20:25:59.57

目的はObjective
Objectは単純に『物』の意味だよ。

**デフォルトの名無しさん** · 2017/10/17(火) 20:28:58.13

>>636
典拠をご提示いただきたい

**デフォルトの名無しさん** · 2017/10/17(火) 20:53:30.82

>>637
まず自分が提示しろ

**デフォルトの名無しさん** · 2017/10/17(火) 21:02:26.86

依存しあってんじゃねーよ

**デフォルトの名無しさん** · 2017/10/17(火) 21:19:29.37

>>638
senderを自分で生成する方法
http://bbs.wankuma.com/index.cgi?mode=al2&;namber=85371

**デフォルトの名無しさん** · 2017/10/17(火) 21:56:16.29

>>640
お、おう。。それもJittaさんか…

面白い捉え方だと思うけど
Object Orientedという言葉が出てきた歴史を調べれば
「目的指向」が誤訳なのが分かるよ
https://en.wikipedia.org/wiki/Object-oriented_programming#History

**デフォルトの名無しさん** · 2017/10/17(火) 22:34:25.19

>>641
Jittaさんが言ってることの方がガセネタですね
じゃあそれを根拠にわんくまに怒鳴り込もうと思います
ありがとうございます

あ · 2017/10/17(火) 22:41:00.56

まあ英語でObject orientedだと、大体は対象志向みたいな意味合いだけどな。
Objectって単語は、モノと言うよりも「認識できる何か」「動作や感情の対象」を指す。
動詞になると顕著で、「俺はこれに文句があるんだが」ぐらいキツい意味。
「I object to waiting」みたいな。

Ob + ject 。前に向かって投げたやつ。客観的に見ることができる物、が語源。
逆に、中に投げ入れるモノがinject。下に投げたものがsubject(自我、主観)。

あ · 2017/10/17(火) 22:46:44.09

>>636
単なる「モノ」はだいたいbody、matter、substance。
physical bodyとか使う。
天体の「体」もbody。heavenly-body。

**デフォルトの名無しさん** · 2017/10/17(火) 22:54:02.93

>>644
素晴らしい「モノ」
優れている「モノ」
高品質な「モノ」
高機能な「モノ」

のモノはどれになるの？

**デフォルトの名無しさん** · 2017/10/17(火) 22:55:17.94

食べモノ、飲みモノ
も追加しよう

**デフォルトの名無しさん** · 2017/10/17(火) 22:55:26.36

thingは？

**デフォルトの名無しさん** · 2017/10/17(火) 22:55:57.78

>>643
つまりJittaさんが大正解ってこと？

**デフォルトの名無しさん** · 2017/10/17(火) 22:59:32.89

目的を指向するってメチャクチャ当たり前だなw　殊更言葉にするのが恥ずかしいくらい

**デフォルトの名無しさん** · 2017/10/17(火) 23:08:10.96

責務指向でいいじゃん？

**デフォルトの名無しさん** · 2017/10/17(火) 23:20:41.75

役割って感じ？
objectではないけどしっくり来る

**デフォルトの名無しさん** · 2017/10/17(火) 23:31:17.25

責務駆動設計とか言うよね

**デフォルトの名無しさん** · 2017/10/17(火) 23:35:58.51

せやかて駆動設計

**デフォルトの名無しさん** · 2017/10/17(火) 23:36:27.01

責務はいつも一つ！

**デフォルトの名無しさん** · 2017/10/17(火) 23:38:24.92

>>654
いいね！