X

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

■ このスレッドは過去ログ倉庫に格納されています
0718仕様書無しさん
垢版 |
2023/04/22(土) 09:44:34.01
ChatGPTにCording interviewの相手して貰うとか出来るかな
0719仕様書無しさん
垢版 |
2023/04/22(土) 09:45:45.00
>>716
本気なら対策コース有るで
interviewcake.comとか
0720仕様書無しさん
垢版 |
2023/04/22(土) 09:48:05.89
>>719
さんきゅー
0721仕様書無しさん
垢版 |
2023/04/22(土) 09:50:32.46
>>713
俺もそう思っていたが実際は逆だった
駆け出しから進歩してないんだ大半の連中は
みんながエクセルで手続き型スパゲッティ疑似コードを書いてる
そこでオブジェクト指向だのなんだの言っても煙たがられるだけ
0722仕様書無しさん
垢版 |
2023/04/22(土) 09:53:27.44
ワイ「gitHubActionsとterraformでノンストップデプロイ実現したお」
お客たま「すげーな　じゃリリース手順書かいて印鑑もらってきて」
ワイ「・・・・・・・イエッサー」
0723仕様書無しさん
垢版 |
2023/04/22(土) 09:53:28.33
わからんでもない
ただその糞溜まりから抜け出す時に必要になるで
0724仕様書無しさん
垢版 |
2023/04/22(土) 09:58:40.75
みんな手続き型に戻る
時代はREST
オブジェクト志向は間違いだった
0726仕様書無しさん
垢版 |
2023/04/22(土) 10:01:33.95
正しいオブジェクト志向はExcelVBAだけ
データに処理がついてる
0727仕様書無しさん
垢版 |
2023/04/22(土) 10:01:46.97
オブジェクト指向が間違いとされる理由は、
できるヤツにしかできないから。
属人化しやすいからコストダウンにはつながらない。
0729仕様書無しさん
垢版 |
2023/04/22(土) 10:02:29.72
ExcelVBAでオブジェクト指向で書かんといかんなんて意識したことない
0730仕様書無しさん
垢版 |
2023/04/22(土) 10:05:22.90
セル一つ一つが明らかにオブジェクトなのに意識しなくてええなんてむしろ理想的やん
0731仕様書無しさん
垢版 |
2023/04/22(土) 10:05:36.84
「このソースをオブジェクト指向にしてください」って
ChatGPTにやってもらえばいいんじゃね？
0733仕様書無しさん
垢版 |
2023/04/22(土) 10:06:47.21
動的型付けなのにDimで変数宣言を強要してくる実に面倒くさいVBAさん
0734仕様書無しさん
垢版 |
2023/04/22(土) 10:07:35.01
>>723
俺は勉強したけど周りも勉強してていつか環境が変わると信じて留まってしまった
大きな間違いだった
0735仕様書無しさん
垢版 |
2023/04/22(土) 10:08:49.75
今どき、オブジェクト指向なんて言わなくても
オブジェクトだらけじゃんｗ
0738仕様書無しさん
垢版 |
2023/04/22(土) 10:12:15.40
VBAはオブジェクト指向だから使いやすいんじゃん
オブジェクト無かったらどんだけ覚えること増えると思ってんのよ
意識してないかもしれんけどプロシージャもほとんどイベント書いてるだけだろ
0740仕様書無しさん
垢版 |
2023/04/22(土) 10:20:44.61
好みのパラダイムが異なる人同士でチームを組むと大失敗する法則に名前をつけて業界で誰でも知ってるレベルに啓蒙したい
0742仕様書無しさん
垢版 |
2023/04/22(土) 10:24:18.78
とりあえずわかってることと言えば、
自分でブロック崩しやゲーム電卓などのチャチゲー作った際に、
これはオブジェクト指向で作っております、みたいなことは
とてもとても自分からは言えないな、恥ずかしくて。
0743仕様書無しさん
垢版 |
2023/04/22(土) 10:24:32.88
オブジェクト指向は設計手法だー
と何度言えば
思考でもいいわ　順々に処理してくと考えるな
機能単位で処理を分ける考えだけでもいいから持っとけ
0746仕様書無しさん
垢版 |
2023/04/22(土) 10:30:31.96
OOPやデザインパターンの目的はカプセル化による分割統治であってOOPやパターン自体が目的になってはいけない
分割統治する必要がない(将来の変更が少ない/分割統治しなくても設計/テスト時の負担が低い)なら別に適用せんでもよろしい

DDDで全部メッセージングでやりましょう、みたいなポリシーで全部疎結合にしましょう、とか良いアイデアだとは思うけど若干手段先行してる感ある
0749仕様書無しさん
垢版 |
2023/04/22(土) 10:34:43.97
石原莞爾かおのれは
0750仕様書無しさん
垢版 |
2023/04/22(土) 10:34:49.57
だってお
今の現場クソでお
PGの頭に全部DB_connectって書いてあんだよ
クソコード製造機のワイでも目を覆いたくなる惨状！！
0751仕様書無しさん
垢版 |
2023/04/22(土) 10:39:08.99
おじさん「ひと目でわかって良いじゃん！」
0752仕様書無しさん
垢版 |
2023/04/22(土) 10:39:40.41
ポイントテーブルからポイントが1000ポイント以上残ってる情報を読んで、
半年間利用の無いユーザをユーザーテーブルから読んで、ユーザーの年齢が60歳以上で、住んでる地域が、⚪︎×市の場合に、買い物実績テーブルに買い物実績があるユーザーを画面に一覧表示して、ボタンを押したらAマーケットでポイント利用促進の案内をSMSで通知する

みたいな処理って、いちいちオブジェクト思考で考えないで、手続き型でダラダラ書くよね
0755仕様書無しさん
垢版 |
2023/04/22(土) 10:42:46.84
言語？　Javaで十分だろ。
オブジェクト指向対応って謳ってるようだし。
0756仕様書無しさん
垢版 |
2023/04/22(土) 10:44:05.80
ｐｙてょん
0757仕様書無しさん
垢版 |
2023/04/22(土) 10:45:38.11
>>755　←　この人解ってるわ
そうオブジェクト指向対応言語なんだわな
0758仕様書無しさん
垢版 |
2023/04/22(土) 10:47:21.85
>>752
嘘だろ？
列挙する、表示する、広告を送る、の少なくとも三つに分けるだろ
その三つだけなら関数でもいいけど大きなシステムだとスパゲティ化を防ぐために構造化しないと保守性墜落すんじゃん
これだから土方は
後釜のことまで考えてコーディングしないからいつまで経っても評価上がらないんだぞ
0760仕様書無しさん
垢版 |
2023/04/22(土) 10:48:44.20
データベース　が　デーブスペクター　に見えたから休もう
0761仕様書無しさん
垢版 |
2023/04/22(土) 10:50:20.41
>>744
手続き型もそうじゃん、関数で分ければいいじゃん
0762仕様書無しさん
垢版 |
2023/04/22(土) 10:50:32.51
なぜ書けないんだよw
列挙メソッドを持つモデルクラス(他にも多くのメソッドがある)
表示を受け持つビュークラス
メッセージを送るモデルクラス
0763仕様書無しさん
垢版 |
2023/04/22(土) 10:54:37.78
OOPとかけまして、プログラマーの日常とときます
そのこころは、クラスを書いて暮らすでしょう
0764仕様書無しさん
垢版 |
2023/04/22(土) 10:56:02.61
えっ、クラスをかいてコード組むことかオブジェクト思考なの
0765仕様書無しさん
垢版 |
2023/04/22(土) 10:56:10.08
どっちに転んでも悪くなるやつだという強い予感があった
0766仕様書無しさん
垢版 |
2023/04/22(土) 10:56:19.26
ていうかユーザー一覧画面を処理ごとに作ってるのかよ
うわぁ。。。
0767仕様書無しさん
垢版 |
2023/04/22(土) 10:56:59.17
ね
なんで業務用システムを
毎回毎回１から作ってるのか
0769仕様書無しさん
垢版 |
2023/04/22(土) 10:58:37.30
>>762
その列挙メソッドを持つクラスってのは、少なくとも3つのテーブルから情報を取得して情報をフィルタして結果を返すラッパークラスだろ
しかも、よっぽどうまく設計しないと、この処理でしか使えないという
そして、本人は上手く設計したつもりでも、他のチームメンバーからは誰からも利用されることのないボッチクラスになる可能性が高い

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

なお、CQRSで割り切って、短いキャンペーンの間なら、表示までは、テキトーなSQLでええやろ、ならおk
ずっと残すものは、綺麗に作れ。これ大事
0803仕様書無しさん
垢版 |
2023/04/22(土) 11:20:18.50
>>798
一回のキャンペーンの条件に過ぎないものを全部オブジェクトとしてハードコーディングするのはさすがにアホだよね
0804仕様書無しさん
垢版 |
2023/04/22(土) 11:20:32.69
>>798
彼が言いたいのは仕様をDRYしろって大原則が抜け落ちるとdddのメリットの9割が消えるってのが主張したいことだろ
結果的に条件が横断的な仕様なら個別に別れてなきゃいかん
0806仕様書無しさん
垢版 |
2023/04/22(土) 11:23:23.63
マイクロサービスはそうするよ
という肯定意見がないのでこのスレはその程度なのだろう
0807仕様書無しさん
垢版 |
2023/04/22(土) 11:23:25.89
何万件ものデータ扱うならDBとか意味あるけど
たかだか数百件扱うのに導入する意味が分からないよ
0808仕様書無しさん
垢版 |
2023/04/22(土) 11:24:25.32
>>798
一つ一つとか関係ない
それが業務で定義されてるのなら、どんなに小さくても、作るのだ
システムは、気持ち、で開発するのではない
業務、ドメインを再現するのじゃ
それがDDDなのじゃよ
0809仕様書無しさん
垢版 |
2023/04/22(土) 11:24:32.70
条件をオブジェクトにするやつって複数のキャンペーンにどう対応するんだろう
全部クラス化するのか？
0813仕様書無しさん
垢版 |
2023/04/22(土) 11:27:49.76
>>799
変更が多い時に最も大切なことはテストだろう
テストしやすいようにDDDしよう
0814仕様書無しさん
垢版 |
2023/04/22(土) 11:28:18.69
>>809
クラス化しても、後でそれでカバーできない条件ってのが絶対出てくるから、クラスの書き直し、それに依存してるコードの修正、そしてテストも失敗するから、大量のテストの修正ってパターンだな
0815仕様書無しさん
垢版 |
2023/04/22(土) 11:28:56.78
DBにする理由は永続化でデータ件数とかより
こっちかなと
テキストとかCSVで保存すると排他制御とか
行単位では出来ないし、何がどれやら作った人にしか解らなくなる
0816仕様書無しさん
垢版 |
2023/04/22(土) 11:28:59.08
検索条件の一つ一つをクラス化しなきゃいけないと思ってるやつは電卓を作るときはボタンの一つ一つを全部クラス化しなきゃいけないとか思ってそうだな
Value Objectを知らんのだな
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況