プログラマの雑談部屋 ★38
■ このスレッドは過去ログ倉庫に格納されています
プログラマは
こちらで雑談してください。
ユーザ、SEが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。
※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/
プログラマの雑談部屋 ★37
http://medaka.5ch.net/test/read.cgi/prog/1530182616/ ひーひー言いながら仕様書の機能実装してよしオッケー→使いにくいからここ変更して
ってのを延々繰り返している。残業してもいいから……みたいな発言までいよいよ飛び出した
これがIT業界の洗礼なのかなって今泣いてる >>611
俺はドヤ顔で残業代出るから沢山仕事して良いよと言われた
こんな業界で一生働けるのかな >>611
慣れるまで。
ここでいう慣れるというのは、どんな変更が来るか先読みできるようになる事と、どんな変更が来てもさほど改変なく(残業無くw)できるような設計をベースとして作れるようになる、まで。 打ち合わせに参加していると、
だいたいどういう変更がありそうかわかるけど、
プログラマごときは出席しないでよい、などという思いあがった
ユーザ―の場合、「忖度した設計」することができないから、
後ですごく困ったことになる。
プログラマは打ち合わせに出席すべき。
だって、出席した奴が馬鹿だったら、
その馬鹿からの説明の範囲しか知ることができないから、
その馬鹿のレベルを超えるシステムは作れなくなってしまう。
で、だいたい上司にゴマすってる馬鹿がリーダー格に
なって打ち合わせに出席したりするから困ったもの。 >>612
境界値テストしたらそんな操作しないからいいって・・・ >>610
もちろんその通りで今の現場は大変優良だと思う
ただ本来どこもそうあるべきだわ
打つだけで設計書残さないのはその後の機能追加の難易度を大幅に上げるし土方側も期間短くておいしくないし何もいいことがない ファーストサーバのZenlogicってなんで全然復旧しなかったの? >>617
難易度が高いのはコードでも設計書でも変わらんよ
特に誰でもコードが書けるように詳細まで書いた設計書はコードと同じかそれ以上にメンテナンスが難しい
なぜなら設計書はプログラムと比べてシステマチックに管理されておらず(フリーフォーマット)、
静的解析によるサポートもリファクタリングツールもユニットテストもUIテストも存在しないから
変更のリスクが恐ろしく高い
この事実から目をそらす人が多すぎるようだね >>614
設計は元請け正社員様なのが定石
その正社員様が瞬間湯沸かし器で論理矛盾をどうするか聞くとお前で考えろと発狂するのも良くあること
で、こっちで考えたものをお披露目すると、なんでこんな仕様にしたと激怒して派遣元にクレームという流れも経験済み >>620
>>特に誰でもコードが書けるように詳細まで書いた設計書
コレはゴミですわ そんなエクセル作ってる間にコーディングしろよって話だな >>623
そう
まさにゴミなんだけど
外注の派遣さんを使うと詳細すぎる設計書がないと全く働いてくれないから作るしかない 偽装請負や二重派遣とかって誰が罰金払ってるんだろう?
顧客なのかねぇ? 汚いコードの元になった設計書って同じぐらい汚いんだよね
そもそも論理的な設計が狂ってるから、それを文書としてアウトプットしたってろくなものにはならない
設計が綺麗ならダイレクトにコードにアウトプットしても問題なく読める
むしろ自然言語より読みやすい >>629
ツォンカパとオックスフォード大学の数学教授はどっちの方が賢いですか? >>630
お届けするには、今から13 時間 22 分以内にお急ぎ便を選択して注文を確定してください(Amazonプライム会員は無料) 裏口入学かぁいいなあ
青春犠牲にして第二志望だよオレ
日本の権力者はほんとやりたい放題だね
国民はさもっと怒らないとだめだよ
こんな国は民主主義じゃない やっぱりあのPMは進捗報告の数字しか見てなかった
アラート挙げても全部無視 >>635
でも末端のPGより給与も評価も高いよ? だからなんだ
アラートがPMに無視されたんだ
俺が困ってるんだひとの給料の話なんかしてない >>637
ID無い板だとお前みたいに成りすまして
わざと叩かれるレス書き込む奴いて虫唾が走るわ 美味しいとこは吸い上げてミスはPGに押し付ける
あとは怒鳴り散らしながら進捗を眺めるだけ
イージーすぎて笑えてくるわ >>634
日本神話と北欧神話はどっちの方が崇高ですか? 本当にそれはミスだったのか?
相手はお前の理解力のなさにげんなりしているかもしれない 「わかる人と話がしたい」という台詞が
管理者はスゲーむかつくらしいぞ。 件名:【アラート】緊急報告【重要】
やばいです仕様矛盾どうにもなりません時間もたりません(略
件名:Re:【アラート】緊急報告【重要】
スケジュールに間に合うよう仕様通り実装してください。 アラートなんて言われたって管理職になにが出来るわけでもなく・・・
せいぜい代わりに怒られることぐらいだな。 誰でもわかるような設計書まではいかなくともDBからどのテーブルのどのカラムから取ってくるくらいは書いてほしい… >>649
最低でもテーブル名とカラム名は必須だな。
いまどきは設計なんかしなくても下請けや派遣の常駐プログラマが
忖度しながら仕事してくれるから
SEは何もしなくてもいい、と思ってるような感じはするな。 残業代が1.5出る派遣会社いたときは基本給20万でももりもりお金が貯まっていったな
休日出勤すると2.0だった 結局自分のしたことを人が都合よくとってくれるかどうか
能力によって期待値も上下するから怒られ度は一緒
不条理だ デリヘルにもNGプレイというのが認められているが、ワイらにもNG現場認めてくれ
ワイは気になる木にはもう二度と行きたくない
逆によかったのは、ゼロ戦のメータ屋だな、あそこは良かった、なんか緩いし >>649
逆にソレがなくてどうして設計書として成立するのかわからんぞ
「なんかいい感じにデータ抽出してください」
「こうなったらいいなぁ・・って思いません?」
なんて書いてあるわけじゃぁ・・(過去の記憶がフラッシュバック) >>656
具体的にどこからどの値を取ってきて
どう計算したら良いですか?
って聞くと、なぜか怒り出す設計者様っているよな。 >>657
大丈夫だ
俺は具体的にどこからどの値を取ってきて
どう計算したら良いか指定されると
キレるプログラマだからだ
わかってんならテメーで作れよ!
( ‘д‘⊂彡☆))Д´) パーン 大昔の課題管理表やら
未公開の要件定義やら
誰も見ないような規約持ち出して
ねちねちいじめてやる >>657
家の設計図に、家の大きさ、ドアの大きさ、窓の大きさだのが書いてなかったら
大工さん文句言っても当然のことだと思うが、それがこと設計書になると抜けててもOK的な風潮あるよね >>660
大工さんは怒るけど、お前ら怒らないじゃん。
自業自得だよ。 ここに書いてある!っつって窓枠のカタログとモデルハウスの例と設計規約をもちだしてきて
ここから類推できなかった土方のせいにする
それがIT業界 >>661
切れたら、契約切られて営業が切れるだろうに。 いいなあ質問バカはヒマそうで。。。
うらやましくてウンコがでるよ。。。 マピオンのサイトに
フィッシングサイトが仕掛けられてるから注意な。
いきなりgoogleの何かの当選です!という
表示がされてびっくりした。
ソースをちょっとみたらコメントにgaqダミー入れとくとか
書いてあるけどそこかなあ?
めんどいから詳しく見る気はしないけど、
マピオンは使わないほうがいいな。
つかマピオンは中国の下請け企業にでも
作らせてるんだろう >>649
そんなわかりきったことを書く意味はない
ドメイン層のエンティティとデータベース層のスキーマの対応はほとんど自動で決まるのだから
設計書にはコンテキストマップやドメインモデルなどもっと重要な情報を書いてくれ 些末なことを特定するのにどれほど労力がかかると思ってるのか おれが作ったスマホとかのアプリは全く売れないけど
おれ自身はよく売れる。 計算機が相手という論理矛盾に最もシビアな世界なのに求められるスキルは忖度 尊宅ってどっからでてきた言葉なんだ
40年ぐらい生きてきてまじで最近はじめて聞いたんだけど
日本建国時にいろいろ文化的に言葉に仕込みをした連中がいるらしいので気になってる
中国語で変な意味だったりしないだろうな そりゃあ、能無しなんだから忖度で勝負するしかねーやな。
ゴマすりとか酒づきあいとか。 >>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/ おれの世代だと、
1.外部設計 (現在の要件定義+基本設計)
2.内部設計 (現在なくなってる!?)
3.詳細設計 プログラムの設計書
となっていた。
だが経験の豊かなプログラマが作成していた内部設計書というものが、
90年代中ごろから無くなってしまった。
なじぇ? >>707
自分は設計書にどのテーブルのどのカラムからデータ取ってこればいいか書かれてなくて困ってて
>>679だとそれが自動で決まるってあるからなにか見分けつける方法あるのかな?って思ったんよ
今の現場の画面設計書だと同じ表記で違うカラムから取ってくるってことがあったから >>708
JavaやC#やHTMLの表現力も生産性もBasicやCobolにくらべてはんぱないから
あんまりいらなくなったのもある
おれが思うに、詳細設計書を詳細に書きすぎると
製造と設計を別人が行うとき、
作業者が満足度を著しく下げる上に
作業者が考えて判断するということをしなくなってしまう
細かくかくなら達成すべきことを
内部の設計がかわってもいいように細かくかいておくべきだ ■ このスレッドは過去ログ倉庫に格納されています