TypeScript part4

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

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
それだよねぇ。長い文章書くわりに具体的な内容無いもの

90: 2022/02/07(月)16:15 ID:yhez4jOW(8/12) AAS
>>83
> 30万行のシステム
これがそもそも間違いなんだよ。
銀行なんて最終的には通帳に記入する内容、つまりは「日時と金額と取引相手」だけ管理出来てればいいんだぞ。
最初から綺麗に作れば、何をどうやっても30万行なんてならんよ。

無駄に膨らんでる理由は、過去のコードを除去出来ない点にある。
だけどそれは新規に書く部分には関係ない。
だから現実的には携帯みたいに2G->3G->4G->5Gと徐々に載せ替え、過去の口座も徐々に新鯖に載せ替えて、
古いコードは丸ごと捨てていけば良かっただけの話。
「メンテする」というのがかなり難しいから、「新規に書いて古いのは捨てる」の発想。
実際Web系はこれに近いでしょ。
実は本来はOOPもこれ（モジュール単位で入れ替えてアップグレードしていく）だったのだが、
何故かひたすらメンテする思想になってしまってるが。

一応言っておくが俺が言ってる行数は、71の言ってる「システム規模」、つまり自前で書くコード規模な。
3rdパーティのライブラリやフレームワーク等、他人が書いてて既に動くことが確定しているコードは含まない。
まあこれを誤解しているレスは今のところ無いと見ているが。

91: 2022/02/07(月)16:16 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界隈の糞な所でもあるよね。
関数ポインタが使えないという言語の問題を継承をこねくり回したデザインパターンで誤魔化して糞コードにしてて、
しかもそれを自覚出来てないところとかもね。

92: 2022/02/07(月)16:17 ID:yhez4jOW(10/12) AAS
だから他人から言われた大正義を信じるのではなくて、それは何の為なのか、
どこまで依存していいのか、何に依存してはいけないのか、
コードはどの程度メンテする予定で、可読性はどれくらい必要なのか、
ちゃんと自分で考えて丁度良い点を目指さないと駄目なんだよ。
Javaにおいては20年後に他人がコードを読む前提だから、間違ってもこんな事は言われないはずだけど、
Web系においては、20年後も動いているコードなんて存在しない前提でも全く問題ないんだよ。
だからJavaの常識はJavaの世界向けにチューニング済みであって、それをWeb系に持ち込んでも失敗するだけだよ。
まあそれでもやるのは自由だけど。

93(1): 2022/02/07(月)17:00 ID:RorkGoUL(6/8) AAS
> 最初から綺麗に作れば、何をどうやっても30万行なんてならんよ。

ガラパゴス日本村のおらが法のスパゲッティをシステム化するんだからしゃーない
30万のif文がおんどれらを襲う

この国の映し鏡である金融システムをリファクタするには、まず老い腐った政治家どもを晒し首にして
もう一度ﾄｷｮを焼け野原にするところからやり直さなきゃいけないんだよ

94(1): 2022/02/07(月)17:13 ID:UTO8dkwM(10/11) AAS
>>93
おまいさん以前Linux板あたりに居なかったか？

95(1): 2022/02/07(月)18:19 ID:RorkGoUL(7/8) AAS
>>94
いたよ。あそこは楽しかったね。

96: 2022/02/07(月)18:34 ID:UTO8dkwM(11/11) AAS
>>95
だな。相変わらずで何よりだ

97(1): 2022/02/07(月)21:20 ID:yhez4jOW(11/12) AAS
>>58
そういえば
> fromJSON
ではなくて、reviver関数な。
外部ﾘﾝｸ:developer.mozilla.org

> getFullName(h) じゃなく
> h.getFullName() みたいにしたかったのに
> みたいな
あと、出来る/出来ないで言えば、これは出来るよ。勿論禁じ手だが

Object.prototype.getFullName = function(){return this.firstName+this.familyName;};
var h = {firstName:'Java', familyName:'Script'};
h.getFullName(); // "JavaScript"

とか。問題は、JSはこれを行うように設計されてるのに、事実上使えない点で、
プロトタイプ拡張がもうちょっとローカルに出来る仕組みが導入されたら言語としては面白くなるとは思うよ。
(俺は知らないけど、)prototype.js時代は楽しかっただろうとも想像出来る。
それぞれのclassをちゃんと整備する方が正道ではあるのだけどね。

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

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

ぬこの手ぬこTOP 0.008s