プログラマの雑談部屋 ★38
■ このスレッドは過去ログ倉庫に格納されています
プログラマは
こちらで雑談してください。
ユーザ、ＳＥが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。
※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/
プログラマの雑談部屋 ★37
http://medaka.5ch.net/test/read.cgi/prog/1530182616/ いいなあ質問バカはヒマそうで。。。
うらやましくてウンコがでるよ。。。 マピオンのサイトに
フィッシングサイトが仕掛けられてるから注意な。
いきなりgoogleの何かの当選です！という
表示がされてびっくりした。
ソースをちょっとみたらコメントにgaqダミー入れとくとか
書いてあるけどそこかなあ？
めんどいから詳しく見る気はしないけど、
マピオンは使わないほうがいいな。
つかマピオンは中国の下請け企業にでも
作らせてるんだろう >>649
そんなわかりきったことを書く意味はない
ドメイン層のエンティティとデータベース層のスキーマの対応はほとんど自動で決まるのだから
設計書にはコンテキストマップやドメインモデルなどもっと重要な情報を書いてくれ 些末なことを特定するのにどれほど労力がかかると思ってるのか おれが作ったスマホとかのアプリは全く売れないけど
おれ自身はよく売れる。 計算機が相手という論理矛盾に最もシビアな世界なのに求められるスキルは忖度 尊宅ってどっからでてきた言葉なんだ
４０年ぐらい生きてきてまじで最近はじめて聞いたんだけど
日本建国時にいろいろ文化的に言葉に仕込みをした連中がいるらしいので気になってる
中国語で変な意味だったりしないだろうな そりゃあ、能無しなんだから忖度で勝負するしかねーやな。
ゴマすりとか酒づきあいとか。 >>684
あ、あと隣のグループの議事録も
「メールCCでこの会議連絡あったよね？」
「議事録を置く場所知ってるよね？」
「知ってるのになんで見てないの？」 アジャイルだからと言って計画を立てずにひたすら突き進むマネージャー
プロジェクトがコケたらマネージャーだけ残って私達は切られるんだろうなぁ アジャイルを何も決めずに見切り発車で開発する手法と勘違いするアホがいる そりゃあ、成果だけなら中国やベトナムで十分なんだから
忖度で勝負するしかねーやな。
ゴマすりとか酒づきあいとか。 >>691
私は下っ端だから何も言えない
なんかもう嫌だ >>680
設計に労力がかかるのは当たり前
・設計
・設計書作成
この2つのプロセスを分けて考えられん？
じっくり時間と労力をかけて細かいことを決めるのが設計
設計したことを何らかの形でアウトプットするのが設計書作成
アウトプットの形式ってのは
専用の設計書作成ツールで作る
エクセルで作る
紙やホワイトボードに書く(パシャる)
など様々で決まったやり方というのはない
そんな多様なアウトプットの形式の1つとしてコードがある
つまりコードは設計書ってことだ
設計と設計書作成の区別がついてないバカは設計をおろそかにして見切り発車で設計書作成を始めてしまう
だからおぞましい悪夢のようなスパゲティ設計書(殆どの場合エクセル)が生産される
この手の設計書は体裁だけ整えたゴミなので背後にある設計が全く見えてこない
逆に設計をよく練る人は即コーディングをしても美しいコードを作る
コードから設計がよく見えて保守もしやすい >>268
こういうのも実は設計する段階ではキッチリと決まっている
設計→エクセル設計書作成→エクセル設計書からコードへコピー
この3段階の無駄なプロセスでプロジェクトを回す前提だったのに
エクセル設計書作成の工程に漏れが有ったということなんだろう
設計したことをさっさとコードとして書いてしまえば>>268が悩むこともなかっただろう >>699
エクセルなんぞで遊んでないでテストコードを書く
社会人の常識でしょう >>679
慣れたらエスパーみたいなもんでわかるものなのか？
どのテーブルのどのカラムから取ればいいのか >>703
慣れとかじゃなくて機械的にマップするんだよ >>704
機械的にマップするってどうやるんだ？
どれ取ってこればいいかわからないのに？ イベントソーシングとかCQRSって誰も使ってない？
CRUDの従来型システムには無い様々なメリットがあるんだが
・実証可能な監査証跡を残せる
・履歴データに基づいたクエリモデルを作れる
・（コマンドの）副作用を気にせずに済む
・トラブルシューティングやデバッグの助けになる
CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも？」
https://postd.cc/using-cqrs-with-event-sourcing/ おれの世代だと、
１．外部設計 （現在の要件定義＋基本設計）
２．内部設計 （現在なくなってる！？）
３．詳細設計 プログラムの設計書
となっていた。
だが経験の豊かなプログラマが作成していた内部設計書というものが、
90年代中ごろから無くなってしまった。
なじぇ？ >>707
自分は設計書にどのテーブルのどのカラムからデータ取ってこればいいか書かれてなくて困ってて
>>679だとそれが自動で決まるってあるからなにか見分けつける方法あるのかな？って思ったんよ
今の現場の画面設計書だと同じ表記で違うカラムから取ってくるってことがあったから >>708
JavaやC#やHTMLの表現力も生産性もBasicやCobolにくらべてはんぱないから
あんまりいらなくなったのもある
おれが思うに、詳細設計書を詳細に書きすぎると
製造と設計を別人が行うとき、
作業者が満足度を著しく下げる上に
作業者が考えて判断するということをしなくなってしまう
細かくかくなら達成すべきことを
内部の設計がかわってもいいように細かくかいておくべきだ >>706
ここにいるのは多分ほとんど業務系の土方だろう
普通に考えて使ってるわけがないと思うが？
イベントソースやDDDはおろかそもそもオブジェクト指向すら理解してない奴らが多数派でしょ
イベントソースなんて百年早いわ
そもそも業務系システムはリアルタイム性と正確性を重要視するから
仮にスキルが十分でもイベントソースは採用しにくいだろうね >>708
エコシステムの進化が原因
便利な入力支援もなくチェックもテストもできないエクセルで設計を練るより
快適なIDEでコードを書いてテストしながらリファクタリングする方が簡単だと気が付いた
昔はパンチカードでプログラミングしたり
コンパイルに一晩もかかったり
自動テストがまったく普及してなかったり
そもそもIDEが重くてまともに動かなかったり
なんてことがあったからじっくり設計書を練りこんでコーディングは最小限にしようって判断が正しかった
でも今はまったく状況が違うから設計書なんて要らなくなった 設計書を書いとかないといっぺん決めたことを忘れてしまう
細かいところで整合性がとれずにソフトがぐちゃぐちゃになる いらないなんて言ってるやつはものすごく小さい範囲の末端だけちぎって投げられてる土方にちがいない >>709
なんだか話がおかしくなってきたぞ
なんで画面設計書にデータベースが出てくるんだ？
設計をちゃんとしてから設計書を書いたのか？
見切り発車で適当な設計書を書いたせいで画面設計書にデータベース処理仕様を混ぜ込んでしまったんじゃないのか？ >>713
頭の中に置いとけと言ってるわけじゃない
決まったことをコードとして完結明快に保存するんだ >>715
自分は実装担当で現場に入ったんだそれで作られた設計書見て作ってねと言われて設計書見たら画面のここはこのデータを表示してってのがデータベースの値を取ってくるんだろうけどあまり詳細に書かれてないんだ
データベースのテーブルから推測したりして探してみたりしたけど似たようなテーブル名やカラム名が多くて判別つかないんよ
最近はPM？の人に聞いて教えてくれるけどなら最初から設計書に書いてほしいかなーって 三層アーキテクチャも知らない素人が設計書を書くとか冗談じゃないよね
画面にデータベースをマッピングだって？
そんな設計書に付き合わされるプログラマはたまったもんじゃない
ようするにさ
設計書をありがたがる人ほど設計なんてしてないんだよ
設計書というなのスパゲティを書いて設計 し た つ も り になってんの >>717
モジュール、名前空間、クラス名、メソッド名
これでどこに何があるかわからんなら
そもそも設計やプログラム構造がめちゃくちゃなんだろうな
このへん手抜きせずに決めればかなり検索性が高くなるぞ
つかファイルシステムとエクセルの組み合わせの方がはるかに探しにくいわな それを整理してどれにどんな名前を付ければいいか判断するには
最初に一覧を作らなきゃむりだろ！
脳内で何千件も処理できるもんか
そしたらそれをメモ書きして捨てるか設計書に残すかってなる
捨てるのはもったいないからちょっとばかり労力を払って内部設計としておいとくことになる
設計書いるじゃねーか 場当たり的にコード改修して整頓された見通しのよさが保てるわけがない
設計したことない連中が主張の都合のいいところだけつまみ食いして
バラ色の未来を提示してる いや設計はしてるんだっていってるけど
設計したんだったら設計書かくのにそれほど苦労しないはずだろ！
なんでなにもないんだ >>722
なんで最初から全部リストアップする必要がある
受注管理の命名をするときに顧客管理の命名をリストアップする必要があるか？
分割して統治せよって新人研修で教わらなかったのか？
そんなことも教えてくれないなんて同業者として憐れみを感じるよ >>723
場当たり的に書いて整理すらしなかったものがエクセル設計書だよ
>>718などは完全にその被害者だろ
設計書は作ったけど設計はしてないとこうなるんだ
逆に良く設計してればコードがドキュメントになるので設計書はいらん >>725
机上の空論破綻はアリの穴から
どこに何をどういうルールで置くか、その分割を適切にできるかどうかは
最初にどれだけ網羅できるかにかかってる
名前はものを区別するためにあるんだ ここにいる人はどんな資格を持ってる？
VBAエキスパートは今更遅いかな 設計書を書くツールがエクセルからIDEに変わって
設計書の出力形式がエクセルからテキストファイルに変わって
設計記述のルールが厳密にチェックされるようになった
それだけのことじゃん？
コードで整理できないって人がエクセルで急に整理できるようになるとは思えんけど 一覧管理のために生まれたExcel様のパワーなめるな >>727
ログイン処理の機構を考えているときに在庫管理のことを考えるか？しないね
全てをまとめて網羅する必要などどこにもないんだよ
分割して統治せよ
君が真っ先に理解すべき概念だ
来週の業務が始まるまでに理解しておいてくれ >>733
在庫管理システムだけプラットフォーム別になってて
ログインユーザーの権限が連動してる必要あるんですけど >>737-738
全の値段は幾らぐらいでしょうか？ >>735
それこそ権限管理のコンテキストで解決する問題
在庫管理のコンテキストを巻き込んではいけない
分割して統治しておいて良かったねと締めくくられメデタシメデタシだな >>711
CQRS/ESでは結果整合性を使うから、
複数のリードモデルがあると一部の反映が遅れる場合があるって弱点はあるが
僅かな期間の表示のズレも許容出来ないようなアプリケーションばかりかって言うと
そうでもないのでは？ >>741
>>743
全の値段は幾らぐらいでしょうか？ >>749−750
全の値段は幾らぐらいでしょうか？ >>749-750
全の値段は幾らぐらいでしょうか？ >>763-764
全の値段は幾らぐらいでしょうか？ >>740
お前がどんな絵をかいてるのか設計書がないから見えない伝わらない
そのシステムユーザーに在庫の製品種別ごとの権限ついててログイン管理してるんですが ■ このスレッドは過去ログ倉庫に格納されています
