TypeScript part4 (396ﾚｽ)
TypeScript part4 http://mevius.5ch.net/test/read.cgi/tech/1640872622/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
9: デフォルトの名無しさん [sage] 2022/02/06(日) 14:01:40.08 ID:23zQCz2C LAMPとか言ってPHPやPerlでバックエンド作ってた狂気の時代よりは遙かにいいと思うけどなぁ http://mevius.5ch.net/test/read.cgi/tech/1640872622/9
10: デフォルトの名無しさん [sage] 2022/02/06(日) 14:21:47.42 ID:Fo3XpFx5 型バリデーションできない人には（TypeScriptは）難しい http://mevius.5ch.net/test/read.cgi/tech/1640872622/10
11: デフォルトの名無しさん [sage] 2022/02/06(日) 14:32:39.20 ID:grglIiaK 鯖サイドは外界とのIOが多いから型バリデーションが増えすぎるのが課題かな あとはPODの濫用が標準的なコーディングスタイルとして受け入れられてる点が問題だと感じた これじゃ型があってても不変条件を満たしているかまではわからん http://mevius.5ch.net/test/read.cgi/tech/1640872622/11
12: デフォルトの名無しさん [sage] 2022/02/06(日) 14:39:40.47 ID:Fo3XpFx5 いやPODで問題ないでしょReadonlyなりas const付ければいいじゃん http://mevius.5ch.net/test/read.cgi/tech/1640872622/12
13: デフォルトの名無しさん [sage] 2022/02/06(日) 14:43:17.15 ID:23zQCz2C PODってなんぞ？ Plain Object Darkness？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/13
14: デフォルトの名無しさん [sage] 2022/02/06(日) 15:05:31.38 ID:Fo3XpFx5 型の話だしググった感じPlain Old Data型の事だと思って回答した。 プリミティブ及びプリミティブで構成されたオブジェクトからなるコンストラクタを持たないオブジェクト。ざっくり構造体みたいなオブジェクトって意味かなと。C++用語のようだ http://mevius.5ch.net/test/read.cgi/tech/1640872622/14
15: デフォルトの名無しさん [sage] 2022/02/06(日) 15:19:09.13 ID:23zQCz2C つまりPlatina Opal Diamond・・・ってコト！？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/15
16: デフォルトの名無しさん [sage] 2022/02/06(日) 15:33:19.89 ID:grglIiaK >>12 そも辺りはスケールによる ドメインが薄いならそれでなんとかなるかもしれない 実際の業務システムはどうしてもドメインが大きくなるからちゃんとクラス化しよう >>13 Plain Old Data プリミティブとPODの属性だけを持っている単純な型のこと 正確にはPODと呼ぶにはC言語とのデータ互換性が要る しかしこの文脈では緩いニュアンスで伝わると考えてPODと書いた http://mevius.5ch.net/test/read.cgi/tech/1640872622/16
17: デフォルトの名無しさん [sage] 2022/02/06(日) 15:46:19.86 ID:Fo3XpFx5 >>16 『ドメインが薄い』とか何用語だ。ググっても出てこないような独自なのじゃなくて、もうちょい一般的な用語使って？ 色々組み合わせるにしてもTS単独で大きなものを組むにしても入り口から出口までimmutableならそれで問題ないと思うんだけど。 デザインパターンにこだわり過ぎてない？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/17
18: デフォルトの名無しさん [sage] 2022/02/06(日) 16:28:56.52 ID:d9+JDYY/ 頭悪いんだよ 融通のきかない頭でっかち http://mevius.5ch.net/test/read.cgi/tech/1640872622/18
19: デフォルトの名無しさん [sage] 2022/02/06(日) 16:57:31.55 ID:23zQCz2C immutable な POD で FP すれば GOOD じゃん class は not json serializable ビコーズチョベリバ http://mevius.5ch.net/test/read.cgi/tech/1640872622/19
20: デフォルトの名無しさん [sage] 2022/02/06(日) 17:24:04.04 ID:Fo3XpFx5 無茶苦茶言ってるかと思ったらちゃんとした内容で草w http://mevius.5ch.net/test/read.cgi/tech/1640872622/20
21: デフォルトの名無しさん [sage] 2022/02/06(日) 17:45:58.69 ID:cUJBT0A1 >>17 すまん DDDのドメイン層を連想してくれると思って言った イミュータブルだから大丈夫ってのは規模の小さなシステムでならたしかに間違いではない ただ規模が大きくなるにつれてそれでは難しくなるのもまた事実 というのもイミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い なのでプログラムにバグが紛れ込みやすくなってしまう それと特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がっ
て大混乱というのが典型的な末路だね >>18 Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない 異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね なのでドメイン層のクラスがJson Serializableである必要はない というかドメイン層のクラスに直接Deserializeするのは危険なので大規模案件ではむしろ禁止した方がいい それは完全コンストラクタを経由せずにオブジェクトをインスタンス化するということであり 不正なオブジェクトを生成してしまう可能性をプログラムに埋め込むということに
他ならない http://mevius.5ch.net/test/read.cgi/tech/1640872622/21
22: デフォルトの名無しさん [sage] 2022/02/06(日) 18:34:09.22 ID:Fo3XpFx5 >>21 > イミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い 不正なイミュータブルオブジェクトの問題ってなに？ イミュータブルオブジェクトがイミュータブルオブジェクトにどうやって影響を与えるのさ。 > 特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱 疎結合になってむしろ良いことでは？ TSにおいて凝集度はクラスで担保すべきでは無いでしょ。 http://mevius.5ch.ne
t/test/read.cgi/tech/1640872622/22
23: デフォルトの名無しさん [sage] 2022/02/06(日) 18:49:51.15 ID:K22p1cEy >>22 不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い その連鎖はいずれIO境界まで辿り着きユーザーに間違ったAPIレスポンスを返したりデータベースに間違ったデータを格納したりする 関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？ もちろん途中でバリデーションをかけて落とすことはできるだろうがそれ
ではバリデーションが増えすぎて手に負えなくなる なのでそもそも間違ったオブジェクトを作れないようにしよう 作れないものを関数に渡すことはできないので安心だ そういう考え方ね 下だけどそれを疎結合とは言わない 否定したい思いが先走って無茶苦茶言ってない？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/23
24: デフォルトの名無しさん [sage] 2022/02/06(日) 19:01:45.12 ID:Fo3XpFx5 >>23 > 不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い 繰り返しになるけど、イミュータブルオブジェクトはイミュータブルオブジェクトに影響与えないよ？ > 関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？ 間違ったオブジェクト渡らないよ？ なんの為の型だと思ってるの？ structとか使わないの
？ データの入り口（IO等）で型バリデーションすればあとは型が化けたりしないよ。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/24
25: デフォルトの名無しさん [sage] 2022/02/06(日) 19:06:18.29 ID:AuLf6V7C >>21 > Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない > 異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね > なのでドメイン層のクラスがJson Serializableである必要はない 横だがこれは完全に間違ってるだろ。 シリアライズするのは確かにI/O側だが、他言語も含めて今現在は クラス側にserialize手段を用意するのが主流だ。TS知らんがJSと同じならtoJSON()。 だからドメイン側でシリアライズ
する可能性のあるクラスの全てにtoJSONを用意しておくのが正しい解だという事に今はなっている。 I/O側にやらせていたのは昔の設計だ。ただそれの何が悪かったのかは俺は知らない。 （実行効率だけは無茶苦茶良かったから、クラスを導入して非効率になっただけなのかもしれんが） http://mevius.5ch.net/test/read.cgi/tech/1640872622/25
26: デフォルトの名無しさん [sage] 2022/02/06(日) 19:18:05.78 ID:7lkHt7VO >>24 つーか「影響を与える」と私が一言でも書いたかな？ 君のレスでは影響を与えるって言葉を変化させるという意味で使ってるように読める だが私はイミュータブルオブジェクトを元にイミュータブルオブジェクトを「生成する」としか書いてない modifyとcreateはプログラミングにおいて全く異なる概念なので明確に区別することをおすすめする PODなら間違ったデータを簡単に渡せる IO境界だけでバリデーションすればいいという考え方は人間を信用しすぎている 人
間は間違えるという前提を忘れてはいけないよ 百点満点のコードを確実に書けると確信できるようなちっぽけなシステムではそれでなんとかなるかもしれないけどね http://mevius.5ch.net/test/read.cgi/tech/1640872622/26
27: デフォルトの名無しさん [sage] 2022/02/06(日) 19:28:15.98 ID:Fo3XpFx5 >>26 イミュータブルがイミュータブルなままなら問題ないって話しかしてないよ？ > 人間は間違える そのためのTypeScriptのstructだよ？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/27
28: デフォルトの名無しさん [sage] 2022/02/06(日) 19:34:50.15 ID:7lkHt7VO >>25 今はなっている？ないないなってない 適当なことを言わんでくれ JSONやXMLやバイトストリームやフォームデータのような外界の都合を吸収してシステムが扱いやすい形式に変換する(あるいはその逆の流れ)はドメイン層の仕事じゃない それは外界とやり取りをするための専門の層の仕事だ http://mevius.5ch.net/test/read.cgi/tech/1640872622/28
29: デフォルトの名無しさん [sage] 2022/02/06(日) 19:39:52.33 ID:7lkHt7VO >>27 structだけじゃ人間は間違えるし問題あるって話をしてる structではデータ型が合ってるところまでしか保証できない インスタンスが抱えてるデータが満たすべき条件を満たしていることを保証できるか？そこがポイント それを保証するにはstructでは不十分で完全コンストラクタを実装したクラスが不可欠 http://mevius.5ch.net/test/read.cgi/tech/1640872622/29
30: デフォルトの名無しさん [sage] 2022/02/06(日) 20:00:52.90 ID:Fo3XpFx5 >>29 だからデータの入り口で型バリデーションするんだよ。 君は前スレの最後で暴れてた型バリデーションできない人だったか。話が通じないわけだ。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/30
31: デフォルトの名無しさん [sage] 2022/02/06(日) 20:04:35.10 ID:+4OSlPdc >>30 だからそれじゃバリデーション箇所が多すぎて手が回らんっての 話がループしてるよ http://mevius.5ch.net/test/read.cgi/tech/1640872622/31
32: デフォルトの名無しさん [sage] 2022/02/06(日) 20:06:04.45 ID:Fo3XpFx5 >>31 だからIOとかfetchみたいなデータの入り口だけなんだよ？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/32
33: デフォルトの名無しさん [sage] 2022/02/06(日) 20:12:58.65 ID:W5e759ag >>32 またループしてる そこだけバリデーションしても人間のミスはカバーしきれない 規模の小さなシステムならなんとかなるかもしれないが大きなシステムでは絶対無理 これ以上は無限ループして時間の無駄っぽいね http://mevius.5ch.net/test/read.cgi/tech/1640872622/33
34: デフォルトの名無しさん [sage] 2022/02/06(日) 20:14:05.76 ID:Fo3XpFx5 >>33 そうだね。止めてもいいよ。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/34
35: デフォルトの名無しさん [sage] 2022/02/06(日) 20:51:55.71 ID:AuLf6V7C >>28 toJSONを呼ぶのはI/O層の仕事で、 toJSONを定義するのはドメイン層の仕事だよ。 つか、そうじゃないと無理なんだよ。 JSONでは対応出来ない型があるから、何が入っているか分からない状態ではシリアライズは出来ない。 逆に言えば何でもシリアライズ出来れば全部I/O側に任せる事は出来るのだが、 現時点で現実的にこれはバイトストリームしかないから、バイナリデータでメモリダンプ形式で良ければ出来るけど、 これはJSONともXMLとも言わないし、実際これを
やってるシステムは今は無いでしょ。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/35
36: デフォルトの名無しさん [sage] 2022/02/06(日) 21:05:05.78 ID:Y8lZmwFL >>35 ん？別の人か？ ドメイン側が提供するのは属性の読み取りアクセスと同等の引数を受け取る完全コンストラクタオーバーロードだけ 読み取った属性を外界が要求する形式に整形、シリアライズする(あるいはその逆)のはIO層の仕事 どの外界とどんな形式でやり取りするのか？ ドメイン層はそんなことは知らないし知ってはいけない だから外界に依存しない純粋な読み取り属性とコンストラクタでIO層と連携する IO層はそのデータをどうすべきか全て知っている http:
//mevius.5ch.net/test/read.cgi/tech/1640872622/36
37: デフォルトの名無しさん [sage] 2022/02/06(日) 21:14:45.88 ID:AuLf6V7C >>36 まあそれでも出来るけど、それが面倒で二度手間で意味無いからみんなPODを使ってるんだと思うぞ。 FizzBuzzEnterpriseEditionとか、君は本気でやりそうだね。 https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition http://mevius.5ch.net/test/read.cgi/tech/1640872622/37
38: デフォルトの名無しさん [sage] 2022/02/06(日) 21:24:14.91 ID:Fo3XpFx5 >>37 なんだこれww http://mevius.5ch.net/test/read.cgi/tech/1640872622/38
39: デフォルトの名無しさん [sage] 2022/02/06(日) 21:25:43.66 ID:7lkHt7VO >>37 君も話がループしてるね 面倒だからPODで済ませるで通じるちっぽけな規模ならそれでいいんだよ私は一貫してそこは否定してないでしょ？ それなりに規模が大きくなった時の話をしてんの FizzBuzzをエンタープライズの手法で作るのが馬鹿馬鹿しいのと同じように エンタープライズのシステムをFizzBuzzを書くようなノリで作るのも馬鹿馬鹿しいってこと http://mevius.5ch.net/test/read.cgi/tech/1640872622/39
40: デフォルトの名無しさん [sage] 2022/02/06(日) 21:33:21.13 ID:7lkHt7VO >>35 ちなみにバイナリでシリアライズするのはprotocol buffersとか普通にあるよ で、どんな形式で通信すんの？JSON？バイナリ？XML？CSV？ そんなのはドメイン側は知りたくない絶対に知りたくない ドメイン側がシリアライズの責務を負ってしまったらじゃあ通信の形式が増えるたびにドメイン側を拡張するのか？ そんなのドメイン側の本質とは全く関係ない通信様式の問題なのに？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/40
41: デフォルトの名無しさん [sage] 2022/02/06(日) 22:02:56.26 ID:AuLf6V7C >>40 JavaScriptといえばJSON以外無い。 そしてXMLもDOMParserでどうにでもなる。 通信形式をドメイン側と分離するべきなのは「あらゆる形式に対応する」大前提でだ。 今時JSONかXMLしかないし、実際これで事足りるからみんなこれを使ってる。 密結合が駄目なのは「変更される可能性がある箇所」であって、何でもかんでも分離すればいいというものではない。 疎結合にすれば結局間接参照を中に挟むから、実行効率もコード効率も落ちるだけ。 Protocol Buffers見て
みたが、ぶっちゃけこれ誰も使ってないだろ。 JSに対応してない時点で今現在のコンピューティングとかけ離れている。 現在もJSONで揺るぎないし、今後もJSONがさらに蔓延る雰囲気だ。 なら、ドメイン側がJSON形式に依存しても全く問題ないんだよ。 そこを無理矢理分離して、分離する意味の無いところも含めてあらゆる分離を行ってるのがFizzBuzzEnterpriseEdition。 君が言ってるのはこれ。 勿論、JSONが廃れればドメイン側のコードを書き換える必要が発生するけど、これは多分あり得ない未来なんだよ。 それでもこれに備えたければ備えるのも自由だ
けど.。 尚一応言っておくがJSONはJavaScriptObjectNotationの略で、つまりJSネイティブ形式だ。 だからPython等の他言語がJSON依存を避けるのならまだ分かるが、TS/JSで避ける意味はない。 君は完全にFizzBuzzEnterpriseEditionのノリでプログラミングをしてる。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/41
42: デフォルトの名無しさん [sage] 2022/02/06(日) 22:16:09.49 ID:jR6D7dXS PODがダメなら普通にclassを使えばいいじゃない その class に完全コントスクラタと toJSON を実装すればいい つか贅沢言いすぎや TSほどJSON API と神話性高く、堅く書けて、ほどよく柔軟な言語ないで ワイはバックエンドをGoで書かされているが、言語機能の貧弱さに発狂しそうや 爆速でコンパイルできても爆裂バグだらけじゃ話にならん http://mevius.5ch.net/test/read.cgi/tech/1640872622/42
43: デフォルトの名無しさん [sage] 2022/02/06(日) 22:20:03.49 ID:jR6D7dXS >>37 ヤバスギでしょ http://mevius.5ch.net/test/read.cgi/tech/1640872622/43
44: デフォルトの名無しさん [sage] 2022/02/06(日) 22:29:45.95 ID:7lkHt7VO あらゆる形式に対応するためじゃない責務を明確に分けるため 仮に変更される可能性がなければ１つの関数でシステムを組むのか？そうはならんやろ 変更される予定がなくても責務は分けて作るんだよお仕事ではね ProtobufはgRPC バイナリで有名なのだと他にもMessage Packとか こっちはゲームとかfluentdで有名 君はFizzBuzzのノリでエンタープライズ開発しそうだね http://mevius.5ch.net/test/read.cgi/tech/1640872622/44
45: デフォルトの名無しさん [sage] 2022/02/06(日) 22:30:03.08 ID:Uni4uKu0 そのDDDの文脈でTSだとバリデーションが必要で GoやC#だとバリデーションが必要ないケースってどんな場合のこと？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/45
46: デフォルトの名無しさん [sage] 2022/02/06(日) 22:33:52.37 ID:jR6D7dXS >>45 Goは完全コンストラクタを実装できない、誰でもインタスンス作り放題ヤリ放題だからバリデーションなんかいらんのや！ バリデーションなんて軟弱フニャチンオカマ野郎がへっぴり腰を振ってるようなもんだ！ ﾌｧｯｷｭｰLGBT！ http://mevius.5ch.net/test/read.cgi/tech/1640872622/46
47: デフォルトの名無しさん [sage] 2022/02/06(日) 22:50:56.58 ID:7lkHt7VO >>42 TypeScriptでもそうすれば良いじゃんってのはその通り 別にTypeScriptがclass使えないとかそういうことを問題視してるわけじゃぜんぜんないんだ ここで最初に戻ってよくレスを読んでみて 私が提起した問題点はこれね 「PODの濫用が標準的なコーディングスタイルとして受け入れられてる」 この問題に関しては言語自体の話題じゃないんだよ ようするに今日やったような問答をTypeScript人材を雇うと毎回全員にやらなきゃならない可能性が高いってこと これじゃ
申し訳ないけど仕事にならないよ なので鯖サイドではTypeScriptは残念だけど人集めの段階でNGってことになるわけ 規模でかくなるのわかってるんだから最初から鯖サイドではちゃんとレイヤ分けましょうねクラス使いましょうねSOLIDなコード書きましょうねでスッと話が通じる人が多い言語で計画立てたいわけさ そうなると古臭いけどJavaなど無難な選択肢しかないんだよな… http://mevius.5ch.net/test/read.cgi/tech/1640872622/47
48: デフォルトの名無しさん [sage] 2022/02/06(日) 22:57:06.33 ID:AuLf6V7C >>44 まあ君とは平行線のようだね。 > 仮に変更される可能性がなければ１つの関数でシステムを組むのか？ 組むぞ。俺は変更される可能性がない所に依存するのは全く問題ないと見てる。 そして基本的に実行効率重視だから、無駄な事はしない。 君はドメインが「１年が365日である事を知っている必要はない」として、365すらもリテラルでは書かないのだろう。 そして人類が火星に到達した時、君のコードは無修正で動くが、俺のコードは役に立たない。 でも俺は、
「一方ロシアは鉛筆を使った」は大切にすべきだと思ってるから、 365はリテラルで書いてしまって、火星に到達してから書き直す事を選択する。 俺はJSONが廃れる未来なんてないと思ってるから、コードがJSON形式に依存するのも何ら問題を感じないし、 今のJSのアーキテクチャ、つまりtoJSONを整備しろ、で全く問題ないと思ってる。 これは確かに分離出来てないアーキテクチャだけど、する意味もないと思うよ。 むしろ他言語でもJSON使えないのはポンコツ扱いだろ今は。 > gRPC > Message Pack > fluentd JSONがあまり効率のいい形式ではな
いのは事実で、これに対する策のようだね。 ただ、俺ならI/O層でJSON形式から変換させる。 つまりドメイン層はtoJSONを定義して、それでおしまい。それ以上の形式が欲しければI/O層で変換だ。 君のアプローチより現実的だと思うけど。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/48
49: デフォルトの名無しさん [sage] 2022/02/06(日) 23:02:11.49 ID:AuLf6V7C >>47 そりゃお前のノリでやってくれる奴はお前の畑の奴だよ。 それがJavaならそうすればいいだけ。 ただ、PODが駄目だってのはただの先入観で、 実際それでやってる奴が多くて、それでも世界が回ってるのなら、お前が勘違いしてるだけだよ。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/49
50: デフォルトの名無しさん [sage] 2022/02/06(日) 23:08:32.84 ID:7lkHt7VO >>48 うん TypeScripterとは分かり合えない人が多いだろうなとは思ってたけど君とは特に分かり合えないと思う 関数１つでシステム書く人を理解するのは私には不可能だ 365をリテラルで書かないのはDDDとかそれ以前の問題だと思うよ 君の書いたコードって四年に一回ぐらいバグ出してない？大丈夫？ 処理効率が大事な部分でわざわざJSONを経由して効率落とすの？ ライブラリ開発者が必死になって直列化コストを削減してくれたのを嘲笑うかのような所業 やっぱり理解
できないや http://mevius.5ch.net/test/read.cgi/tech/1640872622/50
51: デフォルトの名無しさん [sage] 2022/02/06(日) 23:09:14.59 ID:7lkHt7VO >>49 それで回る規模の世界はそりゃ回るだろうね これも何度も言ってるよね http://mevius.5ch.net/test/read.cgi/tech/1640872622/51
52: デフォルトの名無しさん [sage] 2022/02/06(日) 23:34:35.72 ID:EROXxvgE なら、その規模を確認してからでよかったんじゃね？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/52
53: デフォルトの名無しさん [sage] 2022/02/06(日) 23:46:30.23 ID:AuLf6V7C >>50 いずれにしてもJava出身でJava流の開発をしたいのならJavaを使うべきだよ。 シェアもJSよりはあるし、実際何とかなるだろう。 https://w3techs.com/technologies/details/pl-java > 処理効率が大事な部分でわざわざJSONを経由して効率落とすの？ 開発効率を優先するって事だよ。多分Web系の連中はこっちを選択する。 （俺はWeb系ではないが） なおJSONも効率が悪いのは無駄にダブルクオーテーションが多いくらいだから、この方式でもさほど効率は落ちない
よ。 >>51 規模に対してのアプローチが根本的に違うんだよ。 Java：どんなに大規模になってもメンテ出来るようなコードを目指す。コードはひたすらメンテ。 Web系：そもそも大規模にならないように、ひたすらマイクロサービスを目指す。コードは書き捨て。 Java流のまどろっこしいコードだとサクッと変更出来ないからこうなってるのだと思うよ。 実際、Web系だとサーバー側全コードを書き直しました、とか割と聞くでしょ。Javaではあり得ないし。 だから、Web系言語で、そんなに大規模になるという事自体が間違ったアプローチなんだよ。 そう
いう風に言語が出来てない。toJSONという点からも分かるだろ。 俺もこのアプローチの違いに気づいた時はちょっと驚いたけど、間違いでもないよ。 これを認められないのなら、君はJavaでやるべきだよ。 あと、依存に関する考え方も違う。 Web系で危険な依存は、死んでしまう言語/フレームワーク/ライブラリに依存する事で、 具体的にはAltJSのほぼ全部(CoffeeScript等)、Vue/React以外のフレームワーク全部とかだよ。 仮にprotocol buffersを使うとして、頓死した場合、I/O部分は書き直さないといけない。 それはドメイン側のコードをいじるのと同じ
手間だと思うけど。 だったら、分離した意味って無いよね。 まあいずれにしても、君はJavaを選択すべきだと思うけど。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/53
54: デフォルトの名無しさん [sage] 2022/02/07(月) 03:29:33.54 ID:yhez4jOW あと、パフォーマンスレンジの選択も間違ってる。 スクリプト言語は、チャッチャと書いてチャッチャと動かす為の言語であって、 ゴリゴリ一生懸命コードを書いて、パフォーマンスやメンテナンス性を得るための言語ではない。 つまり、今回で言うと、 TS/JSはJSONで全く問題無い場合に使う言語であって、 JSONではパフォーマンスに問題があると分かっているのなら、GoかRustを使うべき。 勿論Javaでもいいが、RustならJavaより速い。 だからこそ逆に、手抜きして何が悪い
！ってことになる。 要求仕様が「オブジェクトを復旧できること」なら、 一番簡単なのはJSONで、これを使う人が多いのは当然だ。 一々自前でコードを書きたくなければPODになる。これがいいかどうかはさておき。 (ただまあ俺も、Web系の連中はJavaのstaticおじさんを馬鹿にする割には 書いてるコードがstaticおじさんと同じなのはどうなのよ、とは思ったが) ちなみに主張されてるようなケースでJavaならイテレータでも渡してI/O側でシリアライズするのか？ 単純なイテレータだと階層があったら厳しいから、階層も跨いでいけるイテレータを渡す事にな
りそうだが、 それでもデータの中身が何か知ってないとシリアライズは厳しくて、 現実的に完全に分離するのは無理だと思うが。 なおメンテナンス性についてはTS/JSは以外に高い。 こういう構造にしたい、というのはあっけないほど簡単に記述出来るから、分離だけは簡単だ。 (ただ、その分離の意味があるのか？が俺には疑問なのだが) http://mevius.5ch.net/test/read.cgi/tech/1640872622/54
55: デフォルトの名無しさん [sage] 2022/02/07(月) 03:30:51.04 ID:yhez4jOW それから、規模については他の人も指摘してるけど、一体何万行のTSを書く気だ？ やれば分かるが、鯖なんて結局DBから読んで加工して吐くだけだから、 APIだけ(HTML生成無し)なら3,000行も書けばいっぱしのサービスは出来てしまう。 あっけないほど簡単にね。スクリプト言語だから記述レベルが元々高いってのもあるけど。 (HTML部分はどこまで凝るかだけど、コード自体は独立してるから分量が多くなっても何ら問題ないはず) Javaから見ればWeb系は多分1/10位で開発してる
。 Redditで6人(言語不明)、diggも6人(Go)、discordが35人(Rust)とかだったと思ったよ。 そもそもそんな「大規模開発」になってない。 この辺を知って、俺は「あれ？これはJavaのアプローチの方が間違ってたんじゃね？」と思いだしたんだよ。 OOP：どんなに大規模なコードでも取り扱ってみせる！ スクリプト言語：そもそも複雑にならない範囲に留めろ Javaから見ればWeb系は馬鹿ばっかなのも事実だろうけど、JavaはJavaで馬鹿な事をやってる。 だから特等席を与えられていたのにJSに駆逐された。(クライアントサイドでは) それって鉛筆でよくね？っ
てのを考えた方がいいと思うぜ。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/55
56: デフォルトの名無しさん [sage] 2022/02/07(月) 06:51:13.72 ID:b69Z+ASC TSの知識が無くTSの開発者文化に馴染めず、理解してない言葉を並べ、決して間違いを認めず、自分のやり方に固執し、目の前にある概念を理解しようともしない。 う〜んこのおっさん。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/56
57: デフォルトの名無しさん [sage] 2022/02/07(月) 10:07:24.70 ID:WuDoUI67 >>55 ううむ…せめてレス読んで理解した上で応答してほしいんだが… 小さなシステムでやり方にこだわる必要はないってのは深夜3時までかけて書いた情熱的な作文でいちいち主張しなくても私も最初から認めてることでしょ？ 昨日議論したのはそういう手法が通じない規模のシステムの話ね(何度もそう書いてるはずだが) 大きいシステムではうまくいかないよという話をしてるのに その応答が小さなシステムならうまくいくから問題ないでは話が噛み合うわけがないよね h
ttp://mevius.5ch.net/test/read.cgi/tech/1640872622/57
58: デフォルトの名無しさん [sage] 2022/02/07(月) 11:40:42.69 ID:RorkGoUL いやでもわかるわ json serializable / deserializable で、かつ this 参照可能な method 生えてれば、カプセル化というかコードの凝縮度上げられるのになとは思う まぁそういう toJSON, fromJSON を実装すれば的な話ではあるが type Human に getFullName 実装したい時に POD だと getFullName(h: Human) みたいになって getFullName(h) じゃなく h.getFullName() みたいにしたかったのに みたいな http://mevius.5ch.net/test/read.cgi/tech/1640872622/58
59: デフォルトの名無しさん [sage] 2022/02/07(月) 11:50:23.99 ID:UTO8dkwM 凝集度をclassで確保する必要は無いんやで。 書き方についてもパイプライン演算子がstage2入ったしね http://mevius.5ch.net/test/read.cgi/tech/1640872622/59
60: デフォルトの名無しさん [sage] 2022/02/07(月) 11:58:19.03 ID:UTO8dkwM Rustのstructとimplみたく、型とそれに付随する関数を収めたモジュールを作るんや。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/60
61: デフォルトの名無しさん [sage] 2022/02/07(月) 12:40:58.10 ID:yhez4jOW >>57 だから何万行書くつもりなんだ？って聞いてるんだよ。 Webの場合は3層なりに強制的に分割されるし、状態管理はDBに丸投げ、View/UIはHTML/CSS/JSに丸投げなので、 鯖でやる事なんて大して無いんだよ。 セキュリティガバガバでよく、（＝社内向けシステムに表示するだけとか) ORMまでセットアップされてれば、 fizzbuzzの次には掲示板でも作ってみようか、となるくらい単純に出来てる。 だからこそPHPみたいな糞言語が未だに主流なわけでさ。 あれほどの糞言
語でも何とかなる程度に収まってんだよ。 ここら辺はやれば分かるんだが、君はやってもないのにJava的な開発を想定しているからおかしな事になってる。 だから1/10想定で、と言ってるわけでさ。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/61
62: デフォルトの名無しさん [sage] 2022/02/07(月) 12:41:25.24 ID:yhez4jOW > 大きいシステムではうまくいかないよという話をしてるのに これが間違ってる。大きいシステムが存在しない世界なんだよ。 なぜなら、大きくなった部分は切り出され、まだ切り出されてない残り部分しか書かない方式だから。 ユーザーデータの管理が面倒です→DBとして切り出して丸投げ HTML生成が面倒です→フレームワークに丸投げ DBを触るのが面倒です→クエリビルダにしますか？ORMにしますか？ セッション管理も面倒です→ではこれもフレームワークで だからフ
レームワークは基本的に小粒だし、場合によってはいきなり頓死する。 でもフレームワークまみれで良ければいくらでも手抜き出来る世界だし、それで良しとされてる。 そしてWeb系プログラマは基本的に技術的には非力で、これは「スクリプタをプログラマと呼ぶな」とか言われてたりするが、 だからこそ逆に、自分より上の連中が作ったフレームワークに乗っかる事に抵抗がない。 Javaの連中や、最近の初心者は、手段が目的化してしまってる。 疎結合にする事、綺麗なコードを書く事が目的になってしまってる。それは本来は手段だ。 本来の目的は、「仕
様を満たすコードを最速で得る事」だよ。 その際にコードの複雑化が障害になるので疎結合や綺麗なコードが必要になるわけだが、 逆に、ひたすら切り出して絶対に複雑化させない、というアプローチをWeb系は採ってる。 OOPだと大体1,000-3,000行で各モジュールは出来、この単位で切り出して行ってるはずだが、 Web系だと本当に数行で書けるような事すら切り出してたりするし、ここまでやれば大規模化や複雑化は絶対にしない。 逆に依存性は問題になってくるから、みんな動向には敏感だろ。 どっちが良いというものでもないけど、俺はこのWeb系のやり方
もありだと思うよ。 すくなくともWeb系の常識からすると、みずほ銀行のポンコツシステムとかあり得ない。 最終的には口座への入出金だけガッツリ管理出来ればいいだけなのに、何でそんなに落ちるんだよ？でしかない。 Javaの流儀でサーバー側を作るのも技術的には可能だけど、それが主流でないって事は、 Javaエンジニアなんて腐るほどいるのだし、「やらなかった」のではなく「上手く行かなかった」と考えた方が妥当だと思うけど。 それでもやるのはどうぞご自由にだが。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/62
63: デフォルトの名無しさん [sage] 2022/02/07(月) 12:44:13.86 ID:NQzt3ZES >>60 それが完璧にできればいいんだが、それだと大きなシステムでは統制が行き届かず、処理が分散し凝集度が下がる、というのは過去の実績から明らかなんだよね そのスタイルでやろうとすると人間がミスをしない、という前提が必要になるんだけど、現実的にそれは難しい なので大きい案件では「間違えるためには手間がかかる状態」を作り出して人間のミスを抑止するわけ クラスなら処理の置き場所がはっきりしてるだけでなく、他の場所に書こうとすると別のクラスが
必要になるので間違いに気付き易くなる なので自然と処理が然るべきクラスに集まって、凝集度が高まるって話 何度も何度も言ってるけど 管理コストのスケーリングを考えなくていい、個人や小さなチームで作れる範囲なら、PODと関数でいいんじゃないかな？ その程度ならプログラマが注意深く作業すれば、ミスなく作れるからね 雑談として脱線するけど、ただデータを流すだけ的な小さいサービスは今後はノーコードが主流になると思う 鯖サイドTSのメインターゲットがそういうスモールサービスだとしたら、将来はもしかしたらノーコードとのシェア争い
になるのかもね http://mevius.5ch.net/test/read.cgi/tech/1640872622/63
64: デフォルトの名無しさん [sage] 2022/02/07(月) 12:57:08.26 ID:UTO8dkwM >>63 モジュール関数がそうなる状況ではclassもそうなるよ？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/64
65: デフォルトの名無しさん [sage] 2022/02/07(月) 12:59:32.42 ID:yhez4jOW >>58 > getFullName(h) じゃなく > h.getFullName() みたいにしたかったのに > みたいな それはC#で言う拡張メソッドだね。staticメソッドをインスタンスメソッドとして『記述出来る』 Goは逆にメソッドをstaticとして呼べたはずだけど。 この辺は『どう書きたいか』であり、文法の問題であって、（本来は）コード構造の問題ではない。 C#はこの辺の文法とコード構造を分離した。 つまり、メソッドとして書きたいからクラスにします、ではなく、 メソッド
として書きたければメソッドとして書ける文法（拡張メソッド）を用意した。 まあ実際はただのパッチだけどね。何故かは知らんが.NETは無駄にstaticメソッドが多くてウザイのは事実だから。 (ただ今見てみるとC#のはPODでは駄目っぽいが) Rubyはこの辺、プリミティブなしで全部オブジェクトだから、数字にもメソッドを生やせるし、出来る素地はある。 （やってないと思うけど） だからJSでやるならボックス化+拡張メソッドで、ということになる。 再度言うがこの辺は文法の話（に出来る話）であって、（本来は）コード構造の話ではないよ。 http://me
vius.5ch.net/test/read.cgi/tech/1640872622/65
66: デフォルトの名無しさん [sage] 2022/02/07(月) 13:01:33.92 ID:NQzt3ZES >>61 業務システムは何万行の単位じゃ足りない そこから1桁2桁は増える 君が幸運にも高々数千行の平和なシステムとしか縁がない環境にいるのはよくわかったよ でも世の中のシステムはそんな恵まれたももばかりじゃないんだ 企業の業務がどれだけ複雑で巨大なのか想像してみたことある？ 適当にそれなりの規模の企業をピックアップしてどんな仕事してるか想像して見て？ データベースやIOや画面とか全部取っ払ってドメインロジックだけでいいよ それを君は3000行ぽ
っちで実装できるのかい？ もしできるというなら今すぐにそのシステムを売り込みに行った方がいい あっという間に大金持ちだ http://mevius.5ch.net/test/read.cgi/tech/1640872622/66
67: デフォルトの名無しさん [sage] 2022/02/07(月) 13:05:14.01 ID:RorkGoUL >>59 パイプ何年かかっとんねん パイプ待ってる内にシステムサ終ですわ object の後のドットで補完できると絶頂射精できるんや パイプなんてどうやっても補完できないし無理無理かたつむり http://mevius.5ch.net/test/read.cgi/tech/1640872622/67
68: デフォルトの名無しさん [sage] 2022/02/07(月) 13:13:31.34 ID:wsXwvKB4 >>64 頻度の話ね http://mevius.5ch.net/test/read.cgi/tech/1640872622/68
69: デフォルトの名無しさん [sage] 2022/02/07(月) 13:18:28.93 ID:UTO8dkwM >>67 そういう事なら仕方ないなw 可変長パイプ関数TSで作るのは確かに辛いけど、とりあえずこんなんで良くね？ https://stackoverflow.com/questions/65154695/typescript-types-for-a-pipe-function http://mevius.5ch.net/test/read.cgi/tech/1640872622/69
70: デフォルトの名無しさん [sage] 2022/02/07(月) 13:29:41.52 ID:yhez4jOW >>66 > 業務システムは何万行の単位じゃ足りない それは仕様を絞り込めてない糞だからだよ。 既に言ったとおり、銀行のシステムなんて最終的には「口座への入出金管理」でしかないだろ。 だったらそれをまず作って、これが3,000行。 そしてそれが株からなら、株を管理する鯖を立てて、これも3,000行。 オンラインバンキングが欲しければ、これもUI専用鯖を立てて3,000行。とやっていくのがマイクロサービス流。 モノリシックには作らないから、でかくなりようが
ない。 この辺は発想の違いで、以下が分かりやすいが、 https://note.com/tsuchie88/n/ncae14ac6466b SMBCがマイクロサービス的で、君が見てる世界は三菱UFJのモノリシック型だね。 どっちが良いとかいう単純な話でもないのだけど。 まあいずれにしてもやりたいようにやればいいとは思うよ。 俺はそれは「誰も思いつかなかった」のではなく、「既に失敗してるから今は誰もやってない」だけだと思うけど。 文化の形成過程って、これだと思うし。 文化を否定する前に、まず何故そんな文化になってるのかを考えるべきだよ。 それは何だかんだで現時点で
の最適化がかかった状態ではあるのだから。 >>63 フレームワークをこねくり回すだけで出来るものはノーコードが主流になるとは思う。 ただしそれでWeb系言語が廃れる事はない。フレームワークになってない部分は自前で書くしかないので。 なお主にマイクロサービスを目指しているのはGoだね。みんなRustに行っちゃった感はあるけど。 TSは…JSだと型が無くて糞だと思ってる連中が使ってるはずだけど、何指向かは知らん。 （というか俺はTS使ってないし) http://mevius.5ch.net/test/read.cgi/tech/1640872622/70
71: デフォルトの名無しさん [sage] 2022/02/07(月) 13:33:18.79 ID:Afq51Jp9 業務システムにオープン系入ってきてもう何十年よ プロジェクト規模ならわかるがシステム規模で何十万行とか ミドルウェアも活用できてない失敗プロジェクト DSLで品質も保ててスッキリ記述できる部分も汎用言語で書いてそう http://mevius.5ch.net/test/read.cgi/tech/1640872622/71
72: デフォルトの名無しさん [sage] 2022/02/07(月) 13:36:19.77 ID:Ipfs3xdV >>70 ははは ならその素晴らしい数千行の銀行システムを売り込んできたら？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/72
73: デフォルトの名無しさん [sage] 2022/02/07(月) 13:40:37.88 ID:UTO8dkwM 途中までの思想はわかるけど、数千行銀行はちょっと無理だと思うよ…… http://mevius.5ch.net/test/read.cgi/tech/1640872622/73
74: デフォルトの名無しさん [sage] 2022/02/07(月) 13:46:02.77 ID:UTO8dkwM とはいえ分割単位次第か http://mevius.5ch.net/test/read.cgi/tech/1640872622/74
75: デフォルトの名無しさん [sage] 2022/02/07(月) 13:58:43.68 ID:yhez4jOW >>72 今は俺はJavaを殺すのはWeb系だと思ってるよ。 何処かが「もうこれWeb系でよくね？」として試しにやってみて成功したら、一気に流れると思う。 開発/運用コストが1/10〜1/100だろうから、 金銭面しか評価出来ない文系馬鹿が仕切ってる日本の銀行とかは一気に導入だよ。 マジな話、みずほ銀行が作り直すのならマイクロサービスでやれば面白いとは思ってる。 まあ現実的には病院や自治体から導入で、銀行は最後尾だろうけどね。 >>73 それは発想の
方向の違い。 単発サービスで3,000行程度に留まるところまでサービスを分割する。 できるできないではなく、3,000行程度になるまでひたすら分割するだけ。 実際、DBに対して単に読み書きするだけなら、200行程度で書けるでしょ。 だから最悪、1,000行程度までのマイクロサービスに分割しろ、と言われても普通に出来てしまうんだよ。 http://mevius.5ch.net/test/read.cgi/tech/1640872622/75
76: デフォルトの名無しさん [sage] 2022/02/07(月) 14:09:33.83 ID:UTO8dkwM >>75 そういう意味なら納得です http://mevius.5ch.net/test/read.cgi/tech/1640872622/76
77: デフォルトの名無しさん [sage] 2022/02/07(月) 14:10:07.39 ID:4z8oj16v 素晴らしい！ ひとりの天才の出現によって金融系システム従事者が超難度システムのメンテから解放されるんだね 私はもしかすると時代の転換点を最も近いところから目撃してしまったのかもしれない http://mevius.5ch.net/test/read.cgi/tech/1640872622/77
78: デフォルトの名無しさん [sage] 2022/02/07(月) 14:19:47.08 ID:RorkGoUL >>69 lodash compose かな まぁあれはあれで前立腺イキな気持ちよさはある http://mevius.5ch.net/test/read.cgi/tech/1640872622/78
79: デフォルトの名無しさん [sage] 2022/02/07(月) 14:20:45.58 ID:RorkGoUL >>77 みずほ社員２０万人「ﾀｽｹﾃ・・・ﾀｽｹﾃ・・・」 http://mevius.5ch.net/test/read.cgi/tech/1640872622/79
80: デフォルトの名無しさん [sage] 2022/02/07(月) 14:27:40.67 ID:mmIvHtEJ ちゅーかなんでみんながみんなクソデカカチカチシステム作る前提なわけ？ 適材適所って言葉を知らんのか http://mevius.5ch.net/test/read.cgi/tech/1640872622/80
81: デフォルトの名無しさん [sage] 2022/02/07(月) 14:43:03.87 ID:UTO8dkwM >>78 lodash有りならlodash/fpにそのままズバリpipeもあるし、部分適用もお手の物やん http://mevius.5ch.net/test/read.cgi/tech/1640872622/81
82: デフォルトの名無しさん [sage] 2022/02/07(月) 14:51:15.15 ID:RorkGoUL >>80 だって小さいシステムなら誰でも作れるじゃん それこそPHPやPerlでも構わな・・・くはない死にたくなるけど、まぁやってやれんことはない っぱエンジニアは20万人月回してこそ1人前でしょ http://mevius.5ch.net/test/read.cgi/tech/1640872622/82
83: デフォルトの名無しさん [sage] 2022/02/07(月) 14:55:26.17 ID:R1s+yfGI それにしてもマイクロサービス万能論者って久々に見た気がするわ サービスを分割すればするほどサービス間の連動の管理が難しくなってそれはそれでうまくいかないぞ というんでモジュラーモノリスだとか色々回帰論が出てきて今となっては「やっぱり銀の弾丸はなかったね」が常識で通じる時代になったと思ったんだが… 仮に30万行のシステムがあったとしてそれを3000行に分割したら単純計算で100個に分割できるわけだ 100種類のサービスを間違いなく連動させるのがどれだ
け大変なことなのか ちょっと甘く見過ぎてる感じがするね？ http://mevius.5ch.net/test/read.cgi/tech/1640872622/83
84: デフォルトの名無しさん [sage] 2022/02/07(月) 15:01:35.38 ID:dHoIQX/o >>61 >Webの場合は3層なりに強制的に分割されるし、状態管理はDBに丸投げ、View/UIはHTML/CSS/JSに丸投げなので、 >鯖でやる事なんて大して無いんだよ。 どんだけ無知なんだよww 流石にこのレベルで偉そうに語られると相手するのが恥ずかしくなる http://mevius.5ch.net/test/read.cgi/tech/1640872622/84
85: デフォルトの名無しさん [sage] 2022/02/07(月) 15:02:48.84 ID:HmGAn9CY >>82 TS開発者全てを20万人月扱うスーパーマンにするなw http://mevius.5ch.net/test/read.cgi/tech/1640872622/85
86: デフォルトの名無しさん [sage] 2022/02/07(月) 15:13:48.61 ID:27SiZacg >>75 相手がボロ出すまで同じ事繰り返すだけの自演おじさんなんて相手しなくて良いよ。おじさんの話の内容見てても読解力もTS理解度も足りてないんだし http://mevius.5ch.net/test/read.cgi/tech/1640872622/86
87: デフォルトの名無しさん [sage] 2022/02/07(月) 15:26:53.69 ID:S/gDVAW3 DDD的な話はわりとまともなこと言ってるけど コード例を出さないからTS固有の問題なのか使い方や作り方の問題なのか判別つかないね http://mevius.5ch.net/test/read.cgi/tech/1640872622/87
88: デフォルトの名無しさん [sage] 2022/02/07(月) 15:33:02.79 ID:S/gDVAW3 銀行みたいに堅牢性や永続性が最重要のシステムをTSで作るわけないけど 変化に対する柔軟性に重きを置くシステムならサーバー側でもTSは有力な選択肢だと思う UnionやIntersectionのおかげでFunctionalなDDDがやりやすいってのが一番の理由 JavaみたいにOOPベースのDDDやるならTSを選ぶメリット感じない http://mevius.5ch.net/test/read.cgi/tech/1640872622/88
89: デフォルトの名無しさん [sage] 2022/02/07(月) 16:02:48.76 ID:UTO8dkwM >>87 それだよねぇ。長い文章書くわりに具体的な内容無いもの http://mevius.5ch.net/test/read.cgi/tech/1640872622/89
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 307 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.027s