TypeScript part4

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

60(1): 2022/02/07(月)11:58 ID:UTO8dkwM(2/11) AAS
Rustのstructとimplみたく、型とそれに付随する関数を収めたモジュールを作るんや。

61(2): 2022/02/07(月)12:40 ID:yhez4jOW(3/12) AAS
>>57
だから何万行書くつもりなんだ？って聞いてるんだよ。

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

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

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

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

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

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

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

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

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

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

64(1): 2022/02/07(月)12:57 ID:UTO8dkwM(3/11) AAS
>>63
モジュール関数がそうなる状況ではclassもそうなるよ？

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

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

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

66(1): 2022/02/07(月)13:01 ID:NQzt3ZES(2/2) AAS
>>61
業務システムは何万行の単位じゃ足りない
そこから1桁2桁は増える

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

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

67(1): 2022/02/07(月)13:05 ID:RorkGoUL(2/8) AAS
>>59
パイプ何年かかっとんねん
パイプ待ってる内にシステムサ終ですわ

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

68: 2022/02/07(月)13:13 ID:wsXwvKB4(1) AAS
>>64
頻度の話ね

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

70(1): 2022/02/07(月)13:29 ID:yhez4jOW(6/12) AAS
>>66
> 業務システムは何万行の単位じゃ足りない
それは仕様を絞り込めてない糞だからだよ。

既に言ったとおり、銀行のシステムなんて最終的には「口座への入出金管理」でしかないだろ。
だったらそれをまず作って、これが3,000行。
そしてそれが株からなら、株を管理する鯖を立てて、これも3,000行。
オンラインバンキングが欲しければ、これもUI専用鯖を立てて3,000行。とやっていくのがマイクロサービス流。
モノリシックには作らないから、でかくなりようがない。
この辺は発想の違いで、以下が分かりやすいが、
外部ﾘﾝｸ:note.com
SMBCがマイクロサービス的で、君が見てる世界は三菱UFJのモノリシック型だね。
どっちが良いとかいう単純な話でもないのだけど。

まあいずれにしてもやりたいようにやればいいとは思うよ。
俺はそれは「誰も思いつかなかった」のではなく、「既に失敗してるから今は誰もやってない」だけだと思うけど。
文化の形成過程って、これだと思うし。
文化を否定する前に、まず何故そんな文化になってるのかを考えるべきだよ。
それは何だかんだで現時点での最適化がかかった状態ではあるのだから。

>>63
フレームワークをこねくり回すだけで出来るものはノーコードが主流になるとは思う。
ただしそれでWeb系言語が廃れる事はない。フレームワークになってない部分は自前で書くしかないので。
なお主にマイクロサービスを目指しているのはGoだね。みんなRustに行っちゃった感はあるけど。
TSは…JSだと型が無くて糞だと思ってる連中が使ってるはずだけど、何指向かは知らん。
（というか俺はTS使ってないし)

71: 2022/02/07(月)13:33 ID:Afq51Jp9(1) AAS
業務システムにオープン系入ってきてもう何十年よ
プロジェクト規模ならわかるがシステム規模で何十万行とか
ミドルウェアも活用できてない失敗プロジェクト
DSLで品質も保ててスッキリ記述できる部分も汎用言語で書いてそう

72(1): 2022/02/07(月)13:36 ID:Ipfs3xdV(1) AAS
>>70
ははは
ならその素晴らしい数千行の銀行システムを売り込んできたら？

73(1): 2022/02/07(月)13:40 ID:UTO8dkwM(5/11) AAS
途中までの思想はわかるけど、数千行銀行はちょっと無理だと思うよ……

74: 2022/02/07(月)13:46 ID:UTO8dkwM(6/11) AAS
とはいえ分割単位次第か

75(2): 2022/02/07(月)13:58 ID:yhez4jOW(7/12) AAS
>>72
今は俺はJavaを殺すのはWeb系だと思ってるよ。
何処かが「もうこれWeb系でよくね？」として試しにやってみて成功したら、一気に流れると思う。
開発/運用コストが1/10〜1/100だろうから、
金銭面しか評価出来ない文系馬鹿が仕切ってる日本の銀行とかは一気に導入だよ。
マジな話、みずほ銀行が作り直すのならマイクロサービスでやれば面白いとは思ってる。
まあ現実的には病院や自治体から導入で、銀行は最後尾だろうけどね。

>>73
それは発想の方向の違い。
単発サービスで3,000行程度に留まるところまでサービスを分割する。
できるできないではなく、3,000行程度になるまでひたすら分割するだけ。

実際、DBに対して単に読み書きするだけなら、200行程度で書けるでしょ。
だから最悪、1,000行程度までのマイクロサービスに分割しろ、と言われても普通に出来てしまうんだよ。

76: 2022/02/07(月)14:09 ID:UTO8dkwM(7/11) AAS
>>75
そういう意味なら納得です

77(1): 2022/02/07(月)14:10 ID:4z8oj16v(1) AAS
素晴らしい！
ひとりの天才の出現によって金融系システム従事者が超難度システムのメンテから解放されるんだね
私はもしかすると時代の転換点を最も近いところから目撃してしまったのかもしれない

78(1): 2022/02/07(月)14:19 ID:RorkGoUL(3/8) AAS
>>69
lodash compose かな
まぁあれはあれで前立腺イキな気持ちよさはある

79: 2022/02/07(月)14:20 ID:RorkGoUL(4/8) AAS
>>77
みずほ社員２０万人「ﾀｽｹﾃ・・・ﾀｽｹﾃ・・・」

80(1): 2022/02/07(月)14:27 ID:mmIvHtEJ(1) AAS
ちゅーかなんでみんながみんなクソデカカチカチシステム作る前提なわけ？
適材適所って言葉を知らんのか

81: 2022/02/07(月)14:43 ID:UTO8dkwM(8/11) AAS
>>78
lodash有りならlodash/fpにそのままズバリpipeもあるし、部分適用もお手の物やん

82(1): 2022/02/07(月)14:51 ID:RorkGoUL(5/8) AAS
>>80
だって小さいシステムなら誰でも作れるじゃん
それこそPHPやPerlでも構わな・・・くはない死にたくなるけど、まぁやってやれんことはない
っぱエンジニアは20万人月回してこそ1人前でしょ

83(1): 2022/02/07(月)14:55 ID:R1s+yfGI(1) AAS
それにしてもマイクロサービス万能論者って久々に見た気がするわ
サービスを分割すればするほどサービス間の連動の管理が難しくなってそれはそれでうまくいかないぞ
というんでモジュラーモノリスだとか色々回帰論が出てきて今となっては「やっぱり銀の弾丸はなかったね」が常識で通じる時代になったと思ったんだが…

仮に30万行のシステムがあったとしてそれを3000行に分割したら単純計算で100個に分割できるわけだ
100種類のサービスを間違いなく連動させるのがどれだけ大変なことなのか
ちょっと甘く見過ぎてる感じがするね？

84: 2022/02/07(月)15:01 ID:dHoIQX/o(1) AAS
>>61
>Webの場合は3層なりに強制的に分割されるし、状態管理はDBに丸投げ、View/UIはHTML/CSS/JSに丸投げなので、
>鯖でやる事なんて大して無いんだよ。

どんだけ無知なんだよww
流石にこのレベルで偉そうに語られると相手するのが恥ずかしくなる

85: 2022/02/07(月)15:02 ID:HmGAn9CY(1) AAS
>>82
TS開発者全てを20万人月扱うスーパーマンにするなw

86: 2022/02/07(月)15:13 ID:27SiZacg(1) AAS
>>75
相手がボロ出すまで同じ事繰り返すだけの自演おじさんなんて相手しなくて良いよ。おじさんの話の内容見てても読解力もTS理解度も足りてないんだし

87(1): 2022/02/07(月)15:26 ID:S/gDVAW3(1/2) AAS
DDD的な話はわりとまともなこと言ってるけど
コード例を出さないからTS固有の問題なのか使い方や作り方の問題なのか判別つかないね

88: 2022/02/07(月)15:33 ID:S/gDVAW3(2/2) AAS
銀行みたいに堅牢性や永続性が最重要のシステムをTSで作るわけないけど
変化に対する柔軟性に重きを置くシステムならサーバー側でもTSは有力な選択肢だと思う

UnionやIntersectionのおかげでFunctionalなDDDがやりやすいってのが一番の理由
JavaみたいにOOPベースのDDDやるならTSを選ぶメリット感じない

89: 2022/02/07(月)16:02 ID:UTO8dkwM(9/11) AAS
>>87
それだよねぇ。長い文章書くわりに具体的な内容無いもの

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

あと 307 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.016s