TypeScript part4 (376レス)
1-

67
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 13:05:14.01 ID:RorkGoUL(2/8) AAS
>>59
59(1): デフォルトの名無しさん [sage] 2022/02/07(月) 11:50:23.99 ID:UTO8dkwM(1/11) AAS
凝集度をclassで確保する必要は無いんやで。
書き方についてもパイプライン演算子がstage2入ったしね
パイプ何年かかっとんねん
パイプ待ってる内にシステムサ終ですわ

object の後のドットで補完できると絶頂射精できるんや
パイプなんてどうやっても補完できないし無理無理かたつむり
68: デフォルトの名無しさん [sage] 2022/02/07(月) 13:13:31.34 ID:wsXwvKB4(1) AAS
>>64
64(1): デフォルトの名無しさん [sage] 2022/02/07(月) 12:57:08.26 ID:UTO8dkwM(3/11) AAS
>>63
モジュール関数がそうなる状況ではclassもそうなるよ?
頻度の話ね
69
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 13:18:28.93 ID:UTO8dkwM(4/11) AAS
>>67
そういう事なら仕方ないなw
可変長パイプ関数TSで作るのは確かに辛いけど、とりあえずこんなんで良くね?
外部リンク:stackoverflow.com
70
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 13:29:41.52 ID:yhez4jOW(6/12) AAS
>>66
66(1): デフォルトの名無しさん [sage] 2022/02/07(月) 13:01:33.92 ID:NQzt3ZES(2/2) AAS
>>61
業務システムは何万行の単位じゃ足りない
そこから1桁2桁は増える

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

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

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

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

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

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

雑談として脱線するけど、ただデータを流すだけ的な小さいサービスは今後はノーコードが主流になると思う
鯖サイドTSのメインターゲットがそういうスモールサービスだとしたら、将来はもしかしたらノーコードとのシェア争いになるのかもね
フレームワークをこねくり回すだけで出来るものはノーコードが主流になるとは思う。
ただしそれでWeb系言語が廃れる事はない。フレームワークになってない部分は自前で書くしかないので。
なお主にマイクロサービスを目指しているのはGoだね。みんなRustに行っちゃった感はあるけど。
TSは…JSだと型が無くて糞だと思ってる連中が使ってるはずだけど、何指向かは知らん。
(というか俺はTS使ってないし)
71: デフォルトの名無しさん [sage] 2022/02/07(月) 13:33:18.79 ID:Afq51Jp9(1) AAS
業務システムにオープン系入ってきてもう何十年よ
プロジェクト規模ならわかるがシステム規模で何十万行とか
ミドルウェアも活用できてない失敗プロジェクト
DSLで品質も保ててスッキリ記述できる部分も汎用言語で書いてそう
72
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 13:36:19.77 ID:Ipfs3xdV(1) AAS
>>70
ははは
ならその素晴らしい数千行の銀行システムを売り込んできたら?
73
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 13:40:37.88 ID:UTO8dkwM(5/11) AAS
途中までの思想はわかるけど、数千行銀行はちょっと無理だと思うよ……
74: デフォルトの名無しさん [sage] 2022/02/07(月) 13:46:02.77 ID:UTO8dkwM(6/11) AAS
とはいえ分割単位次第か
75
(2): デフォルトの名無しさん [sage] 2022/02/07(月) 13:58:43.68 ID:yhez4jOW(7/12) AAS
>>72
今は俺はJavaを殺すのはWeb系だと思ってるよ。
何処かが「もうこれWeb系でよくね?」として試しにやってみて成功したら、一気に流れると思う。
開発/運用コストが1/10〜1/100だろうから、
金銭面しか評価出来ない文系馬鹿が仕切ってる日本の銀行とかは一気に導入だよ。
マジな話、みずほ銀行が作り直すのならマイクロサービスでやれば面白いとは思ってる。
まあ現実的には病院や自治体から導入で、銀行は最後尾だろうけどね。

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

実際、DBに対して単に読み書きするだけなら、200行程度で書けるでしょ。
だから最悪、1,000行程度までのマイクロサービスに分割しろ、と言われても普通に出来てしまうんだよ。
76: デフォルトの名無しさん [sage] 2022/02/07(月) 14:09:33.83 ID:UTO8dkwM(7/11) AAS
>>75
そういう意味なら納得です
77
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 14:10:07.39 ID:4z8oj16v(1) AAS
素晴らしい!
ひとりの天才の出現によって金融系システム従事者が超難度システムのメンテから解放されるんだね
私はもしかすると時代の転換点を最も近いところから目撃してしまったのかもしれない
78
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 14:19:47.08 ID:RorkGoUL(3/8) AAS
>>69
lodash compose かな
まぁあれはあれで前立腺イキな気持ちよさはある
79: デフォルトの名無しさん [sage] 2022/02/07(月) 14:20:45.58 ID:RorkGoUL(4/8) AAS
>>77
みずほ社員20万人「タスケテ・・・タスケテ・・・」
80
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 14:27:40.67 ID:mmIvHtEJ(1) AAS
ちゅーかなんでみんながみんなクソデカカチカチシステム作る前提なわけ?
適材適所って言葉を知らんのか
81: デフォルトの名無しさん [sage] 2022/02/07(月) 14:43:03.87 ID:UTO8dkwM(8/11) AAS
>>78
lodash有りならlodash/fpにそのままズバリpipeもあるし、部分適用もお手の物やん
82
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 14:51:15.15 ID:RorkGoUL(5/8) AAS
>>80
だって小さいシステムなら誰でも作れるじゃん
それこそPHPやPerlでも構わな・・・くはない死にたくなるけど、まぁやってやれんことはない
っぱエンジニアは20万人月回してこそ1人前でしょ
83
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 14:55:26.17 ID:R1s+yfGI(1) AAS
それにしてもマイクロサービス万能論者って久々に見た気がするわ
サービスを分割すればするほどサービス間の連動の管理が難しくなってそれはそれでうまくいかないぞ
というんでモジュラーモノリスだとか色々回帰論が出てきて今となっては「やっぱり銀の弾丸はなかったね」が常識で通じる時代になったと思ったんだが…

仮に30万行のシステムがあったとしてそれを3000行に分割したら単純計算で100個に分割できるわけだ
100種類のサービスを間違いなく連動させるのがどれだけ大変なことなのか
ちょっと甘く見過ぎてる感じがするね?
84: デフォルトの名無しさん [sage] 2022/02/07(月) 15:01:35.38 ID:dHoIQX/o(1) AAS
>>61
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想定で、と言ってるわけでさ。
>Webの場合は3層なりに強制的に分割されるし、状態管理はDBに丸投げ、View/UIはHTML/CSS/JSに丸投げなので、
>鯖でやる事なんて大して無いんだよ。

どんだけ無知なんだよww
流石にこのレベルで偉そうに語られると相手するのが恥ずかしくなる
85: デフォルトの名無しさん [sage] 2022/02/07(月) 15:02:48.84 ID:HmGAn9CY(1) AAS
>>82
TS開発者全てを20万人月扱うスーパーマンにするなw
86: デフォルトの名無しさん [sage] 2022/02/07(月) 15:13:48.61 ID:27SiZacg(1) AAS
>>75
相手がボロ出すまで同じ事繰り返すだけの自演おじさんなんて相手しなくて良いよ。おじさんの話の内容見てても読解力もTS理解度も足りてないんだし
87
(1): デフォルトの名無しさん [sage] 2022/02/07(月) 15:26:53.69 ID:S/gDVAW3(1/2) AAS
DDD的な話はわりとまともなこと言ってるけど
コード例を出さないからTS固有の問題なのか使い方や作り方の問題なのか判別つかないね
88: デフォルトの名無しさん [sage] 2022/02/07(月) 15:33:02.79 ID:S/gDVAW3(2/2) AAS
銀行みたいに堅牢性や永続性が最重要のシステムをTSで作るわけないけど
変化に対する柔軟性に重きを置くシステムならサーバー側でもTSは有力な選択肢だと思う

UnionやIntersectionのおかげでFunctionalなDDDがやりやすいってのが一番の理由
JavaみたいにOOPベースのDDDやるならTSを選ぶメリット感じない
89: デフォルトの名無しさん [sage] 2022/02/07(月) 16:02:48.76 ID:UTO8dkwM(9/11) AAS
>>87
それだよねぇ。長い文章書くわりに具体的な内容無いもの
90: デフォルトの名無しさん [sage] 2022/02/07(月) 16:15:52.59 ID:yhez4jOW(8/12) AAS
>>83
> 30万行のシステム
これがそもそも間違いなんだよ。
銀行なんて最終的には通帳に記入する内容、つまりは「日時と金額と取引相手」だけ管理出来てればいいんだぞ。
最初から綺麗に作れば、何をどうやっても30万行なんてならんよ。

無駄に膨らんでる理由は、過去のコードを除去出来ない点にある。
だけどそれは新規に書く部分には関係ない。
だから現実的には携帯みたいに2G->3
3(1): デフォルトの名無しさん [sage] 2021/12/31(金) 00:30:19.49 ID:/NplslaL(1) AAS
>>1
G->4
4(1): デフォルトの名無しさん [sage] 2021/12/31(金) 10:54:08.06 ID:jCXckXJt(1) AAS
4.6でmjs対応は入るのかな?
G->5
5(1): デフォルトの名無しさん [sage] 2022/01/16(日) 23:06:00.91 ID:CViIeqBQ(1) AAS
Unionを受け取る関数の返り値の型を引数の型によって変えたいときってどう書けばいいの?

type F<T> = (() => void) | ((x: T) => void);

const wrap = <T>(f: F<T>) => ??? ;

const a: () => void = wrap( () => {} );
const b: (x: string) => void = wrap( (x: string) => {} );
Gと徐々に載せ替え、過去の口座も徐々に新鯖に載せ替えて、
古いコードは丸ごと捨てていけば良かっただけの話。
「メンテする」というのがかなり難しいから、「新規に書いて古いのは捨てる」の発想。
実際Web系はこれに近いでしょ。
実は本来はOOPもこれ(モジュール単位で入れ替えてアップグレードしていく)だったのだが、
何故かひたすらメンテする思想になってしまってるが。

一応言っておくが俺が言ってる行数は、71の言ってる「システム規模」、つまり自前で書くコード規模な。
3rdパーティのライブラリやフレームワーク等、他人が書いてて既に動くことが確定しているコードは含まない。
まあこれを誤解しているレスは今のところ無いと見ているが。
91: デフォルトの名無しさん [sage] 2022/02/07(月) 16:16:36.07 ID:yhez4jOW(9/12) AAS
あと俺は別にマイクロサービスが良いと思っているわけではない。
俺が言ってるのは、(という程は言ってないが)
「コードを書いて捨てる前提なら、メンテナンス性も可読性も必要ない」って事だ。
ここが逆転の発想なんだよ。
元々これらが必要だったのは、
初心者あるあるの「半年前に自分が書いたコードが読めない」「規模が大きすぎてコードを追えない」を回避するためだ。
後者については大体10,000行程度が限界だと昔から言われてるから、単純には、

・半年で開発を終了出来ない規模以上の開発は、可読性が高いコードでないと無理。
・10,000行を越える規模の開発は、一人では無理。よって他人にも読めるコードを書け。
・作り直すにしてもどうせ同じようなコードを書く事になるから、メンテした方が生産性が高い。

というわけでこれが大正義とされていたわけだが、実際は、

・そもそも可読性の高さなんて初心者には分からない。
・メンテ性を上げるために間接参照挟みまくってるコードは、余計に分かりにくくなる。
・Web系はそもそもそんなに大規模にならない。(DBとJSに切り出した時点でほぼスカスカ)
・Web系は仕様自体がガンガン追加されるので、古いコードをありがたがってメンテする意味がない。
 (新しい仕様を使った機能は新しく書くしかない)

なので、「依存しない」ではなく「依存先を適切に選んで単純なコードを書き、ハズレだったら捨てる」と割り切ってるのがWeb系。
具体的にはJSONもそうだろ。toJSONはJSON形式に依存する大前提で、JSON形式が捨てられれば立ちゆかなくなるコードだ。
しかし、JSONが使える限りは至極単純なコード、JSON.stringifyとJSON.parseで終われる。
そこを完全コンストラクタを呼び出すコードを全クラス分I/O層に置け、というのは、理屈は分かるが、無駄手間でしかない。
それがJavaにおいては正義だ、というのもまた事実なのだろうけど。
でも実際それがJava界隈の糞な所でもあるよね。
関数ポインタが使えないという言語の問題を継承をこねくり回したデザインパターンで誤魔化して糞コードにしてて、
しかもそれを自覚出来てないところとかもね。
1-
あと 285 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.014s