TypeScript part4

TypeScript part4 (377ﾚｽ)
上下前次 1-新

45(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:30:03.08 ID:Uni4uKu0(1) AAS
そのDDDの文脈でTSだとバリデーションが必要で
GoやC#だとバリデーションが必要ないケースってどんな場合のこと？

46: デフォルトの名無しさん [sage] 2022/02/06(日) 22:33:52.37 ID:jR6D7dXS(3/3) AAS
>>45
Goは完全コンストラクタを実装できない、誰でもインタスンス作り放題ヤリ放題だからバリデーションなんかいらんのや！
バリデーションなんて軟弱フニャチンオカマ野郎がへっぴり腰を振ってるようなもんだ！
ﾌｧｯｷｭｰLGBT！

47(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:50:56.58 ID:7lkHt7VO(7/9) AAS
>>42

42(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:16:09.49 ID:jR6D7dXS(1/3) AAS
PODがダメなら普通にclassを使えばいいじゃない
その class に完全コントスクラタと toJSON を実装すればいい

つか贅沢言いすぎや
TSほどJSON API と神話性高く、堅く書けて、ほどよく柔軟な言語ないで
ワイはバックエンドをGoで書かされているが、言語機能の貧弱さに発狂しそうや
爆速でコンパイルできても爆裂バグだらけじゃ話にならん

TypeScriptでもそうすれば良いじゃんってのはその通り
別にTypeScriptがclass使えないとかそういうことを問題視してるわけじゃぜんぜんないんだ

ここで最初に戻ってよくレスを読んでみて
私が提起した問題点はこれね
「PODの濫用が標準的なコーディングスタイルとして受け入れられてる」
この問題に関しては言語自体の話題じゃないんだよ

ようするに今日やったような問答をTypeScript人材を雇うと毎回全員にやらなきゃならない可能性が高いってこと
これじゃ申し訳ないけど仕事にならないよ
なので鯖サイドではTypeScriptは残念だけど人集めの段階でNGってことになるわけ

規模でかくなるのわかってるんだから最初から鯖サイドではちゃんとレイヤ分けましょうねクラス使いましょうねSOLIDなコード書きましょうねでスッと話が通じる人が多い言語で計画立てたいわけさ
そうなると古臭いけどJavaなど無難な選択肢しかないんだよな…

48(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:57:06.33 ID:AuLf6V7C(5/7) AAS
>>44

44(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:29:45.95 ID:7lkHt7VO(6/9) AAS
あらゆる形式に対応するためじゃない責務を明確に分けるため
仮に変更される可能性がなければ１つの関数でシステムを組むのか？そうはならんやろ
変更される予定がなくても責務は分けて作るんだよお仕事ではね

ProtobufはgRPC
バイナリで有名なのだと他にもMessage Packとか
こっちはゲームとかfluentdで有名

君はFizzBuzzのノリでエンタープライズ開発しそうだね

まあ君とは平行線のようだね。

> 仮に変更される可能性がなければ１つの関数でシステムを組むのか？
組むぞ。俺は変更される可能性がない所に依存するのは全く問題ないと見てる。
そして基本的に実行効率重視だから、無駄な事はしない。

君はドメインが「１年が365日である事を知っている必要はない」として、365すらもリテラルでは書かないのだろう。
そして人類が火星に到達した時、君のコードは無修正で動くが、俺のコードは役に立たない。
でも俺は、「一方ロシアは鉛筆を使った」は大切にすべきだと思ってるから、
365はリテラルで書いてしまって、火星に到達してから書き直す事を選択する。

俺はJSONが廃れる未来なんてないと思ってるから、コードがJSON形式に依存するのも何ら問題を感じないし、
今のJSのアーキテクチャ、つまりtoJSONを整備しろ、で全く問題ないと思ってる。
これは確かに分離出来てないアーキテクチャだけど、する意味もないと思うよ。
むしろ他言語でもJSON使えないのはポンコツ扱いだろ今は。

> gRPC
> Message Pack
> fluentd
JSONがあまり効率のいい形式ではないのは事実で、これに対する策のようだね。
ただ、俺ならI/O層でJSON形式から変換させる。
つまりドメイン層はtoJSONを定義して、それでおしまい。それ以上の形式が欲しければI/O層で変換だ。
君のアプローチより現実的だと思うけど。

49(1): デフォルトの名無しさん [sage] 2022/02/06(日) 23:02:11.49 ID:AuLf6V7C(6/7) AAS
>>47
そりゃお前のノリでやってくれる奴はお前の畑の奴だよ。
それがJavaならそうすればいいだけ。

ただ、PODが駄目だってのはただの先入観で、
実際それでやってる奴が多くて、それでも世界が回ってるのなら、お前が勘違いしてるだけだよ。

50(1): デフォルトの名無しさん [sage] 2022/02/06(日) 23:08:32.84 ID:7lkHt7VO(8/9) AAS
>>48
うん
TypeScripterとは分かり合えない人が多いだろうなとは思ってたけど君とは特に分かり合えないと思う
関数１つでシステム書く人を理解するのは私には不可能だ

365をリテラルで書かないのはDDDとかそれ以前の問題だと思うよ
君の書いたコードって四年に一回ぐらいバグ出してない？大丈夫？

処理効率が大事な部分でわざわざJSONを経由して効率落とすの？
ライブラリ開発者が必死になって直列化コストを削減してくれたのを嘲笑うかのような所業
やっぱり理解できないや

51(1): デフォルトの名無しさん [sage] 2022/02/06(日) 23:09:14.59 ID:7lkHt7VO(9/9) AAS
>>49
それで回る規模の世界はそりゃ回るだろうね
これも何度も言ってるよね

52: デフォルトの名無しさん [sage] 2022/02/06(日) 23:34:35.72 ID:EROXxvgE(1) AAS
なら、その規模を確認してからでよかったんじゃね？

53: デフォルトの名無しさん [sage] 2022/02/06(日) 23:46:30.23 ID:AuLf6V7C(7/7) AAS
>>50
いずれにしてもJava出身でJava流の開発をしたいのならJavaを使うべきだよ。
シェアもJSよりはあるし、実際何とかなるだろう。
外部ﾘﾝｸ:w3techs.com

> 処理効率が大事な部分でわざわざJSONを経由して効率落とすの？
開発効率を優先するって事だよ。多分Web系の連中はこっちを選択する。
（俺はWeb系ではないが）
なおJSONも効率が悪いのは無駄にダブルクオーテーションが多いくらいだから、この方式でもさほど効率は落ちないよ。

>>51
規模に対してのアプローチが根本的に違うんだよ。
Java：どんなに大規模になってもメンテ出来るようなコードを目指す。コードはひたすらメンテ。
Web系：そもそも大規模にならないように、ひたすらマイクロサービスを目指す。コードは書き捨て。

Java流のまどろっこしいコードだとサクッと変更出来ないからこうなってるのだと思うよ。
実際、Web系だとサーバー側全コードを書き直しました、とか割と聞くでしょ。Javaではあり得ないし。
だから、Web系言語で、そんなに大規模になるという事自体が間違ったアプローチなんだよ。
そういう風に言語が出来てない。toJSONという点からも分かるだろ。

俺もこのアプローチの違いに気づいた時はちょっと驚いたけど、間違いでもないよ。
これを認められないのなら、君はJavaでやるべきだよ。

あと、依存に関する考え方も違う。
Web系で危険な依存は、死んでしまう言語/フレームワーク/ライブラリに依存する事で、
具体的にはAltJSのほぼ全部(CoffeeScript等)、Vue/React以外のフレームワーク全部とかだよ。
仮にprotocol buffersを使うとして、頓死した場合、I/O部分は書き直さないといけない。
それはドメイン側のコードをいじるのと同じ手間だと思うけど。
だったら、分離した意味って無いよね。

まあいずれにしても、君はJavaを選択すべきだと思うけど。

54: デフォルトの名無しさん [sage] 2022/02/07(月) 03:29:33.54 ID:yhez4jOW(1/12) AAS
あと、パフォーマンスレンジの選択も間違ってる。
スクリプト言語は、チャッチャと書いてチャッチャと動かす為の言語であって、
ゴリゴリ一生懸命コードを書いて、パフォーマンスやメンテナンス性を得るための言語ではない。

つまり、今回で言うと、
TS/JSはJSONで全く問題無い場合に使う言語であって、
JSONではパフォーマンスに問題があると分かっているのなら、GoかRustを使うべき。
勿論Javaでもいいが、RustならJavaより速い。

だからこそ逆に、手抜きして何が悪い！ってことになる。
要求仕様が「オブジェクトを復旧できること」なら、
一番簡単なのはJSONで、これを使う人が多いのは当然だ。
一々自前でコードを書きたくなければPODになる。これがいいかどうかはさておき。
(ただまあ俺も、Web系の連中はJavaのstaticおじさんを馬鹿にする割には
書いてるコードがstaticおじさんと同じなのはどうなのよ、とは思ったが)

ちなみに主張されてるようなケースでJavaならイテレータでも渡してI/O側でシリアライズするのか？
単純なイテレータだと階層があったら厳しいから、階層も跨いでいけるイテレータを渡す事になりそうだが、
それでもデータの中身が何か知ってないとシリアライズは厳しくて、
現実的に完全に分離するのは無理だと思うが。

なおメンテナンス性についてはTS/JSは以外に高い。
こういう構造にしたい、というのはあっけないほど簡単に記述出来るから、分離だけは簡単だ。
(ただ、その分離の意味があるのか？が俺には疑問なのだが)

55(1): デフォルトの名無しさん [sage] 2022/02/07(月) 03:30:51.04 ID:yhez4jOW(2/12) AAS
それから、規模については他の人も指摘してるけど、一体何万行の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に駆逐された。(クライアントサイドでは)
それって鉛筆でよくね？ってのを考えた方がいいと思うぜ。

56: デフォルトの名無しさん [sage] 2022/02/07(月) 06:51:13.72 ID:b69Z+ASC(1) AAS
TSの知識が無くTSの開発者文化に馴染めず、理解してない言葉を並べ、決して間違いを認めず、自分のやり方に固執し、目の前にある概念を理解しようともしない。
う〜んこのおっさん。

57(1): デフォルトの名無しさん [sage] 2022/02/07(月) 10:07:24.70 ID:WuDoUI67(1) AAS
>>55
ううむ…せめてレス読んで理解した上で応答してほしいんだが…

小さなシステムでやり方にこだわる必要はないってのは深夜3時までかけて書いた情熱的な作文でいちいち主張しなくても私も最初から認めてることでしょ？
昨日議論したのはそういう手法が通じない規模のシステムの話ね(何度もそう書いてるはずだが)
大きいシステムではうまくいかないよという話をしてるのに
その応答が小さなシステムならうまくいくから問題ないでは話が噛み合うわけがないよね

58(2): デフォルトの名無しさん [sage] 2022/02/07(月) 11:40:42.69 ID:RorkGoUL(1/8) AAS
いやでもわかるわ
json serializable / deserializable で、かつ this 参照可能な method 生えてれば、カプセル化というかコードの凝縮度上げられるのになとは思う
まぁそういう toJSON, fromJSON を実装すれば的な話ではあるが

type Human に getFullName 実装したい時に
POD だと getFullName(h: Human) みたいになって

getFullName(h) じゃなく
h.getFullName() みたいにしたかったのに
みたいな

59(1): デフォルトの名無しさん [sage] 2022/02/07(月) 11:50:23.99 ID:UTO8dkwM(1/11) AAS
凝集度をclassで確保する必要は無いんやで。
書き方についてもパイプライン演算子がstage2入ったしね

60(1): デフォルトの名無しさん [sage] 2022/02/07(月) 11:58:19.03 ID:UTO8dkwM(2/11) AAS
Rustのstructとimplみたく、型とそれに付随する関数を収めたモジュールを作るんや。

61(2): デフォルトの名無しさん [sage] 2022/02/07(月) 12:40:58.10 ID:yhez4jOW(3/12) AAS
>>57
だから何万行書くつもりなんだ？って聞いてるんだよ。

Webの場合は3層なりに強制的に分割されるし、状態管理はDBに丸投げ、View/UIはHTML/CSS/JSに丸投げなので、
鯖でやる事なんて大して無いんだよ。
セキュリティガバガバでよく、（＝社内向けシステムに表示するだけとか)
ORMまでセットアップされてれば、
fizzbuzzの次には掲示板でも作ってみようか、となるくらい単純に出来てる。

だからこそPHPみたいな糞言語が未だに主流なわけでさ。
あれほどの糞言語でも何とかなる程度に収まってんだよ。
ここら辺はやれば分かるんだが、君はやってもないのにJava的な開発を想定しているからおかしな事になってる。
だから1/10想定で、と言ってるわけでさ。

62: デフォルトの名無しさん [sage] 2022/02/07(月) 12:41:25.24 ID:yhez4jOW(4/12) AAS
> 大きいシステムではうまくいかないよという話をしてるのに
これが間違ってる。大きいシステムが存在しない世界なんだよ。
なぜなら、大きくなった部分は切り出され、まだ切り出されてない残り部分しか書かない方式だから。

ユーザーデータの管理が面倒です→DBとして切り出して丸投げ
HTML生成が面倒です→フレームワークに丸投げ
DBを触るのが面倒です→クエリビルダにしますか？ORMにしますか？
セッション管理も面倒です→ではこれもフレームワークで

だからフレームワークは基本的に小粒だし、場合によってはいきなり頓死する。
でもフレームワークまみれで良ければいくらでも手抜き出来る世界だし、それで良しとされてる。
そしてWeb系プログラマは基本的に技術的には非力で、これは「スクリプタをプログラマと呼ぶな」とか言われてたりするが、
だからこそ逆に、自分より上の連中が作ったフレームワークに乗っかる事に抵抗がない。

Javaの連中や、最近の初心者は、手段が目的化してしまってる。
疎結合にする事、綺麗なコードを書く事が目的になってしまってる。それは本来は手段だ。
本来の目的は、「仕様を満たすコードを最速で得る事」だよ。
その際にコードの複雑化が障害になるので疎結合や綺麗なコードが必要になるわけだが、
逆に、ひたすら切り出して絶対に複雑化させない、というアプローチをWeb系は採ってる。
OOPだと大体1,000-3,000行で各モジュールは出来、この単位で切り出して行ってるはずだが、
Web系だと本当に数行で書けるような事すら切り出してたりするし、ここまでやれば大規模化や複雑化は絶対にしない。
逆に依存性は問題になってくるから、みんな動向には敏感だろ。
どっちが良いというものでもないけど、俺はこのWeb系のやり方もありだと思うよ。
すくなくともWeb系の常識からすると、みずほ銀行のポンコツシステムとかあり得ない。
最終的には口座への入出金だけガッツリ管理出来ればいいだけなのに、何でそんなに落ちるんだよ？でしかない。

Javaの流儀でサーバー側を作るのも技術的には可能だけど、それが主流でないって事は、
Javaエンジニアなんて腐るほどいるのだし、「やらなかった」のではなく「上手く行かなかった」と考えた方が妥当だと思うけど。
それでもやるのはどうぞご自由にだが。

63(2): デフォルトの名無しさん [sage] 2022/02/07(月) 12:44:13.86 ID:NQzt3ZES(1/2) AAS
>>60
それが完璧にできればいいんだが、それだと大きなシステムでは統制が行き届かず、処理が分散し凝集度が下がる、というのは過去の実績から明らかなんだよね
そのスタイルでやろうとすると人間がミスをしない、という前提が必要になるんだけど、現実的にそれは難しい
なので大きい案件では「間違えるためには手間がかかる状態」を作り出して人間のミスを抑止するわけ
クラスなら処理の置き場所がはっきりしてるだけでなく、他の場所に書こうとすると別のクラスが必要になるので間違いに気付き易くなる
なので自然と処理が然るべきクラスに集まって、凝集度が高まるって話

何度も何度も言ってるけど
管理コストのスケーリングを考えなくていい、個人や小さなチームで作れる範囲なら、PODと関数でいいんじゃないかな？
その程度ならプログラマが注意深く作業すれば、ミスなく作れるからね

雑談として脱線するけど、ただデータを流すだけ的な小さいサービスは今後はノーコードが主流になると思う
鯖サイドTSのメインターゲットがそういうスモールサービスだとしたら、将来はもしかしたらノーコードとのシェア争いになるのかもね

64(1): デフォルトの名無しさん [sage] 2022/02/07(月) 12:57:08.26 ID:UTO8dkwM(3/11) AAS
>>63
モジュール関数がそうなる状況ではclassもそうなるよ？

65: デフォルトの名無しさん [sage] 2022/02/07(月) 12:59:32.42 ID:yhez4jOW(5/12) AAS
>>58
> getFullName(h) じゃなく
> h.getFullName() みたいにしたかったのに
> みたいな
それはC#で言う拡張メソッドだね。staticメソッドをインスタンスメソッドとして『記述出来る』
Goは逆にメソッドをstaticとして呼べたはずだけど。

この辺は『どう書きたいか』であり、文法の問題であって、（本来は）コード構造の問題ではない。
C#はこの辺の文法とコード構造を分離した。
つまり、メソッドとして書きたいからクラスにします、ではなく、
メソッドとして書きたければメソッドとして書ける文法（拡張メソッド）を用意した。
まあ実際はただのパッチだけどね。何故かは知らんが.NETは無駄にstaticメソッドが多くてウザイのは事実だから。
(ただ今見てみるとC#のはPODでは駄目っぽいが)

Rubyはこの辺、プリミティブなしで全部オブジェクトだから、数字にもメソッドを生やせるし、出来る素地はある。
（やってないと思うけど）
だからJSでやるならボックス化+拡張メソッドで、ということになる。
再度言うがこの辺は文法の話（に出来る話）であって、（本来は）コード構造の話ではないよ。

66(1): デフォルトの名無しさん [sage] 2022/02/07(月) 13:01:33.92 ID:NQzt3ZES(2/2) AAS
>>61
業務システムは何万行の単位じゃ足りない
そこから1桁2桁は増える

君が幸運にも高々数千行の平和なシステムとしか縁がない環境にいるのはよくわかったよ
でも世の中のシステムはそんな恵まれたももばかりじゃないんだ

企業の業務がどれだけ複雑で巨大なのか想像してみたことある？
適当にそれなりの規模の企業をピックアップしてどんな仕事してるか想像して見て？
データベースやIOや画面とか全部取っ払ってドメインロジックだけでいいよ
それを君は3000行ぽっちで実装できるのかい？
もしできるというなら今すぐにそのシステムを売り込みに行った方がいい
あっという間に大金持ちだ

67(1): デフォルトの名無しさん [sage] 2022/02/07(月) 13:05:14.01 ID:RorkGoUL(2/8) AAS
>>59
パイプ何年かかっとんねん
パイプ待ってる内にシステムサ終ですわ

object の後のドットで補完できると絶頂射精できるんや
パイプなんてどうやっても補完できないし無理無理かたつむり

68: デフォルトの名無しさん [sage] 2022/02/07(月) 13:13:31.34 ID:wsXwvKB4(1) AAS
>>64
頻度の話ね

69(1): デフォルトの名無しさん [sage] 2022/02/07(月) 13:18:28.93 ID:UTO8dkwM(4/11) AAS
>>67
そういう事なら仕方ないなw
可変長パイプ関数TSで作るのは確かに辛いけど、とりあえずこんなんで良くね？
外部ﾘﾝｸ:stackoverflow.com

上下前次 1-新書関写板覧索設栞歴

あと 308 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.025s