オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>517
試したけど俺の環境では↓こうなるよ
diffだけなら十分実用レベル
$git diff
diff --git a/book.xlsx b/book.xlsx
index c75fc9a..6215aa2 100644
--- a/book.xlsx
+++ b/book.xlsx
@@ -1,5 +1,6 @@
Sheet1
Hello
+ OOXML
World >>525
> YAMLの書き方から教えるのかよ...
YAMLの書き方はExcelよりも簡単だよ。
Excelは知らない人が使いこなすためには
数週間とか数カ月かかるが、
YAMLだとフォーマット用意して、
これと同じように書いてくださいで説明終わり。
Excelでフォーマットを守れないのは、
これと同じように書いてくださいと言っても、使い方が難しいから。
俺の母親は、文字の自動補間機能のせいで「1」と入力しようと
しても「10」と補完されてしまって困っていたな。 >>527
じゃあ今度はある程度データを入れて、同じ内容のセルを結合する前後で
ためしてみそれがどう見えるかを確認したら絶望することになるから ちなみに補足しておくと、>>529はxlsxを直接比較しているのではなく
xlsxをテキストに変換してから比較している。
その時にフォーマット情報などいろいろ抜け落ちる。
だから「取り消し線のところは無視してください。」なんてのはわからない。
このようにExcelはなんでもできてしまうから、
重要な情報が抜け落ちる所に書かれてあった時に比較できない。 >>528
Excelの使い方が難しい？
YAMLがきちんと書けてExcel使えない奴なんて見たことないけどな
お前のおかんはYAML書けるのか？ w >>526
俺はやるべきだと思うなぁ
だって外人のアプリってそのせいなのかどうなのか知らんけど
よく動いてないじゃんｗ >>531
>>500にはフォーマット情報なんて要らんだろ
どんどん深みにはまってるぞ w xmlはプログラマしか編集できない上に
ファイルがでかくなると読み込み速度ヤバイので駄目だよ 俺が昨日書いた検証処理の一部
実際にはこれの数十倍の検証ルールがあると考えてほしい
フレームワークで簡単にできるなら教えてほしいおねがいします
webアプリ
テーブルをバリデーションする
列は4つでそれぞれinputを持ってる
typeは順に「checkbox, text, text, text」
検索でバックエンドから取ってきたデータがこのテーブルに表示される
これを手入力で編集してバックエンドに保存する
再検索できるが検索時にはバリデーションしなくてよい
保存するときはバリデーションを実行する
メッセージはローカライズすること
すべてのテキストリソースはバックエンドで管理されている 1列目のcheckboxがOFFの行はバリデーションしなくていい
2〜4列目のtextがすべて未入力の行はバリデーションしなくていい
2, 3列目が空白の場合エラー
2, 3列目が整数でない場合エラー
2, 3列目の合計値が1000を超えたらエラー
1列目のcheckboxがONの行の2, 3列目の合計値が10000を超えたらエラー
4列目はオプション
10文字以上の場合エラー
入力された文字列がバックエンドに登録されていない場合エラー
エラーメッセージは重複を排除して昇順に並び替えて所定の ul の子要素として追加する
エラーがあった入力項目は背景色を赤くする
同じ行で1つでもエラーがあった行は罫線を赤くする >>533
> だって外人のアプリってそのせいなのかどうなのか知らんけど
> よく動いてないじゃんｗ
外人のアプリって何？Windows？Linux？MacOS？ >>537
どうでもいいけど、列目〜とか言って時点で、画面と密結合してんなーとしか思えんなｗ
列があれば行もあるんだろうけど、一行単位で処理してるようだから、
一行が、一クラスの一インスタンスと考えればよいだろう
1000超えたらエラーなのか10000超えたらエラーなのか分からんが。
画面表示周りにビューの仕事でこれはバリデーションではない。
バリデーション結果オブジェクトを見てビューで表示さればいいだけ（何度も言わせないように）
長くなったのでコードは次のレスに書く class Row
include ActiveModel::Validations
def col1_condition; end
def col2_value; end
def col3_value; end
def col4_text; end
def condition;
col1_condition && col2_value.present? && col3_value.present? && col4_text.present?
end
def col2_plus_col3_number
col2_value + col3_value
end
// ↑ここまでは単なるクラス定義
//↓ここ以下がバリデーション
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
def col4_registered
// 入力された文字列がバックエンドに登録されていない場合エラー
end
end × validate :col4_registered
○ validate :col4_registered, if: condition
っていうか全部 if の後の: 付け忘れてたｗ >>531
だからそれは意図して属性情報は差分比較しないようにしてるからじゃん。。
なんなんその言いがかり
セルの結合もデータ的に何を意味してるのかVBA使うやつなら当然知ってるし
データとして使うExcelシートなら書式設定は変更されないようにロックするだろ
その辺のリテラシがないならExcel使うってのは選択肢にはならないわな >>543
すべての属性情報が無視していいとは限らないからね。
属性情報として重要な事が書かれているかもしれない。
そういう無視して良いのがないかわからないのがExcelの欠点の１つ
Excelになれている人ほど、余計な工夫をしてくる。 >>541
これはなんの言語ですか?
JavaScriptだとどうなるのでしょうか?
10000を超えないのは複数の行について合計した時の話です
メッセージやCSSの処理はどうすればいいでしょうか？ >>545
Ruby & Rails
JavaScriptはしらん。けど大差ないものは作れるだろ
文法上の制約があるとしてんもこんなふうになる程度
validates("col2_value", {numericality: true, presence: true, if: "condition"})
> 10000を超えないのは複数の行について合計した時の話です
一行ごとに保存できるのであれば、保存する時に
この一行を保存するときに10000を超えるかどうかを調べればいい
一行ごとに保存できない、つまりまとめて保存するならば、
一行に相当するオブジェクトに含まれる配列として
テーブル全体を持っておき、そのテーブルの数値の合計を調べれば良い。
> メッセージやCSSの処理はどうすればいいでしょうか？
んなもん、バリデーション結果を返して、そこに含まれるerrorsを
画面に表示すればいいだけ。ローカライゼーションは別の話。 >>546
なるほど
なんとなくわかりかけてきました
肝心のエラー情報はどうやって、どのような形式で取得しますか？
検索や保存など処理によって検証内容が異なる場合は似たようなクラスを２つ用意するのでしょうか？ > 肝心のエラー情報はどうやって、どのような形式で取得しますか？
フレームワーク次第なんだんだからそのやり方に従えばいい
> 検索や保存など処理によって検証内容が異なる場合は似たようなクラスを２つ用意するのでしょうか？
似たようなもの＝同じではない＝違うもの
違うなら別々に用意しなければいけないし、
100%まったく同じならば、使い回せばいい。
一部が全く同じならば、同じ部分だけつかいまわせるように切り出せばいい
絶対にやってはいけないのは、違うところがあるのに
似ているからという理由だけで違うものを使いまわすこと
そんなことをするとある修正が全く無関係な所に影響を及ぼしてしまう。
異なるなら別のものを作るのは当たり前の話だ。 >>544
> すべての属性情報が無視していいとは限らないからね。
限るだろ ⇒ >>500 のデータなんだから w あとなぁ、コピペはいけないってことの意味を勘違いしてるやつが多いんだよな。
単語、文字列をコピペしたらいけない。ファイルをコピペしたら
いけないって勘違いしてる。
コピペしたらいけないのは処理だってーの。
処理はテストするものが定義はテストする意味はない。
定義でするべきなのはテストではなくて確認
確認は目視でもOKなんだよ。
バリデーションなんてほぼ定義にできてしまうのだから
テストする項目にはならない。確認する項目。
だからYAMLに分離して、技術者じゃなくても確認できるようにしておけば良いんだ。 >>548
ちなみにrubyだとバリデーション結果はどうなってるんですか？ >>549
問題はExcelには>>500のデータ以外の情報も自由に入れられてしまうところなんだよ。
そしてそれがわかりづらい。 >>551
RubyじゃなくてRailsな。バリデーションはRailsというフレームワークの一機能
バリデーション結果のオブジェクトの中に
errosってのがあってそこに項目ごとにエラーメッセージが入ってる。
またバリデーション結果のオブジェクトにはvalid?、invalid?メソッドがあって
全体がバリデーションでOKだったかどうかもわかる。 >>553
どの項目でエラーが出たかはわかりませんか？
背景色を変えるには入力項目のidとrubyオブジェクトのプロパティとのひも付けが必要だと思いますが
ここも粗結合にしたまま対応できるんでしょうか？ >>541
この場合のcheckboxは更新対象を示すフラグっぽいから
2~4列目のモデルの要素とは別にしたほうがいいんじゃないかな
ONになってる行のコレクション対してバリデーションすればいいので
if conditionは全部消せる >>554
だからerrorsオブジェクトの中に項目ごとにエラーが入ってるって言ったろ
> 背景色を変えるには入力項目のidとrubyオブジェクトのプロパティとのひも付けが必要だと思いますが
いらねーよ。
どうせエラー画面がでたら、エラーが出たその項目の値を表示するだろ？
その項目のすぐ下にでもエラー情報だせばいいだろ。
あ？id？ エラー情報の表示にidなんていらねーからな。
まさかと思うが、CSSに全項目書いてたりしないよな。
それならclass使え。アホらしいから >>555
そこらへんはどうでもいいやｗ
重要なのはこの程度でカスタムコード書きまくらないと対応できないとか
思っていたことがはっきりしたってだけ
で、俺の意見はここからさらに先で、Railsのバリデーションコード
あの程度の情報量であれば、YAMLに簡単に外だしできるので、
外出して、客にもレビュー可能にして、価値の低いテストを減らしたい。
YAMLにすればフロントエンド側（JavaScript）でも再利用できるだろうし。
なんでもかんでもクラスに定義するのが良いとは思わないな。 その先はないので程々にした方がいい
設定ファイルでバリデーションするアイデアはJavaとか他の言語が大昔にとっくに通過していて
世界中でこれは使い物にならんと判定されたものだよ バリデーションすなわち入力検証をプレゼンテーションから切り離して考えるのもバカバカしい
入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
ドメインモデルに入力検証をやらせるのは愚かとしか言いようがない > 設定ファイルでバリデーションするアイデアはJavaとか他の言語が大昔にとっくに通過していて
それはXMLが失敗の原因だった。
XMLにはタグや属性という技術者しか知らないものが
あるからだめだったんだよ。 >>559
> 入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
YAMLにすることでそれも実現できる
バリデーションは、プレゼンテーションだけのものではない
プレゼンテーションでもドメインモデルでも使われるものだ 更に言うならば、バリデーションはフレームワークではなく
言語仕様に組み込むべきものだよ。
本質的にはD言語の契約プログラミングと同じものなんだから >>560
違う
モデル定義とバリデーション定義が離れすぎていること
コンパイルできないから開発環境の恩恵をうまく得られないこと
バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること
これらが問題点 >>563
> バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること
あんたはバリデーション処理とバリデーション定義をごっちゃにしてる。
バリデーション処理は動くコードで書くが、
バリデーション定義は動くコードではない。
JavaのXMLなんかも動くコードではないから
これは定義であり、定義の内容をJavaやC#で書く意味はない。
だってただのデータだぞ？ハッシュで持たせればいい程度の情報。 >>559
俺もその意見に賛成かなぁ
画面が変わったら変わった画面用のチェックが必要になってる気がするわ >>561
違う
プレゼンテーションレイヤではオブジェクトが不正な状態を受け入れることが前提
不正な状態を検知する処理がバリデーション
ドメインレイヤではオブジェクトは不正な状態は受け入れない
プロパティの不正な値をセットしようとした瞬間に例外
メソッドに不正な引数を与えた瞬間に例外
これはバリデーションではない
ドメインレイヤでは契約を使う >>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の内容がバリデーション処理（の一部） >>566
> ドメインレイヤではオブジェクトは不正な状態は受け入れない
> プロパティの不正な値をセットしようとした瞬間に例外
> メソッドに不正な引数を与えた瞬間に例外
> これはバリデーションではない
バリデーションに引っかかった結果をどう表示するか？が
プレゼンテーションでやるべきこと。
バリデーションそのものは使いまわすことができる。 >>566
ctrl+vで貼った1GBテキストとかメモリに保持すんの？ >>564
それはあなただけが感じる特殊な感覚だよ
世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった
XMLよりYAMLの方が多少マシという点は認めるが上記の手法に比べればどんぐりのせくらべといったところだ >>570
> 世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった
設定ファイルを捨ててYAMLにしたの間違いだろｗ 設定をYAMLではなくソースコードに埋め込むのを見てみたいもんだがｗ お前ら、喧嘩するな
どこに持とうがチェック項目は増えても減ってもいないんだぜ
だったら一番やりやすい画面かな >>573
いや増えてる。画面でやると画面ごとにバリデーション処理が増えてしまう。
だから数を減らすにはより中心であるモデルで行う必要がある。 ファイルに外だししたからチェックしなくていいですなんて
んなわけねぇだろ
今時エロ本の竿役だってそんなこと言わねぇよ >>572
JavaのBean ValidationやC#のDataAnnotationsを調べてみればいい
モデルとバリデーション設定を分離して管理する意味がないとわかるはずだ >>552
低能相手ならそうかもな
御愁傷様としか言えないけど w >>575
> ファイルに外だししたからチェックしなくていいですなんて
> んなわけねぇだろ
そんなこと言ってないよｗ
バリデーションという単純な部分を
外だしすると誰でもチェックできるようになるよ。
そもそもExcelでやっていたことだからね。
Excelという使いづらい形式がYAMLに変わっただけ
誰でもチェックできるってことの意味がわかったかな？
あ、YAMLに変わってプログラムからそれを
そのまま使うってところも違うか。 YAMLが誰でも読み書きできると主張しているのはプログラマだけという事実について考える必要があるようだ
エクセルは誰でも読み書きできる
これはプログラマ以外のステークホルダーも同意している xmlはパンピーには無理
スコープなんて意識できるわけねーし
っていうか俺でも辛い
xmlを編集できるツールがそもそもねーじゃん
責任持ってお前作って配れよ 結局のところフレームワーク無しだとif文書きまくるのが最強ということですか？
いわゆるKISSに原則ってやつですね データからソースコード吐き出すツールでも作ったらどうか？ データはRDBMSでもテキストでもなんでもいいだろ
DAOで抽象化しとけば後から変えられる
メンテできるものにしろ >>584
それやるとメンテが大変になるから辞めたほうが良いよ。
変換などせずそのまま使う方がいい なんか盛り上がってるようだがとりあえず
>>533
に賛成票。
設定が正しいか目視で済ませずテストすべき。
目視チェックで済ませたところが往々にしてトラブルの元。 > 設定が正しいか目視で済ませずテストすべき。
そのテストって実行結果を目視で調べるんだろ？
それか、テストのテストのテストのテストを書くわけないだろうから、
テスト書いて目視でそのテストが正しいか調べるんだろ？
どうせ最後は目視するしかないんだよ。
コードレビューとも言うね。
そんなのをやるぐらいなら
「十分な目ん玉があれば、全てのバグは洗い出される」方式を
利用した方がいいよ。
オープンソースでない場合、コードだと「十分な目ん玉」は集められない。
だから技術者ではない人でも検証可能な形にして「十分な目ん玉」を集めたほうが良い
これはコストのかけ方の問題だよ。重要かつ難しい所には技術者を割り当て
バリデーションとかいう単純な所は、誰でもできるようにして十分な数の目ん玉で対応する バグってるかどうかはリリースすればわかる
瑕疵期間でも人件費はタダじゃねえからな
別にテストで全部見つける必要はない
瑕疵期間なしって契約ならテストで全部チェックするけどね >>588
コードレビューとテストは目的も確認の手段も違うじゃん
正しいメールアドレスの形式かどうかをチェックする場合とかを考えたら分かるだろ
それに仕様に間違いがないかどうかを誰もが確認できるようにすることと
コードがその仕様通りに動いているかどうかを確認することは
確認する対象が全く違う
自己正当化の論理に聞こえる >>590
> 正しいメールアドレスの形式かどうかをチェックする場合とかを考えたら分かるだろ
その場合だと「ある文字列が正しいメールアドレスの形式か？」という
ロジックは技術者が入念にチェックすべき重要なロジック。
そしてこれはisMailAddressみたいな名前の関数となる。
そしてユーザーが入力したある項目のバリデーションが
isMailAddressになっているか？は目視で確認すれば良い
これは技術者でなくてもできる。
何でもかんでもコストがかかる技術者を使うなっていうのはこういう話だよ。
バカは項目が存在する数だけ、漢字が使えないこと、@の前は.になってないこと
.を連続して２つ以上使わないこと、みたいなチェックをするからな。
メールアドレスのバリデーションが正しく動いているならば、
そのバリデーションを使う場所がいくつあろうが、
そのバリデーションが使われていることだけを確かめれば良いんだよ。 「社員に対して給料を振り込む」という文章を
「ooをxxする」という1文にしたいときって、
「社員」と「給料」の2つの目的語があるからどうすればいいの? >>591
>>メールアドレスのバリデーションが正しく動いているならば、
>>そのバリデーションを使う場所がいくつあろうが、
>>そのバリデーションが使われていることだけを確かめれば良いんだよ。
確める内容はそれでOK
でも確める方法が設定ファイルの目視チェックでは不十分。
設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
まあシステム間結合テストとか言われるようなテストフェーズでやる場合、実装担当はあまり関係ないことかもしれないが。
誰かがそのテストをする必要はある。 設定ファイルに書いてあればOK
笑えないけど笑っちまった
設定ファイルの記述ミスは存在しない前提かよ >>593
> 設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
それは画面やAPIごとに、ここではこの項目が使われていますって
画面に表示するだけでOK。それを目視で確認すれば良い。
>>594
> 設定ファイルの記述ミスは存在しない前提かよ
記述ミスは目視で調べろって話だろｗ
何を聞いてるんだか というかさ、目視を軽視してないか？
動作確認を過大評価してないか？
動作確認っていうのは確かに動作させたものに関しは
その通り動くだろうけど、動作させてない所はわからないんだぞ。
偶数かどうかチェックする関数、2と4と6でテストしてOKだからといって
8がOKになるとは限らない。コードのロジックを "目視" して
問題ないことを確認しているはずなんだが？
永遠の時間があれば全て動作確認すればいいだろうけど
実際にはそんな時間はない。だから動作させずに目視で確認できるように
そういう仕組を作っていくことが重要なんだよ。
時間をかけて努力をすることは偉くもなんともない。
なるべく時間をかけずに成果を上げるようにしないと
生産性は上がらないぞ >>596
それは見ただけでわかるような仕組みを作ってないから。
ゲームでよくあるデバッグモードみたいなものを
本気で実装した方がいいよ。
通常のプレイで見えないパラメータを、デバッグする人も見えないまま
デバッグするのは、時間を無駄に消費するだけ
デバッグモードを有効にしたら、見えないパラメータ
例えばこの項目のバリデーションは○○です〜みたいなものを
表示するようにすれば、見ただけでわかるようになる。 テストも目視も要らないよ
とりあえずリリースしちゃいなよ
問題があればそれではっきりするだろ
説得するより怒られる方が楽って昔の偉いプログラマも言ってたぞ >>599
ベータ版リリースとか有るからね。
でも、それはちゃんと発生した問題を自動で
検出して通知する仕組みが必要だよ。
それがないと問題があっても教えてくれないし、
発生した問題の詳細もわからない。
言うほど簡単じゃない。 >>597
なんかお前もうヤケクソじゃね？ｗ
お前の主張は誰が見てもありえねーからｗ >>601
反論は、文句じゃなくて、理屈で返してください >>602
だってそんなん
社会で通用しねーのわかってるし
相手にしてお前の馬鹿が伝染ったら嫌だし >>602
でかいソフトを書いたことないだろうな...
コードは正しくても実行するとうまく動かないとか経験したことないだろ >>605
その質問に、
ある と答えた場合
ない と答えた場合
それぞれあなたはなんて返してくるんですか？
いや、どうせどちらで答えても、的はずれな
文句言って終わるんだろうなと思いましてねｗ >>606
いや、もうただの屁理屈じゃんお前の
設定ファイルの読み込み処理がバグってるかもしんねーじゃん
最終的な動作の確認は絶対必要じゃん
お客からしたら設定値なんて
ファイルに出そうがソースに埋め込もうが知ったこっちゃないじゃん
ただ、お約束した機能が動いているかどうかはお客さんとの約束でしょ？
その確認をしないでどーすん？ > 設定ファイルの読み込み処理がバグってるかもしんねーじゃん
ならそこだけをテストすりゃいーだろ。
仕事は減らす方向に向かって頑張れよ。
人海戦術で時間をかけたらからって
偉くもなんともないんだぞ > ただ、お約束した機能が動いているかどうかはお客さんとの約束でしょ？
> その確認をしないでどーすん？
その確認をどーするって、お前は客にテストやりましたって
エクセルシートでも送りつけて、それが本当かもわからないのに
これ見て納得してくださいってやってるんだろ？何一つ証拠がねーよ。
それともテスト作業してる動画を何時間も見せてこれが証拠ですとでもやるつもりか？
コード見せたって客はその内容わからないかもしれないし、
テストコード見せたって、それがソースコードの形じゃやっぱりわからない。
エクセルファイル見せたって、それを本当にやったかどうかもわからない。
間違って記入しているかもしれない。何にもあてにならないよね。
俺が言ってるのは、客にも簡単にわかるような形でデータを作り
そのデータをそのままプログラムで使えって言ってるの。
客がそれみて納得すりゃそれでOKだし、そのファイルを
直接使うからもちろんその通りに動く。
客の検収作業が、そのまま目視による確認になってるんだが。 >>591
メールアドレスじゃなく郵便番号くらいを例にしたほうがよかったかね
どういうメールアドレスを正しい形式とするかは要件によって変わってくるんだよ
RFCがあるからといって技術者が勝手に決められるものじゃないから
簡単な郵便番号の入力チェックでも
何をOKとして何をNGとするかは要件次第
その「目視の確認」で一体何が担保できるんだろうね？
1500001
150-0001
１５０−０００１
150 (旧３桁)
150-01 (旧５桁)
150-9999 (存在しない)
あらゆるケースをすべてテストできるわけでもないしするべきでもないが
仕様通りに動くと自信を持てるレベルのテストはすべき >>608
はぁ？馬鹿？
設定ファイルが間違ってる可能性は？
読み込みはうまく行っても
値が反映されてない可能性は？
それが設定ファイルのある特定の設定値だけバグる可能性は？
まあ、普通に仕様通りに動くこと確認した方が早いよね？ > メールアドレスじゃなく郵便番号くらいを例にしたほうがよかったかね
> どういうメールアドレスを正しい形式とするかは要件によって変わってくるんだよ
> RFCがあるからといって技術者が勝手に決められるものじゃないから
>
> 簡単な郵便番号の入力チェックでも
> 何をOKとして何をNGとするかは要件次第
> その「目視の確認」で一体何が担保できるんだろうね？
メールアドレスや郵便番号でもなんでもいいが、
ある項目が「メールアドレス」や「郵便番号」であることが担保できる。
これにより仮にバグがあったとしても、一箇所を修正するだけで
すべてが修正されることが担保できる。
動かして確認する方法だと、ある箇所のバグが修正されたからといって
別の場所も同じように修正されるとは限らない。
目視の確認ができるようにしておくことで、工数が大幅に削減できた。 >>612
ならばそこだけテストすればいいだろって
さっきも言った。
目視の確認ではない。テストだ。 想像力が足りないから不具合が無いように見えるんだろうね
想像力足りなくてもこういうの経験ないのかな？
経験不足もあるのかな？
考えが幼いよ >>614
じゃあ、普通に全部テストするってレスしてるよね？ｗ >>616
お前関数って知らないのか？
共通化の基本テクニックだぞ？
全てのメールアドレスや郵便番号の項目で
同じ関数を使うんだよ。
テストをするのはその関数のみ。
バリデーションとしてその関数を使っているかどうかを
設定ファイルに書く。
何度も同じ話をさせるな >>617
かんけーねーんだよ
何度も言うけどファイルに出したのはテメーの勝手なんだよ
動くかどうかを証明しろって言ってるの
何が必要でしょうか？ >>618
見えない情報がある時点で、動かした所で
どんな場合でも動くとは証明できないってのは理解できてる？
ソースコードを読めば動かさなくてもわかる問題でも
ソースコードを隠した状態だと動かした結果だけでは証明できなくなる。 >>619
俺の質問に答える気はあるのかな？
もちろん答えは千差万別だが
お前のソフトが動くことの証明をして欲しいんだよ
一度でもソフトを納品したことがあるならわかるよね？
上司におんぶで抱っこでそんなこと気にしたことなかった？ >>628
> お前のソフトが動くことの証明をして欲しいんだよ
なんでお前もできてないことを俺がやらんといけないの？
って言ってるんだが。
動くことの証明はソースコードを見せる以外に不可能なんだよ。 ソフトウェアの納品は、動くことの証明じゃない。
これだけやりました。やったという証拠です。信じてください。
バグはないと思います（実際には有るだろ？）
という意味でしかない。
気にしたことなかった？ いや、ソフトウェア納品でバグが１つもないと
証明するものを出したというのであれば、
それを言ってくれて良いんだが？
バグが有ることは証明できるが
バグがない（正しく動く）ことは証明できない
常識なんだがねぇ。 >>622
おお、よくわかってんじゃん
じゃあ、それをお前はどうやってやるの？ >>624
え？ 信用してくださいドキュメントの話なんかしてないじゃんｗ
今まで通りのやり方で適当にでっち上げれば？
俺は少ない手間で必要十分なテストをするだけの話 >>625
いいや
ソフトウェアって上から下まで
さっきお前が言ったとおり
確実なものなんか何一つないよ
お前の十分だってお前の中の十分だろ？
俺等とは違うの
その差分を俺らとは違うお前は自分で埋めなければならない
そこに理屈はない
それが説得ってもんじゃん
人を見るのが嫌ならこの業界は向いてないね ■ このスレッドは過去ログ倉庫に格納されています
