オブジェクト指向システムの設計 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/08(日) 10:04:06.91

でも見積り出せない作業じゃお金もらえないから

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

単価を品質に見合ったものにしろ

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

おまえらアスペとかADHDとか言ってるけど
せめてググってwikipediaや解説サイトぐらい見れば話が合うような言葉を選んでくれ
10人にADHDの説明させたら10通りの回答が出てくる現状では
技術的な議論に使う言葉じゃないと思うんだわ

**デフォルトの名無しさん** · 2017/10/08(日) 11:01:13.46

見積もりは出したふりでいい
客も見積もりに意味ないことは分かってるから上司への説明など適当にうまくやってくれる
その辺は阿吽の呼吸ですよ

**デフォルトの名無しさん** · 2017/10/08(日) 11:04:17.48

関わるのも面倒だからそういうのはメンバーにいない方がマシ

**デフォルトの名無しさん** · 2017/10/08(日) 11:16:34.14

>>427
自分が誰よりも上位にあることを見せかける上で便利だからねアスペ認定は

**デフォルトの名無しさん** · 2017/10/08(日) 11:18:28.86

ここオブジェクト指向スレなんですが？
アスペがアスペを叩いていて笑う

**デフォルトの名無しさん** · 2017/10/08(日) 11:25:19.20

アスペクト指向ってどうなったの

**デフォルトの名無しさん** · 2017/10/08(日) 11:36:48.97

>>436
オブジェクト指向にフックを仕込めれば十分であることがわかった
アスペクト指向は「指向」ではなく、オブジェクト指向設計に
組み込む一種のパターン

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

>>436
DIで若干使われてなかったっけ？

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

そういや一時期流行ったな
実装のまずさを誤魔化す手段という認識しかなかった

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

デコレーター
属性バリデーション
シリアライズ
apiプロキシ
…

aopは意識しないだけで結構使ってるな

**デフォルトの名無しさん** · 2017/10/09(月) 08:04:01.64

メッセージリソース管理クラスの素晴らしい設計を教えてください

void SomeAppMethod() {
// do something
view.AddMessage("MSG_0123")
// do something
}

こんな感じでリソースIDがシステム中にばら撒かれて制御不能状態になっています
メッセージリソースを管理するクラスを作って解消したいのですが良いAPIが決まりません

**デフォルトの名無しさん** · 2017/10/09(月) 08:13:01.79

>>441
何が困ってるの？

**デフォルトの名無しさん** · 2017/10/09(月) 08:52:42.35

>>441
OOPではリソースIDのような物理的な情報は隠蔽しなければならない

public interface ILowLevelMsgManager {
string GetMsg(string msgId, params object[] placeHolderArgs);
}

public interface IMsgManager {
string GetHogeMsg(); // ほげええええ
string GetFugaMsg(int num); // ふがふが{num}ふがふが
}

public class MsgManager : IMsgManager {
private ILowLevelMsgManager llmm;
public MsgManager(ILowLevelMsgManager pllmm) { llmm = pllmm; }
public string GetHogeMsg() { return llmm.GetMsg("MSG_0001"); }
public string GetFugaMsg(int num) { return llmm.GetMsg("MSG_0002", num); }
}

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

>>443
それになんの意味があるのかさっぱりわからんな
メッセージなんてでかいプロジェクトだと500個とか行っちゃって
詳細なんかわかんなくていいんじゃないの？
もうメッセージ一覧で確認することは諦めろよ的な

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

メッセージでこれまで見た中で一番多いのは3000だった
そこまで構えろとはいわんけどそういう性質のものではある

ソースの該当箇所に一つ一つ置いていく手間は省略できない
メッセージリソースIDとメッセージが照合できればそれでその作業は終わりじゃねーのか？
後、何を管理してもらいたい？

**デフォルトの名無しさん** · 2017/10/09(月) 10:08:03.54

>>444-445
ハードコードされた人間可読性ゼロの3000個のIDはそう簡単には管理しきれないと思うが
まあ君の人生だしどう時間を使おうと君の自由だね
私はしっかり管理して時間を節約するよ

**デフォルトの名無しさん** · 2017/10/09(月) 10:21:29.30

客の都合でID体系変更になってリテラル全部調べて置き換えて再テストしたトラウマ
する価値ないと思ってもとりあえずでいいから抽象化しておいて損はない

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

別ファイルに切り出して読み込めばいいと思う

**デフォルトの名無しさん** · 2017/10/09(月) 10:44:55.28

>>446
いやぁ、だからさ
ソースのエラー箇所に自動配置なんかできないんだからそこは300だろうが3000だろうが30000だろうが手動じゃん
IDとエラーメッセージが組にさえなってたらどういう構造にしようがやることかわんねーよ的な

**デフォルトの名無しさん** · 2017/10/09(月) 10:48:47.25

visualstudioのjaファイルとかその辺の仕組み使えばいいんじゃないの？
ローカライズするならやっとかないと死ぬよ

**デフォルトの名無しさん** · 2017/10/09(月) 10:50:11.84

rm = new ResourceManager(locale)
un = rm.get("property.name.user-name")
msg = rm.get("validation.error.max-length", un, 10)
print msg # ユーザー名は10文字以下で入力してください

スッキリ

**デフォルトの名無しさん** · 2017/10/09(月) 10:55:11.14

>>449
それじゃ可読性が低すぎるって言ってるの
暗号みたいにIDばらまかれても保守できないよ
それに>>447のようにIDとメッセージの対応が変わることもある
手間が変わらないなら1つ抽象化層を設けてコードを保護すべき

**デフォルトの名無しさん** · 2017/10/09(月) 11:29:45.24

>>452
いやぁでもこの数やる気にはなんないなぁ

**デフォルトの名無しさん** · 2017/10/09(月) 11:31:53.98

>>452
体系が変わるのはまた別の話かな
もう完全に仕様変更なわけで落ち着いて対応できる

**デフォルトの名無しさん** · 2017/10/09(月) 11:34:13.65

このケースで余計に一層設けるのはメリット薄いんじゃない？
って言いたい

**デフォルトの名無しさん** · 2017/10/09(月) 11:44:58.84

>>441
C#なら素直に.resx使う
少なくとも存在しないIDを使った場合に
コンパイルエラーになる仕組みを使う

種類ごとにグループ化(階層化)して管理しやすくする

メジャーなフレームワーク参照したら分かると思うがMSG_0123みたいな命名自体も悪手
もうどうしようもないのかもしれんが

**デフォルトの名無しさん** · 2017/10/09(月) 11:50:08.07

>>456
もう数からいってメッセージのうちのどれ？って判別できる量で終わらんと思うし
IDの命名規則なんて些細なことよｗ
俺の経験で言うと

**デフォルトの名無しさん** · 2017/10/09(月) 11:59:06.73

コードジェネレータがいいよ

メッセージID, メッセージテキスト, パラメータ数
Hoge, ほげ, 0
Fuga, {0}はふがです, 1

これをエクセルで管理してメッセージ管理クラスを出力

class MessageManager {
public static string Hoge() => "ほげ";
public static string Fuga(object p0) => string.Format("{0}はふがです", p0);
}

んでデータ数が増えてきたらエクセルをやめてデータベースで管理
エクセルを使えばお客様もお喜びになられるので一石二鳥

**デフォルトの名無しさん** · 2017/10/09(月) 12:17:44.19

>>457
メンテナンス性を犠牲にしても
命名負荷を下げたいという意思決定をしてるんならいいんじゃないの

神クラス・神テーブルと同じアプローチだけど
物によってはそれが適切な選択の場合もあるんだろうから

**デフォルトの名無しさん** · 2017/10/09(月) 12:35:04.44

>>441
> メッセージリソース管理クラスの素晴らしい設計を教えてください

メッセージリソースなんてものを作らない。

view.AddMessage("あーがこーでどうなりました")

って日本語で書けばいい。

多言語化したいなら、gettextなどの言語やフレームワーク標準の
多言語化ライブラリを使えばいい話。

その場合は、英語でメッセージを書いて、日本語化するってことが
よく行われるが逆でもいいだろう。

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

>>373
責務指向良いね

ゲームはオブジェクト指向でしっくり来るかも知れんけど業務システムだとピンと来ない

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

ゲームをオブジェクト指向で作ると作りにくいよ
相互作用の処理が多過ぎてオブジェクトに閉じない

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

それは設計どころかゲームそのものとしての落とし込みが不十分
ゲームとか一定のルールに則った動作をするだよ

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

>>462
メッセージ&イベントだらけになって死ぬな
ゲームは関数型が至高

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

「オブジェクト指向だからステージの俳優が全員なんか言ってきて
カントクは一人一人対応なんかしてたら死ぬな！！www」

…いや、間違った理解をした奴はまあそういうドマヌケやらかしがちだが
普通はステージステータスに集約されて、ディレクターは
そのステータスを見て上から必要な個々に指示が送られるように作るからね…

**デフォルトの名無しさん** · 2017/10/11(水) 00:09:15.15

ゲームは油断するとすぐにキャストや型判定だらけになってしまう
特定のクラス同士の時だけ発生する相互作用とか

**デフォルトの名無しさん** · 2017/10/12(木) 12:26:13.92

ゲームとか業務とかピンキリだろ

**デフォルトの名無しさん** · 2017/10/12(木) 21:48:31.48

お客さんが属性バリデーションも他のバリデーションフレームワークも使っちゃダメって言うんだけど
どうすれば楽にバリデーションできる？
言語はC#
テキストリソースは全てDBで管理されている
ロケールによってエラーテキストを変えなければならいとする

**デフォルトの名無しさん** · 2017/10/12(木) 22:09:08.92

>>468
普通に作る以外にない
ちなみにダメって言う理由は何なの？

あとバリデーション自体と
バリデーション結果に応じたエラーテキストの選択は
分けて考えたほうがいいよ

**デフォルトの名無しさん** · 2017/10/12(木) 22:34:53.95

>>469
属性やフレームワークは設定方法がよくわからないのでメンテナンスの時に困るから

ひたすら単調にif文をズラズラと書いてるんだけどシンドイ
項目数が100近いPageもあってそれぞれが何種類かのバリデーションを行うからバリデーションだけで数百行のメソッドになることもある

**デフォルトの名無しさん** · 2017/10/12(木) 23:00:42.84

>>470
xmlでルール書くやつは敬遠されるのは理解できなくもないが
単純な属性ベースは分かりやすいしメンテしやすいのにね

楽しようとすれば結局自前で簡易的なフレームワーク風のものを作ることになる
あまりにも数が多いならコード生成という選択肢も

**デフォルトの名無しさん** · 2017/10/12(木) 23:06:26.57

>>470
ライセンス的に問題がないものをコピーすればいい

あ · 2017/10/13(金) 00:23:50.41

>>468
フレームワーク書いたらだめなの？

**デフォルトの名無しさん** · 2017/10/13(金) 01:47:19.56

>>470
Frameworkを使わないc#ってどんだけマゾなの？ランタイム自分で書いてんの？

**デフォルトの名無しさん** · 2017/10/13(金) 01:48:05.83

>>470
そんな理由にならない理由に従おうとする方がバカ

**デフォルトの名無しさん** · 2017/10/13(金) 02:48:12.40

今回みたいな例だとライブラリを使わないで自作するとしたら
使った場合に比べて何倍ぐらいの金額を請求する？

**デフォルトの名無しさん** · 2017/10/13(金) 02:56:05.56

バリデーションが全体の工数に占める割合がわからないとなんともいえないけど、数倍なんてなるわけないだろアホ
どんだけバリデーションばっかやってるプロダクトを想定してんだよ

客に費用の話をするとき、「通常この規模だと20人月ですが、バリデーションライブラリが使えないので+50人月かかります」とでも言うのか

**デフォルトの名無しさん** · 2017/10/13(金) 03:43:57.20

はぁ？増えた分の請求は当然するだろ。当たり前のことを当たり前にするだけだぞ

**デフォルトの名無しさん** · 2017/10/13(金) 04:33:13.10

>>476
なんでいきなりフレームワークじゃなくてライブラリの話になってんの？

**デフォルトの名無しさん** · 2017/10/13(金) 04:36:24.84

>>476
既存のフレームワーク使わずに自作する方が工数膨らむに決まってんだろ
カプコンレベルじゃないとスキル的にも厳しい

**デフォルトの名無しさん** · 2017/10/13(金) 04:37:49.67

ごめん勘違い
工数の膨らみ方が半端なさ過ぎて非現実的ってのが言いたかった

**デフォルトの名無しさん** · 2017/10/13(金) 04:40:34.82

ひとまず使って組んで元の処理コピーして置き換えちゃえばいいんちゃう？
バリデーションのソースってあんでしょ？

**デフォルトの名無しさん** · 2017/10/13(金) 05:21:13.13

>>479
バリデーションのフレームワークなんてないでしょｗ

**デフォルトの名無しさん** · 2017/10/13(金) 07:46:49.24

>>483
フレームワークの一部としてバリデーションがあるやろ

**デフォルトの名無しさん** · 2017/10/13(金) 14:51:54.32

バリデーションのフレームワーク普通にあるだろw

**デフォルトの名無しさん** · 2017/10/13(金) 16:33:32.34

ごめん、何言ってんだかよくわかんないんだけど、
まず、>>468のバリデーションって、一体何に対するバリデーションの話してるの？

**デフォルトの名無しさん** · 2017/10/13(金) 23:02:45.05

if (!validateRequired("#foo")) {
var msgFormat = getResource("error.required");
var label = getLabel("#foo");
addMessage(msgFormat, label);
addCss("#foo", "input-error");
}
以下100項目繰り返し

これ以上簡潔で保守性の高いバリデーションが存在しない件
OOPは物事を無駄に複雑化するばかりで役に立たん

**デフォルトの名無しさん** · 2017/10/13(金) 23:14:22.48

>>487
バリデーションとメッセージとUIを一緒くたにするな
どこが保守性高いんだか、見づらいだけだろ

**デフォルトの名無しさん** · 2017/10/13(金) 23:14:50.38

>>487
それは普通に抽象化できるだろ
そんなん100個も繰り封ﾔしてたらサブャCボ出るわ

**ャfフォルトの名末ｳしさん** · 2017/10/13(金) 23:16:05.73

だよなー
判定と表示は分けようって最初に教わる

**デフォルトの名無しさん** · 2017/10/13(金) 23:18:48.84

バリデーションはYAMLで定義するのが一番だって最近気づいた

**デフォルトの名無しさん** · 2017/10/13(金) 23:31:13.18

御託はいいからコード書いてみれば？
俺のコードより明確で保守性の高いコードをかけるとは思えんが

**デフォルトの名無しさん** · 2017/10/13(金) 23:36:42.10

こーゆー上から目線なやつは自分の思い描くもの以外は全部クソって発想なのでめんどくさい

**デフォルトの名無しさん** · 2017/10/13(金) 23:38:06.15

そもそも俺のコードは判定と表示が綺麗に分かれてるし

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

煽って教えてもらうスタイルに転向した？

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

きも

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

バリデーション処理はexcel表から生成するものだよ
素人は手書きするらしいけどね
プロはこんなめんどくさいコードは書かない

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

>>497
マジで！？どういう仕組み？

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

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

コピペプログラマは余計なコードを増やしてくれるな

foreach(validate as entry){
if (!validateRequired(entry.name)) {
var msgFormat = getResource(entry.resource);
var label = getLabel(entry.name);
addMessage(msgFormat, label);
addCss(entry.name, entry.clazz);
}
}

簡単に100分の1になるだろ
validateもプログラムからデータにしたら保守性あがるだろ
Modelからvalidateを収集するようにしてビジネスロジックを集約してもいいけど
今更そこまで設計変えるのは愚策か

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

>>500
これじゃ何やってるかお客様がわからないだろ
素直にエクセルにしろって

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

お客様がソース読むのかよ w
条件をお客様が決めるならExcelでもらって>>500のentryを生成するツールを作ればいいだけ

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

結局コード生成するんじゃないかwww
なら最初からコード生成する前提で余計な手書きコードは書かない方がいい
プログラミングの基本すらわかってないのかよ

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

でた、いつもの自称プロさんw

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

自称プロってwww
ここは学生専用だったか？

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

>>502
> 条件をお客様が決めるならExcelでもらって>>500のentryを生成するツールを作ればいいだけ

発想が逆。YAML形式などで条件を書いて
必要ならばExcelに変換する。
Excelなんてサイズが無駄に多すぎて差分の比較もできないから
バージョン管理は事実上無理だろ

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

YAML形式の何が良いかというとシンプルで見やすいから
お客様が直接読み書きできるってことだな
下手なCSVファイルよりもメンテナンス性が良い

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

まあそのデータなら差分出したきゃ
CSVで出して比較できそうだけどな

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

Excelでも管理できてるなら別にいいと思うぞ
客や開発メンバーのリテラシーレベルに合ってるなら
無理に違うフォーマットを強要する必要はない
openxmlとか使えば差分比較だけならできる

むしろルールと処理を密結合させても平気な神経のほうが理解できない
そのうえプロを自称してドヤるww

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

>>509
客にExcelを "ルール通りに" 使わせるという
リテラシーレベルをもとめるな

勝手にフォーマットを変える、勝手にセルを結合する。
どこからかコピペした結果おかしくなって直さない
追加分とかいって差分を送りました。そっちで結合してください
とか、毎回人手で対応しなきゃならない作業が発生するぞ。
こっちで決めた使い方のルールを守ってくれやしない

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

> openxmlとか使えば差分比較だけならできる
むり、見た目同じように見えても、
レイアウト属性など関係ない情報の
大量の差分までできて管理できない

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

>>511
属性情報は無視してdiff出せるよ
色変えたとか罫線追加したとかそのレベルの差分確認したいとなると
専用ツール入れないと実用レベルでは使えない

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

ヴァリデーションフレームワークってどれも中途半端だよな
ちょっと複雑なヴァリデーションをしようとすると適用不能になる
しょうがないからカスタムコードを書くことになるんだけどフレームワークとケンカし始めるからフレームワークは規約で禁止って流れになる
日本の厳しい要件についてこれる柔軟性の高いフレームワークは無いものか

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

>>510
その辺は上の自称プロさんならVBA使ってルール守らせるExcel作るだろ
俺は別にExcel推奨したいわけじゃないぞ

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

>>506
意味わからん
YAMLで書ける客がどれだけいるんだよ w
そもそも客がYAMLで書けるならExcelに変換なんて要らん、そのままソースに変換するなりすればいい
要件によっては実行時にそのまま読み込んでもいいかも知れんし
まあ>>500程度ならcsvとかで充分だと思うが

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

>>510
> とか、毎回人手で対応しなきゃならない作業が発生するぞ。
どんだけ低レベルの客と付き合ってるんだよ w

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

>>512
例えばこの例だと行を一行追加して、A2にあったWorldが
A3に変わった時の差分はこんなふうに表示される
http://blog.modd.com/entry/2016/01/26/125206

diff -u a.txt b.txt
--- a.txt 2017-10-14 14:16:59.481494825 +0900
+++ b.txt 2017-10-14 14:17:20.601528128 +0900
@@ -5,6 +5,12 @@
</row>
<row r="2">
<c r="A2" t="str">
+ <v>OOXML</v>
+ </c>
+</row>
+<row r="3">
+ <c r="A3" t="str">
<v>World</v>
</c>
</row>

Worldがもともとrow r="2"、c r="A3" だったわけだが、たった一行挿入することで、
2行目以下の、"全ての行データに対して" このようにrowとcが変化するわけだよ。
それで差分を管理できるわけ無いだろ。

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

>>515
> YAMLで書ける客がどれだけいるんだよ w

こっちでこんな感じで書いてくださいっていうだけ。
それはExcelと同じ。

違うのは、Excelでは条件を指定した所で
見えない情報（フォーマット情報など）が
大量に埋め込まれるということ。
そしてその見えない情報を正しく修正するのが大変だということ

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

>>516
> どんだけ低レベルの客と付き合ってるんだよ w

逆。客のレベルがExcelを無駄に使えるから
セルの結合とか色を変えたりしてくる。
Excelはできることが多すぎるんだよ。
余計なことをなんでもできてしまう。

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

>>513
> ちょっと複雑なヴァリデーションをしようとすると適用不能になる

普通はちょっと複雑なバリデーションを書くための方法がフレームワークに用意されてる。

それに、ちょっと複雑なところだけ別にやればいいだけ。

100個のうち1個のマイナーケースに対応できないから、
100個すべてめんどくさい方法で作りましたとかアホでしか無い。

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

>>520
日本の業務アプリを甘く見過ぎだろ
カスタムコード書きまくらないと対応できねえよ
アホみたいにシンプルなUIしか書かなくてもいいWeb屋はスキル要らないし気楽でいいよな

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

>>521
じゃあバリデーションのすべてがカスタムコードである例を教えてください

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

例えば郵便番号のバリデーションが
カスタムコードとか言いそうで笑えるｗ

そして郵便番号を使うたびに
同じバリデーションをコピペしてるんだろうな。

普通は関数にしてフレームワークに登録すれば終わり
あとは同じバリデーションを使いまわしできる。

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

あぁ、当たり前だけど範囲チェックや型チェックや正規表現チェックとか
単純なものだけではなく、カスタムバリデーションや条件付きバリデーションなんかも
フレームワークの基本機能の１つだと先に言っておこう

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

>>518-519
> こっちでこんな感じで書いてくださいっていうだけ。
えっ？
YAMLの書き方から教えるのかよ...
Excelでフォーマット守れって言うこともできない客にYAML書けるとか無職の妄想乙 w

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

日本の業務アプリを作っているところがアホなのは、
バリデーションが正しく機能しているかは
アプリを実行して画面からぽちぽち実際と同じ使い方をして
検証していることなんだよな。同じ内容のバリデーションであっても
項目ごとに検証する。それがテスト時間を無意味に増やしてしまっている。

本来はバリデーションのテストは種類ごとに１つ（すごく当たり前だがｗ）
そして、画面の項目ごとに、想定しているバリデーション名が
設定されているかを設定ファイルを見て確認するだけ。
実際に動かしてテストはしない。

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

>>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

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

>>525
> YAMLの書き方から教えるのかよ...

YAMLの書き方はExcelよりも簡単だよ。
Excelは知らない人が使いこなすためには
数週間とか数カ月かかるが、

YAMLだとフォーマット用意して、
これと同じように書いてくださいで説明終わり。

Excelでフォーマットを守れないのは、
これと同じように書いてくださいと言っても、使い方が難しいから。
俺の母親は、文字の自動補間機能のせいで「1」と入力しようと
しても「10」と補完されてしまって困っていたな。