プログラマの雑談部屋 ★274

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2023/04/17(月) 19:11:47.99
雑談スレ

前スレ
プログラマの雑談部屋 ★273
https://medaka.5ch.net/test/read.cgi/prog/1681225229/
2023/04/22(土) 10:56:19.26
ていうかユーザー一覧画面を処理ごとに作ってるのかよ
うわぁ。。。
2023/04/22(土) 10:56:59.17
ね
なんで業務用システムを
毎回毎回１から作ってるのか
2023/04/22(土) 10:57:13.70
>>764
そうだよ
何だと思ったんだ？
継承必須とか思った？
2023/04/22(土) 10:58:37.30
>>762
その列挙メソッドを持つクラスってのは、少なくとも3つのテーブルから情報を取得して情報をフィルタして結果を返すラッパークラスだろ
しかも、よっぽどうまく設計しないと、この処理でしか使えないという
そして、本人は上手く設計したつもりでも、他のチームメンバーからは誰からも利用されることのないボッチクラスになる可能性が高い

この程度の処理は、インターフェースとかクラスとか使って無駄に複雑に書かれるより、手続き型で素直に書かれてた方がメンテもしやすかったりするんだよなぁ
2023/04/22(土) 11:00:30.92
>>769
ラッパークラスじゃなくフィルタリングメソッドな
ほんと基礎からわかんねーんだな
ここまで話にならんやつは新人でもなかなかおらんわ
771仕様書無しさん
垢版 |
2023/04/22(土) 11:01:09.11
>>768
そんなの日本だけだよ、普通はパッケージを使うよ
日本は独自でやりたがるんだよ、日本は終身雇用だからね
2023/04/22(土) 11:01:15.17
クラスのインヘリタンスがどうのこうのなんだよ
2023/04/22(土) 11:01:54.69
>>771
えっと、お前プログラミングできないだろ
2023/04/22(土) 11:03:19.88
パッケージ（bootstrap）
2023/04/22(土) 11:03:35.89
>>752
ユーザーリポジトリクラス
ポイント数でユーザー検索する仕様を表現するクラス
半年利用がないでユーザー検索する仕様を表現するクラス
年齢が60〜◯×市って条件を判定するポリシークラス
買い物実績でユーザー検索する仕様を表現するくらす
SMSを送信するクラス
Aマーケットでポイント利用促進の案内メッセージを作るクラス
2023/04/22(土) 11:04:47.62
>>769
データベースとのやり取りをするクラスが使われないわけあるか
逆にそれをチーム毎に独自に作るとかどんだけ底辺の話をしてるんだ
777仕様書無しさん
垢版 |
2023/04/22(土) 11:04:51.25
えーあー工場があって車があってタイヤがあるのがオブジェクト至高
2023/04/22(土) 11:05:29.35
なんかいいソフト思いつきませんか
犬の餌みたいに与えられる業務案件はもういやだ
2023/04/22(土) 11:05:33.04
>>758
世の中にはUIからのアクションごとに実質一つの関数でまかなう書き方する会社がごまんとあるんやで
ユーザdtoやポイントdtoにvo的な60歳以上や1000ポイント以上みたいな判定プロパティは持たせても、メインの処理は一本手続きや
2023/04/22(土) 11:05:33.24
>>775
それはさすがに分けすぎ
設計のセンスのないやつって実在するんだ
2023/04/22(土) 11:06:12.86
>>779
dtoがオブジェクトなことから説明が必要な感じ？
2023/04/22(土) 11:06:51.77
>>780
君はDDD再履修ね
2023/04/22(土) 11:07:45.02
>>782
お前はまず入門しろ
言ってることが素人以前だ
2023/04/22(土) 11:08:00.46
Dtoは構造体だよ
2023/04/22(土) 11:08:42.14
>>761
？
2023/04/22(土) 11:08:44.55
>>775
列挙するだけなら3つのテーブルJOINして検索するSQLを発行するリポジトリクラス１つで済むけどな
2023/04/22(土) 11:08:49.85
>>779
アクションはUIからデータを取り出して最小限の入力チェックを行い、サービスを呼び出し、サービスの戻り値をUIに書き戻すだけ、だって教わらないのかね？世の中の平均的プログラマってさ
2023/04/22(土) 11:09:08.39
>>784
構造体はオブジェクトの実装でしかないぞ
2023/04/22(土) 11:09:57.99
プログラミング言語なんて1,2つでよくて契約とるところから一人でできることのが大事
2023/04/22(土) 11:10:46.19
>>781
dddじゃなくてトランザクションスクリプトあるいは貧血ドメインモデルやでって言いたかった
トランザクションスクリプトもoopだろって言われればまあそう
2023/04/22(土) 11:11:03.63
ファンクションキー毎に２００行くらいあって
内容がほとんど同じで、キーによって微妙に違う所がある
そんなコピペ方式の実装を見たことがある
2023/04/22(土) 11:11:04.09
何万件ものデータ扱うならDBとか意味あるけど
たかだかすうひゃ
2023/04/22(土) 11:14:43.95
>>758
一度も仕事したことない奴の感想文すぎて草
ビジネスロジックが抜け落ちてる
2023/04/22(土) 11:15:07.24
>>787
そりゃ世間はコントローラアクションからドメインクラスを呼び出すのが作法になってるからだが、はっきり言ってトランザクションスクリプトしてるとボイラーテンプレートだしな。
まあ実際にはサービスクラスpublicメソッド呼び出しにaopしてるからコントローラはその呼び出しになってるけど
2023/04/22(土) 11:15:40.79
>>793
「少なくとも」という日本語から説明が必要な感じ？
2023/04/22(土) 11:16:08.57
>>783
俺のはDDDに忠実な、スタンダードな設計
DDDをよく理解せずに、リポジトリとかサービスって、言っとけばいいんだろ？
みたいな、浅い理解の仕方だと、仕様とか、ポリシーといった概念が抜け落ちて、しまうんだ
すると、リポジトリにやたら複雑な検索を実行するメソッドとか、同じ条件判定が、あちこちにコピーされる、といった、なんとも残念な、エセDDDになってしまう
797仕様書無しさん
垢版 |
2023/04/22(土) 11:16:44.04
ユーザクラスを生成してポイントと
履歴をテーブルから取得でええんじゃね？
よくあるパターンだとserviceで判定してactionにSMS通知フラグを
返しやるみたいな
2023/04/22(土) 11:17:24.40
>>796
さすがに条件の一つ一つをオブジェクトにするのはアホだわって話が通じないところを見ると真正だな？
2023/04/22(土) 11:17:55.46
>>796
正直うちは基幹システムメインだから仕様変更多くなくてdddにする意義が見いだせなくてなー...
800仕様書無しさん
垢版 |
2023/04/22(土) 11:18:44.21
みんな家に引きこもってないで出かけなさーい
2023/04/22(土) 11:19:00.28
>>796
SQLである程度絞らないとメモリに大量に読み込んでロジックで抽出する富豪的な書き方になるだろ
まぁ今はそれでも許される時代になったのか
2023/04/22(土) 11:20:17.82
>>786
ううむ、バッドプラクティス
そのまま進むと、リポジトリの責務が際限なく膨らみ、様々なビジネスロジックの置き場と化す
悪いことはいわん、お若いの
リポジトリはシンプルに保つのじゃ

なお、CQRSで割り切って、短いキャンペーンの間なら、表示までは、テキトーなSQLでええやろ、ならおk
ずっと残すものは、綺麗に作れ。これ大事
2023/04/22(土) 11:20:18.50
>>798
一回のキャンペーンの条件に過ぎないものを全部オブジェクトとしてハードコーディングするのはさすがにアホだよね
2023/04/22(土) 11:20:32.69
>>798
彼が言いたいのは仕様をDRYしろって大原則が抜け落ちるとdddのメリットの9割が消えるってのが主張したいことだろ
結果的に条件が横断的な仕様なら個別に別れてなきゃいかん
2023/04/22(土) 11:21:12.69
>>804
60歳をハードコーディングすることのどこがDRYだw
2023/04/22(土) 11:23:23.63
マイクロサービスはそうするよ
という肯定意見がないのでこのスレはその程度なのだろう
2023/04/22(土) 11:23:25.89
何万件ものデータ扱うならDBとか意味あるけど
たかだか数百件扱うのに導入する意味が分からないよ
2023/04/22(土) 11:24:25.32
>>798
一つ一つとか関係ない
それが業務で定義されてるのなら、どんなに小さくても、作るのだ
システムは、気持ち、で開発するのではない
業務、ドメインを再現するのじゃ
それがDDDなのじゃよ
2023/04/22(土) 11:24:32.70
条件をオブジェクトにするやつって複数のキャンペーンにどう対応するんだろう
全部クラス化するのか？
2023/04/22(土) 11:24:50.59
数百件って条件は何処から出て来たんだよ
2023/04/22(土) 11:25:01.87
>>808
とりあえず入門しろ
お前の想像とは全然違うものだから
2023/04/22(土) 11:26:52.69
>>810
要件定義からの仕様書からの詳細設計書だが？
2023/04/22(土) 11:27:49.76
>>799
変更が多い時に最も大切なことはテストだろう
テストしやすいようにDDDしよう
2023/04/22(土) 11:28:18.69
>>809
クラス化しても、後でそれでカバーできない条件ってのが絶対出てくるから、クラスの書き直し、それに依存してるコードの修正、そしてテストも失敗するから、大量のテストの修正ってパターンだな
815仕様書無しさん
垢版 |
2023/04/22(土) 11:28:56.78
DBにする理由は永続化でデータ件数とかより
こっちかなと
テキストとかCSVで保存すると排他制御とか
行単位では出来ないし、何がどれやら作った人にしか解らなくなる
2023/04/22(土) 11:28:59.08
検索条件の一つ一つをクラス化しなきゃいけないと思ってるやつは電卓を作るときはボタンの一つ一つを全部クラス化しなきゃいけないとか思ってそうだな
Value Objectを知らんのだな
2023/04/22(土) 11:29:54.78
>>814
そろそろ自分でもイタいこと言ってることに気づかないか？
2023/04/22(土) 11:30:15.37
まあ、皆自分の経験で仕事の規模も類推してしまいがちで
そのため過度に大げさになったり、小さくまとまり過ぎる事もあるだろう
2023/04/22(土) 11:31:48.06
>>815
それ、DBでも同じじゃね？
で、ドキュメント化されてれば良くね？
2023/04/22(土) 11:33:59.36
結局、SQLで書きにくい条件は、一旦メモリに読み込んでコードでゴリゴリフィルターかけて抽出するって感じ？
で、ゴリゴリフィルター部分をオレオレクラスで華麗に設計すればいいのか
821仕様書無しさん
垢版 |
2023/04/22(土) 11:35:50.21
10kmラン54m44s
用もないのに有明まで走ってきた
2023/04/22(土) 11:36:13.04
>>820
速度と転送量に問題が出ない程度に絞って読み込んじゃってるかな？
でも対象が絞れないほどデカイときは注意
2023/04/22(土) 11:36:55.05
>>801
もしかして、仕様クラスを理解してない
エンティティが満たすべき、条件を抽象化するためのクラスだよ
だから仕様っていうの
リポジトリは、渡された仕様を満たすエンティティを、検索するだけ、だから業務の事を知らなくていいので、スッキリ
仕様を満たす、エンティティだけが、メモリに読み込まれるので、メモリ効率も抜群
2023/04/22(土) 11:37:17.26
利用促進の案内クラスを作っておいて
条件や内容は可変にしておけば、後々楽だろう
825仕様書無しさん
垢版 |
2023/04/22(土) 11:38:05.74
>>819
うーん
作った人にしか解らないってトコ？

テキストは行にコメント付けられない
( ｰ`дｰ´)ｷﾘｯ
2023/04/22(土) 11:38:53.56
前向きに明るくポジティブに
みたいな愚痴も言えない空気押し付けられるのどう思う？
2023/04/22(土) 11:39:54.03
>>805
この場合は、キャンペーン対象の条件を仕様として定義する、のだから60がハードコードされていても、おk
2023/04/22(土) 11:41:58.18
SQLでも普通は一気にメモリに読み込むんじゃなくて、1件ずつ読みながら処理だからそれがネックになる事はないわな
SQL自体にしてもSQLビルダーで複雑な条件を動的に生成出来るし
2023/04/22(土) 11:43:50.55
年齢指定なんかは、運用時に自由にできたほうが便利だと思いますが
いかがですか
830仕様書無しさん
垢版 |
2023/04/22(土) 11:44:39.36
SQLはまとめてデータ取れてる気がすんだけど
それって実際は1件ずつFetchした結果を見てるから
そう感じるってだけなんかな？
2023/04/22(土) 11:46:27.14
>>809
キャンペーンごとに作る
var spec1 = new キャンペーンX対象者仕様();
var spec2 = new キャンペーンY対象者仕様();
var spec3 = new キャンペーンZ対象者仕様();

users.find(spec1);
users.find(spec2);
users.find(spec3);

繰り返しキャンペーンで、毎回微妙に変えたいならパラメータ化してもいい
var spec4 = new 定期キャンペーンW対象者仕様(age: 60, addressNearBy: "◯×");

users.find(spec4);


エレガント、、、
実にエェエエエエエレガントッ！
2023/04/22(土) 11:47:22.14
>>816
全く関係ないこと言ってて草
2023/04/22(土) 11:48:06.07
>>811
ぶっちゃけ入門が元々のdddかって言われるとかなり首を傾げたくはなるんだどね
まあ、現実解としてはこうなるよなって実装になっててより実務的なんだけど
2023/04/22(土) 11:48:29.23
性別の指定がありませんが、これは担当者様の見落としですか？
835仕様書無しさん
垢版 |
2023/04/22(土) 11:49:04.83
>>834
ジェンダーフリーの時代だからじゃぁぁ
2023/04/22(土) 11:50:32.86
なんというか、世間的にもdddしなくてもvoガッツリ育てりゃどうでも良くねってなってきてるフシあって、少なくとも2000年代に主張されてたdddとは違うプラクティスになってるよな
2023/04/22(土) 11:50:36.74
>>830
それは書き方次第
一気にも取れるし、カーソルで一件ずつも処理できる
C#だと、Listに読み込むか、IQueryableで遅延評価するみたいな感じか
レコードを全部オブジェクトに変換してから抽出しようとするとメモリ使う
838仕様書無しさん
垢版 |
2023/04/22(土) 11:50:40.40
節句寿司太陽
2023/04/22(土) 11:52:38.16
>>829
時と場合
仕様クラスのコンストラクタで、可変にしつつ、デフォルト60とかでもいい
大事なのは、そのキャンペーンを、何度やるか
2回目が決まった時に、可変にしたって、いい
でも、一回しかやらない場合でも、業務を明確化するために、クラスにする
それは、条件がどんなに小さくても、だ
2023/04/22(土) 11:54:05.38
>>752 みたいなお題だと、
検索による一覧画面は実装済みで
それを眺めてる内に「ボタンで案内を送れたら便利かも」
って思いつくような経緯もありそうですね
2023/04/22(土) 11:54:24.53
>>830
内部的には全て1件ずつループしてる
使う側が全部リストに入れてから使うか、逐次処理するか選ぶ
2023/04/22(土) 11:55:05.81
>>830
IQueryable じやなくて、IEnumerable だった
843仕様書無しさん
垢版 |
2023/04/22(土) 11:56:56.26
ポイントテーブルが処理のトリガーなのか
ユーザークラス生成の前にポイントの読み込みが先ですわね
こりゃお恥ずかしい　ガハハハ
2023/04/22(土) 11:58:58.80
古えの90年代に存在したADOのRecordSetは破棄するまでDBに繋がったまま一行ずつフェッチする例だった気がする
メモリが少ないしそうなるよなって思うやつ
2023/04/22(土) 11:59:49.30
>>836
というか、使う側のメンタリティが、変わった、のだろう
完全性だのなんだのと、とにかく、データが厳密であることを、求められた、昔は
大衆が、稀にしか起きないデータ誤りなら、運用でカヴァーした方が、安い、実行速度が速い、と気付いた
2023/04/22(土) 11:59:57.46
検索結果オブジェクトと
案内の内容オブジェクトを
いい感じで連携させればいい
2023/04/22(土) 12:00:14.04
お前らが華麗に設計して作ったクラスも、チームの他のメンバーからは誰にも気づかれず二度と再利用される事はないのであった…
2023/04/22(土) 12:02:27.12
>>847
まあ、悲しいけど、悲しいけど、これが現実よな
2023/04/22(土) 12:03:37.05
再利用なんて実感として1割以下なんだけど世の中はそこそこ再利用されているものなのか？
850仕様書無しさん
垢版 |
2023/04/22(土) 12:04:28.56
Javaとデザインパターンかなり覚えたけど
結局、設計する事はなくソース解析の時にしか約に立たなかったわ

だから土方は土方のままなんだわ
Javaは大規模システムに向いているから商流によって作業が違うので
規模の大きな会社に居ないとド底辺作業員になるというロジックが成り立つ

のでJavaを捨ててpythonReactマンになりますた
2023/04/22(土) 12:05:22.25
汎用的なクラスってのはいろんなパターンを想定して無駄に複雑だったりするからな
まずそれを理解するコストが面倒くせ！ってなるんよ
2023/04/22(土) 12:05:39.14
>>827
いいわけねーだろ無職
2023/04/22(土) 12:06:33.99
>>852
時と場合、と、言っとるやろがい！
2023/04/22(土) 12:07:42.10
今日はいい議論ができた
5chもたまには有意義なのだな
2023/04/22(土) 12:07:52.25
一発のみでもDIにしとけよとは思う
2023/04/22(土) 12:08:33.21
>>850
そりゃデザインパターンの大半はフレームワークを作る側か、シミュレーション分野などでしか使わんからな

普通の業務システムではフレームワークの選定とオレオレフレームワークに調整する作業者でないと、かっちりハマる機会はあまり無い
2023/04/22(土) 12:10:43.85
>>853
キャンペーンのたびにコードをデプロイし直すなんて仕様が許されるわけないだろ
2023/04/22(土) 12:10:49.30
>>831
今日のエレガント賞
2023/04/22(土) 12:11:33.72
休日だからS級からZ級まで色んなプログラマが来てる
いや、S級は来ねえかｗ
860仕様書無しさん
垢版 |
2023/04/22(土) 12:11:33.74
>>856
そうっすよね

個人的には業務をシステムに落とし込む段階で
オブジェクト指向とかデザインパターンって約に立つと
思ってたといか想像してたけど

そういう機会はないまま俺のJava道は終わりを告げたのだった
2023/04/22(土) 12:12:47.42
>>857
いや許されるだろう
今はddとやかく言うよりdevops進めて週一リリースをできるようにする時代だ
2023/04/22(土) 12:13:32.14
Javaは勉強するものであって実務で使う物ではない
例外で金融だけはJavaがベストだけど
863仕様書無しさん
垢版 |
2023/04/22(土) 12:13:53.44
で、お前ら昼飯何食うの
2023/04/22(土) 12:14:12.77
>>857
緊急に決まったキャンペーンでいちいち呼び出されて設計実装テストアップロード更新とかやってらんないよな
キャンペーンテーブルを作ってそこにクライアントがデータを打ち込めるUIを作るに決まってる
2023/04/22(土) 12:14:37.12
コーディングするこっち側が
可変部の見当付けておいて、
なんなら半自動でソース生成すればいい
2023/04/22(土) 12:15:01.15
>>857
許される
つか、今どきは、みんな、コードマージして、自動でポン、だろ
承認ボタンを間に挟むかど、うかは、組織ポリシーだが
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況