X

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

■ このスレッドは過去ログ倉庫に格納されています
2018/07/07(土) 13:38:07.62
プログラマは
こちらで雑談してください。

ユーザ、ＳＥが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。

※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/
プログラマの雑談部屋 ★37
http://medaka.5ch.net/test/read.cgi/prog/1530182616/
2018/07/14(土) 08:23:37.87
尊宅ってどっからでてきた言葉なんだ
４０年ぐらい生きてきてまじで最近はじめて聞いたんだけど

日本建国時にいろいろ文化的に言葉に仕込みをした連中がいるらしいので気になってる
中国語で変な意味だったりしないだろうな
2018/07/14(土) 08:24:40.41
death mass 調
2018/07/14(土) 08:28:08.38
世の経営者がAIに求めているのは忖度力
688仕様書無しさん
垢版 |
2018/07/14(土) 08:28:10.81
そりゃあ、能無しなんだから忖度で勝負するしかねーやな。
ゴマすりとか酒づきあいとか。
2018/07/14(土) 08:29:15.06
>>684
あ、あと隣のグループの議事録も
「メールCCでこの会議連絡あったよね？」
「議事録を置く場所知ってるよね？」
「知ってるのになんで見てないの？」
2018/07/14(土) 08:36:20.99
アジャイルだからと言って計画を立てずにひたすら突き進むマネージャー
プロジェクトがコケたらマネージャーだけ残って私達は切られるんだろうなぁ
2018/07/14(土) 08:37:18.57
アジャイルを何も決めずに見切り発車で開発する手法と勘違いするアホがいる
692仕様書無しさん
垢版 |
2018/07/14(土) 08:38:30.30
そりゃあ、成果だけなら中国やベトナムで十分なんだから
忖度で勝負するしかねーやな。
ゴマすりとか酒づきあいとか。
2018/07/14(土) 08:38:33.43
>>691
私は下っ端だから何も言えない
なんかもう嫌だ
694仕様書無しさん
垢版 |
2018/07/14(土) 08:39:08.26
プロジェクトがコケても残される哀れなマネージャー
2018/07/14(土) 08:44:02.64
マネジメントできないマネージャーを残す意味…
2018/07/14(土) 08:50:42.24
>>680
設計に労力がかかるのは当たり前

・設計
・設計書作成

この2つのプロセスを分けて考えられん？
じっくり時間と労力をかけて細かいことを決めるのが設計
設計したことを何らかの形でアウトプットするのが設計書作成

アウトプットの形式ってのは
　専用の設計書作成ツールで作る
　エクセルで作る
　紙やホワイトボードに書く(パシャる)
など様々で決まったやり方というのはない
そんな多様なアウトプットの形式の1つとしてコードがある
つまりコードは設計書ってことだ

設計と設計書作成の区別がついてないバカは設計をおろそかにして見切り発車で設計書作成を始めてしまう
だからおぞましい悪夢のようなスパゲティ設計書(殆どの場合エクセル)が生産される
この手の設計書は体裁だけ整えたゴミなので背後にある設計が全く見えてこない

逆に設計をよく練る人は即コーディングをしても美しいコードを作る
コードから設計がよく見えて保守もしやすい
2018/07/14(土) 08:53:29.03
暑くてイライラしてんのに長文書くんじゃねえ
698仕様書無しさん
垢版 |
2018/07/14(土) 09:03:53.07
>>268
こういうのも実は設計する段階ではキッチリと決まっている

設計→エクセル設計書作成→エクセル設計書からコードへコピー

この3段階の無駄なプロセスでプロジェクトを回す前提だったのに
エクセル設計書作成の工程に漏れが有ったということなんだろう

設計したことをさっさとコードとして書いてしまえば>>268が悩むこともなかっただろう
2018/07/14(土) 09:33:06.96
え…エクセル設計書はテストの根拠になるから…
2018/07/14(土) 10:21:40.26
>>699
エクセルなんぞで遊んでないでテストコードを書く
社会人の常識でしょう
701仕様書無しさん
垢版 |
2018/07/14(土) 10:26:04.23
Code First!
2018/07/14(土) 10:55:42.93
設計書おじさんは不滅
2018/07/14(土) 11:15:53.74
>>679
慣れたらエスパーみたいなもんでわかるものなのか？
どのテーブルのどのカラムから取ればいいのか
2018/07/14(土) 11:27:04.34
>>703
慣れとかじゃなくて機械的にマップするんだよ
2018/07/14(土) 11:33:04.47
>>704
機械的にマップするってどうやるんだ？
どれ取ってこればいいかわからないのに？
706仕様書無しさん
垢版 |
2018/07/14(土) 11:53:55.26
イベントソーシングとかCQRSって誰も使ってない？
CRUDの従来型システムには無い様々なメリットがあるんだが

・実証可能な監査証跡を残せる
・履歴データに基づいたクエリモデルを作れる
・（コマンドの）副作用を気にせずに済む
・トラブルシューティングやデバッグの助けになる

CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも？」
https://postd.cc/using-cqrs-with-event-sourcing/
2018/07/14(土) 12:51:58.59
>>705
何言ってんだ？
708仕様書無しさん
垢版 |
2018/07/14(土) 13:00:48.16
おれの世代だと、
１．外部設計　（現在の要件定義＋基本設計）
２．内部設計　（現在なくなってる！？）
３．詳細設計　プログラムの設計書
となっていた。

だが経験の豊かなプログラマが作成していた内部設計書というものが、
90年代中ごろから無くなってしまった。
なじぇ？
2018/07/14(土) 13:08:34.80
>>707
自分は設計書にどのテーブルのどのカラムからデータ取ってこればいいか書かれてなくて困ってて
>>679だとそれが自動で決まるってあるからなにか見分けつける方法あるのかな？って思ったんよ
今の現場の画面設計書だと同じ表記で違うカラムから取ってくるってことがあったから
2018/07/14(土) 13:20:18.17
>>708
JavaやC#やHTMLの表現力も生産性もBasicやCobolにくらべてはんぱないから
あんまりいらなくなったのもある

おれが思うに、詳細設計書を詳細に書きすぎると
製造と設計を別人が行うとき、
作業者が満足度を著しく下げる上に
作業者が考えて判断するということをしなくなってしまう

細かくかくなら達成すべきことを
内部の設計がかわってもいいように細かくかいておくべきだ
2018/07/14(土) 13:22:08.26
>>706
ここにいるのは多分ほとんど業務系の土方だろう
普通に考えて使ってるわけがないと思うが？

イベントソースやDDDはおろかそもそもオブジェクト指向すら理解してない奴らが多数派でしょ
イベントソースなんて百年早いわ

そもそも業務系システムはリアルタイム性と正確性を重要視するから
仮にスキルが十分でもイベントソースは採用しにくいだろうね
2018/07/14(土) 13:28:59.17
>>708
エコシステムの進化が原因

便利な入力支援もなくチェックもテストもできないエクセルで設計を練るより
快適なIDEでコードを書いてテストしながらリファクタリングする方が簡単だと気が付いた

昔はパンチカードでプログラミングしたり
コンパイルに一晩もかかったり
自動テストがまったく普及してなかったり
そもそもIDEが重くてまともに動かなかったり
なんてことがあったからじっくり設計書を練りこんでコーディングは最小限にしようって判断が正しかった
でも今はまったく状況が違うから設計書なんて要らなくなった
2018/07/14(土) 13:30:28.75
設計書を書いとかないといっぺん決めたことを忘れてしまう
細かいところで整合性がとれずにソフトがぐちゃぐちゃになる
2018/07/14(土) 13:32:19.23
いらないなんて言ってるやつはものすごく小さい範囲の末端だけちぎって投げられてる土方にちがいない
2018/07/14(土) 13:33:04.64
>>709
なんだか話がおかしくなってきたぞ
なんで画面設計書にデータベースが出てくるんだ？
設計をちゃんとしてから設計書を書いたのか？
見切り発車で適当な設計書を書いたせいで画面設計書にデータベース処理仕様を混ぜ込んでしまったんじゃないのか？
2018/07/14(土) 13:39:21.43
>>713
頭の中に置いとけと言ってるわけじゃない
決まったことをコードとして完結明快に保存するんだ
2018/07/14(土) 13:42:26.74
コードは見通し悪すぎだ
検索性がひどい
2018/07/14(土) 13:42:46.20
>>715
自分は実装担当で現場に入ったんだそれで作られた設計書見て作ってねと言われて設計書見たら画面のここはこのデータを表示してってのがデータベースの値を取ってくるんだろうけどあまり詳細に書かれてないんだ
データベースのテーブルから推測したりして探してみたりしたけど似たようなテーブル名やカラム名が多くて判別つかないんよ
最近はPM？の人に聞いて教えてくれるけどなら最初から設計書に書いてほしいかなーって
2018/07/14(土) 13:43:29.07
三層アーキテクチャも知らない素人が設計書を書くとか冗談じゃないよね
画面にデータベースをマッピングだって？
そんな設計書に付き合わされるプログラマはたまったもんじゃない

ようするにさ

設計書をありがたがる人ほど設計なんてしてないんだよ

設計書というなのスパゲティを書いて設計 し た つ も り になってんの
2018/07/14(土) 13:49:09.95
>>717
モジュール、名前空間、クラス名、メソッド名

これでどこに何があるかわからんなら
そもそも設計やプログラム構造がめちゃくちゃなんだろうな
このへん手抜きせずに決めればかなり検索性が高くなるぞ

つかファイルシステムとエクセルの組み合わせの方がはるかに探しにくいわな
2018/07/14(土) 13:52:00.50
>>720
で？
2018/07/14(土) 13:54:21.05
それを整理してどれにどんな名前を付ければいいか判断するには
最初に一覧を作らなきゃむりだろ！
脳内で何千件も処理できるもんか

そしたらそれをメモ書きして捨てるか設計書に残すかってなる
捨てるのはもったいないからちょっとばかり労力を払って内部設計としておいとくことになる

設計書いるじゃねーか
2018/07/14(土) 13:56:37.25
場当たり的にコード改修して整頓された見通しのよさが保てるわけがない

設計したことない連中が主張の都合のいいところだけつまみ食いして
バラ色の未来を提示してる
2018/07/14(土) 13:58:13.48
いや設計はしてるんだっていってるけど
設計したんだったら設計書かくのにそれほど苦労しないはずだろ！

なんでなにもないんだ
2018/07/14(土) 14:02:24.11
>>722
なんで最初から全部リストアップする必要がある
受注管理の命名をするときに顧客管理の命名をリストアップする必要があるか？
分割して統治せよって新人研修で教わらなかったのか？
そんなことも教えてくれないなんて同業者として憐れみを感じるよ
2018/07/14(土) 14:06:07.80
>>723
場当たり的に書いて整理すらしなかったものがエクセル設計書だよ
>>718などは完全にその被害者だろ
設計書は作ったけど設計はしてないとこうなるんだ
逆に良く設計してればコードがドキュメントになるので設計書はいらん
2018/07/14(土) 14:08:39.65
>>725
机上の空論破綻はアリの穴から
どこに何をどういうルールで置くか、その分割を適切にできるかどうかは
最初にどれだけ網羅できるかにかかってる

名前はものを区別するためにあるんだ
2018/07/14(土) 14:10:20.90
ここにいる人はどんな資格を持ってる？
VBAエキスパートは今更遅いかな
2018/07/14(土) 14:10:49.50
>>727
しらねーよ
2018/07/14(土) 14:11:46.50
設計書を書くツールがエクセルからIDEに変わって
設計書の出力形式がエクセルからテキストファイルに変わって
設計記述のルールが厳密にチェックされるようになった

それだけのことじゃん？
コードで整理できないって人がエクセルで急に整理できるようになるとは思えんけど
2018/07/14(土) 14:14:55.62
一覧管理のために生まれたExcel様のパワーなめるな
732仕様書無しさん
垢版 |
2018/07/14(土) 14:16:00.32
>>677
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 14:19:51.07
>>727
ログイン処理の機構を考えているときに在庫管理のことを考えるか？しないね
全てをまとめて網羅する必要などどこにもないんだよ

分割して統治せよ

君が真っ先に理解すべき概念だ
来週の業務が始まるまでに理解しておいてくれ
2018/07/14(土) 14:20:56.90
>>732
ごりら
2018/07/14(土) 14:22:33.09
>>733
在庫管理システムだけプラットフォーム別になってて
ログインユーザーの権限が連動してる必要あるんですけど
736仕様書無しさん
垢版 |
2018/07/14(土) 14:27:40.25
>>734
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 14:32:57.90
>>736
ごりら
2018/07/14(土) 14:36:36.19
>>736
ごりら
739仕様書無しさん
垢版 |
2018/07/14(土) 14:41:01.63
>>737-738
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 14:41:59.24
>>735
それこそ権限管理のコンテキストで解決する問題
在庫管理のコンテキストを巻き込んではいけない
分割して統治しておいて良かったねと締めくくられメデタシメデタシだな
2018/07/14(土) 14:42:26.14
>>739
ごりら
742仕様書無しさん
垢版 |
2018/07/14(土) 14:44:10.01
>>711
CQRS/ESでは結果整合性を使うから、
複数のリードモデルがあると一部の反映が遅れる場合があるって弱点はあるが
僅かな期間の表示のズレも許容出来ないようなアプリケーションばかりかって言うと
そうでもないのでは？
2018/07/14(土) 14:49:53.66
>>739
ごりら
744仕様書無しさん
垢版 |
2018/07/14(土) 14:54:23.06
>>741
>>743
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 14:57:37.05
>>744
ごりら
746仕様書無しさん
垢版 |
2018/07/14(土) 14:58:26.50
>>745
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:05:10.41
>>746
ごりら
748仕様書無しさん
垢版 |
2018/07/14(土) 15:10:22.06
>>747
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:11:34.44
>>748
ごりらあ
2018/07/14(土) 15:12:22.34
>>748
ごりら
2018/07/14(土) 15:18:17.06
>>742
で？
752仕様書無しさん
垢版 |
2018/07/14(土) 15:21:57.55
>>749−750
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:22:34.16
>>752
ごりら
754仕様書無しさん
垢版 |
2018/07/14(土) 15:22:44.95
>>749-750
全の値段は幾らぐらいでしょうか？
755仕様書無しさん
垢版 |
2018/07/14(土) 15:23:10.35
>>753
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:26:00.13
>>755
ごりら
757仕様書無しさん
垢版 |
2018/07/14(土) 15:26:21.64
>>756
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:27:25.87
>>757
ごりら
2018/07/14(土) 15:27:38.47
>>754
ごりら
760仕様書無しさん
垢版 |
2018/07/14(土) 15:27:44.11
>>758
全の値段は幾らぐらいでしょうか？
761仕様書無しさん
垢版 |
2018/07/14(土) 15:29:05.62
>>759
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:30:22.95
>>760
1ドル
2018/07/14(土) 15:31:05.16
>>760
ごりら
2018/07/14(土) 15:31:20.64
>>761
ごりら
765仕様書無しさん
垢版 |
2018/07/14(土) 15:34:11.74
>>763-764
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:36:03.29
>>740
お前がどんな絵をかいてるのか設計書がないから見えない伝わらない
そのシステムユーザーに在庫の製品種別ごとの権限ついててログイン管理してるんですが
2018/07/14(土) 15:37:00.06
>>765
ごりら
768仕様書無しさん
垢版 |
2018/07/14(土) 15:39:50.71
>>767
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:40:27.31
>>768
ごりら
770仕様書無しさん
垢版 |
2018/07/14(土) 15:43:05.13
>>769
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:44:39.45
>>566
高単価でも定時で帰ればいいじゃん
2018/07/14(土) 15:45:34.24
>>770
ごりら
773仕様書無しさん
垢版 |
2018/07/14(土) 15:45:54.04
>>772
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:46:39.64
>>773
ごりら
775仕様書無しさん
垢版 |
2018/07/14(土) 15:48:21.10
>>774
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:50:13.72
>>775
ごりら
2018/07/14(土) 15:50:19.33
>>766
コードみればわかるよ
778仕様書無しさん
垢版 |
2018/07/14(土) 15:50:58.17
>>776
全の値段は幾らぐらいでしょうか？
2018/07/14(土) 15:53:21.95
ご無体な…
2018/07/14(土) 15:55:26.72
>>766
在庫管理に特殊な権限管理が必要なら在庫管理のコンテキストに組み込むか在庫権限管理など新しいコンテキストを作るかな
いずれにせよ一般的なログイン管理と在庫管理を同時に考えることはないよ
2018/07/14(土) 16:04:55.14
「在庫権限管理」

ほら言葉がでてきただろ
俺がシステムの実情を伝える前にコードは設計とばかりに書き下してたら
後からどうなってたことやら
782仕様書無しさん
垢版 |
2018/07/14(土) 16:07:42.02
>>710
多分、若い人はそういう考えなんだろうと思う。
Webを中心としたシステム構成が増えてきて、
すぐに仕様変更できてしまうから、いちいちドキュメントを
直すなんてほうが無駄に時間がかかるしね。

仕事によって作成するドキュメントの種類や内容を変える必要があるのに、
内部設計書を書いたことのないWebプログラマなどが大規模業務系には参加して、
「なにこれメンドクセ！」とか言って重要なドキュメントを書かなくなったのだろう。
2018/07/14(土) 16:15:41.93
>>781
今の会話セッションは「設計」プロセスな
設計中に新しい用語が出てくるのは当然のこと
プログラミングはこれから始まるんだよ

さらに言うとログイン処理の命名を決めようというときには結局、在庫管理も在庫権限管理も関係がない
ログイン処理関連の命名は在庫管理のことなど気にせず決めていいし、在庫管理も逆に同じこと
新しく出てきた在庫権限管理もログイン処理とは独立して考えられるが、在庫管理とは上流下流の関係にありそうだから、在庫管理と在庫権限管理は多少関わり合った方がいいかもね

こうして物事を分けて個別に考えられるのは分割して統治するという基本ができてるから
君にも早く身につけてほしい概念だ
784仕様書無しさん
垢版 |
2018/07/14(土) 16:16:58.35
日商PC検定試験のデータ活用1級って持ってるとなんか意味ある？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況