プログラマの雑談部屋 ★37
レス数が900を超えています。1000を超えると表示できなくなるよ。
プログラマは
こちらで雑談してください。
ユーザ、SEが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。
※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/ >>800
view model - service input model
view model - service output model
プロパティマッピングを定義
おわり >>790
ゲーム屋崩れがだいたいそんな感じで作りやがる。
あと、ホントに適性のない奴。 今のプロジェクトすごい
新規開発で新規参入メンバーなのに既存設計書をまねて設計書を作らせて
その基本、詳細設計書のレビューがたった1人で各1時間だけ
コーディング、単体テスト仕様書、テスト結果レビュー無し、
結合テストもレビュー無し、システムテストも無し
結合テストのバグが毎日増え続ける現状で
品質を担保すると豪語するPM 切れる手札がババしかない状態で
調整業務やらされるの疲れた
何が頭使って交渉しろだよ...
飛び込んでいいよね、パトラッシュ 正直に言う。
俺はベルギーを応援した。
日本が嫌いなだけだからじゃない。
安倍を利することが嫌だったからだ。
安倍がサッカーを政治利用し、メディアが愛国を鼓舞し、日本はすごいと騒ぐのを観たく無いだけだ。
早く自民党政権を退陣させて、多文化共生社会が訪れて、素直に日本チームを応援できる日が来て欲しい。 死んだらどうなるのでしょうか?
無になってもう二度と有にならないのでしょうか?
それとも死後の世界があるのでしょうか? >>807
死後の世界が無いことは誰も証明できない、が答え
お前は何も定義しないで質問ばかりだが、
質問は誰でもできる。
どんな馬鹿でもできることは質問だ
だからどんどん質問したまえ
君は自分の頭で考えることは不可能だ 超大型キャンピングカーを買って、日本中を旅したい。 超超大型バイブレーターを買って、日本女を犯したい。 >>790
最後はプログラマが全ての罪を背負って死ぬ
プログラマはIT業界のキリストなのです >>776
ほんそれ
何もしないリーダーいる時はなんとか回っていた業務がウルサイ奴が来て人が次々辞めて破綻気味だわ キッチリ要件定義決まって設計書作られてそれでも量が膨大で大変なことになってるのは
主に大企業の案件だな。
中小企業が仕事を請けると、そういうのを省略することで
コストダウンを図っている。 >>815
仕様書もインプットとアウトプット無いけどこれ直して
は良く言われる ソースを出して説明することがよくあるねぇ、中小は。
で、ディスプレイつつきながら「これをこうかえるんだ」みたいな。 >>803
新規開発なのに縁もゆかりも無い古い既存プロジェクトをベースに作って誕生した早々にメーカー保証切れたシステムは作った 大手の下請けとかでずっとやってきた者が
会社潰れたとかで派遣になって中小の自社開発などやったりすると
さぞや大変なんだろうな。
ゲーム上がりの者は、そういうののほうが得意なようだが。 コードを全く書かないから書けなくなって設計書に縋る大企業
コードを当たり前のように読み書きできる中小企業
このギャップをどうにかしないと日本のIT業界に未来はないんだろうな コードを当たり前のように読み書きできる奴を雇うと
後が怖いからねぇ。
中小企業だって、ホントはそんな奴は雇いたくないんだ。 >>817
説明あるだけ良心的
説明無しでここを直してと振られる方が多い >>822
そう、こういうことが起こるから、企業は出来るだけ
コードを当たり前のように読み書きできる奴など雇いたくない。
迂闊に雇ってそいつが辞めた直後とかなんだろうな。 コードの読み書きをできない大企業社員が書いた設計書はコード以上に読みにくい直しにくいゴミとなる
もう殆ど借金なんだよね 良い設計を設計書としてアウトプットしたものには価値がある
悪い設計を設計書としてアウトプットしたものはもはや技術的負債である
なくてもいいどころかマイナスなのだ 大企業の書く設計書とは
こんなにたくさん設計書を書いたんだから品質は保証されてると納得してください
というアピールのための材料でしかなく設計書が品質そのものに貢献することは稀である 多くの場合、設計書はエクセルで書かれるが
エクセルは静的解析も行ってくれなければ、リファクタリングツールもない
設計書を綺麗に整理するための基盤がないのだ
一回で良い設計書が書かれることはないし
設計書を良い状態にメンテナンスするには膨大な工数がかかる
よって、殆どのプロジェクトで設計書は低品質なまま放置され、製造やテストに尻拭いをさせる方式が採用される >エクセルは静的解析も行ってくれなければ
ひどい侮辱
存在意義全否定すんなし 誰もが閲覧、編集できる設計書のためのツールがないのもまた事実 >>827
細かすぎたり同じ内容を複数書いたりするからメンテナンスできないんだよ
常にシンプルを目指せばメンテナンスも割と楽 「全」を金額に換算すると、幾らぐらいになるのでしょうか? 宇宙船だけあっても、プレハブ住宅になるだけちゃうか? 有人宇宙船にも、車や船や飛行機などのように、運転免許みたいなのがあったら良いのになぁ・・・・・・。 >>835
開発しない人間にIDEインストールさせるの? >>835
ideで設計書開けたとしてどんなメリットがあるんだ 倒産してから派遣やってるんだけど
派遣会社によって単価がかなり違う
なじぇ? >>756
残業、休出してください(無料で)
これを上手に言える管理職は貴重な戦力 >>756
前倒しでっていう単語が何を意味してるかわかってないよな
「普段サボってんだからまじめにやったらもっと速くできるんだろ?」って暗に言ってる
外注に言うなら他の仕事との調整でなんとかしてって意味にもとれるが
100%時間を拘束してる場合(個人事業主で現場で9時〜6時拘束の違法フリーランス)は
労働力を無料で提供しろっていう脅迫だからな ITドカタの場合は「みんなが100メートル10秒切ったら納期に間に合う!」みたいな事を言ってくるわけだからね
どうすれば10秒切れるんですか?
夢みるPMだと現実は悪夢になる >>847
これ本気で理解してないやつ多いよな
同じ会社から同じ仕事が発注されたら同じ単価になると本気で思ってて
「あ、単価が違うのは途中でピンハネしてる会社の数の差ですよね」って
嬉々として言われたときは
「せやな」
としか言いようがなかったわ >>841
派遣に有利な資格はだいたい持ってる
凄すぎず、適度にハッタリがきき知名度もある
そんな資格は全て取得した プログラマーは会社によって、
太ってるか、顔が歪んでる人が多いのは何故ですか? 客先で仕様書を書いたら、後から参加してきた正社員にこのフォーマットに合わせろと後出しジャンケン
挙げ句罫線の書き方まで細かく指摘され作業が遅いと怒られて契約終了
非正規客先常駐は辛い >>857
仕様書をエクセルで書いたんだろ?
データにしておけば出力設定を変えるだけだったのになぁ はぁ
プロジェクトルームに隕石落ちてこねかな
物量戦しか戦略がないリーダーはもうやだ 契約終了になっても、スグに次に行けたんだろ?
それこそがIT技術者の最大の強み。 今派遣をやっているが、年齢は40半ばなのにどうも30半ばと勘違いされているようである。
色々教えてくれるが年齢知られると距離感がおかしくなりそうで中々カミングアウトできない。
意外とつらい。 今まで払ってきた自己犠牲の貴重な時間で
他に何が出来ただろうか >>829
ツール以前に設計書のフォーマットすら世界標準でも存在しないからな
最近は減ってきたけど、社内の別プロジェクトで設計書のフォーマットが違うとか当たり前だったりするからな 違くていいんだよ
対象のシステムそのものが千差万別なんだから同じものがそのまま通用すると思うほうがバカ
設計でもデザインパターンと同じでエッセンスを再利用して細かいとこは柔軟にアレンジするのが良いんだ
だから何年も同じ設計テンプレートを使うのだけは絶対にやめろ 銀の弾丸はない
設計も同じこと
ただそれだけのこと 最後は
どうせ設計書に書いたものとは
全く違うものが出きるのだから
設計書なんて適当でいい。
どうせ常に変化し続ける
客の神の声が仕様なのだからさ。 設計書を疎かにしてコードで説明する奴のことを
コーダーって言うらしいぞ。 >>871
ソースは設計書であり、設計書はソースなのだ コードで語るからコミュニケーション適当の奴いるよね 設計書だとどこに何があるかわかんねえんだよな
注文の合計注文金額の定義はどこだっけって探すと
別の大きなロジックの中に紛れ混んでたりSQL定義に埋め込まれていたり
ひどい時には画面へのマッピング定義・書式定義のなかにしれっと混ざってたりする
なぜこうなるかっていうと設計書を書くようなバカはオブジェクト指向を知らんトランザクションスクリプト人間だから注文をクラスとして定義するという発想がないんだわ
合計注文金額の定義の置き場そのものがないからその業務知識が行き場を失って変なところに隠されてしまう
コードは設計書であるという真理に到達した人間は合計注文金額の置き場となる注文クラスを書く
そして最小の労力でメソッドを1つ定義するんだ
decimal 合計注文金額 => 注文明細.Sum(d => d.注文金額);
然るべき場所に然るべき業務知識が置かれる
そしてそれは最も簡潔で誤解の余地がない文法で記述されている
これ以上にスマートな設計書は他に存在しないよ 読んでて頭がおかしくなる
ほとんど意味がない文章なのに自信がありすぎるせいか
事実に関する主張だけ抜き出して添削してみた
設計書だとどこに何があるかわかんねえんだよな
注文の合計注文金額の定義はどこだっけって探すと
別の大きなロジックの中に紛れ混んでたりSQL定義に埋め込まれていたり
ひどい時には画面へのマッピング定義・書式定義のなかにしれっと混ざってたりする
なぜこうなるかっていうと注文をクラスとして定義していないから
合計注文金額の定義の置き場そのものがないからその業務知識が行き場を失って変なところに隠されてしまう
コードは設計書だと合計注文金額の置き場となる注文クラスを書く
そしてメソッドを1つ定義するんだ
decimal 合計注文金額 => 注文明細.Sum(d => d.注文金額);
然るべき場所に然るべき業務知識が置かれる
そしてそれは最も簡潔で誤解の余地がない文法で記述されている
これ以上にスマートな設計書は他に存在しないよ
…理屈のつながりが独りよがりすぎる あとどこに何があるかわからないのはコードだろうがオブジェクト指向だろうが一緒のはず
合計注文金額の場所と定義を知るのに注文クラスという前提知識がいる分Excel用語集より劣っている
知ってても確実にそこにあるとわかるわけじゃない
お前がそれがそこにあるのがわかるのはコードが設計書だからじゃない
単におまえがつくったからだ 日本語で定義してみよう
合計注文金額:注文の注文金額の合計
ちょうかんたん
注文明細とか余分なものもないし
dとかdecimalとか環境依存や言語依存のわけのわからん概念も出てこない >>882
はぁ?
注文合計金額を書くのに注文クラス以上の場所があるかよ
てめーは注文合計金額を顧客リポジトリに定義すんのか?
それともCSV読み取りクラスか?
在庫一覧画面か?
スレッドキュークラスか?
ちげーだろ
注文に関するものはどう考えたって注文に定義すんのが正解だろーがよ
こんな当たり前のこともわからねえからオブジェクト指向を知らないトランザクションスクリプト人間ってのは嫌になるぜ
トランザクションスクリプト人間は宇宙の果てと果ての間をワープしながら死ぬまでパブリックプロパティいじってればいいんだよ >>883
うわっサイテーにわかりにくいな
なに?お前はそれ全注文の注文金額の合計値でも出そうとしてんの?
日本語ってよーこれだから困るぜ
曖昧すぎてイラつくんだよなー 標準化されていないオレオレの設計書だから外野が見たら分からんということにつながるわけで
そういうコミュニケーションコストを軽く見ているのが設計書イラネとかコードが設計書とかほざいている奴らなのよ >>885
当たり前といったな?
あたりまえ と
IT従事者のくせに
オブジェクト指向と業務を知ってる人間だけの当たり前と
全員に通じる日本語の当たり前の
どっちが優れてるかいうまでもあるまい >>887
おいおいシステム屋の共通言語はプログラミング言語だぞ?
会社ごとにどローカルな田舎っぺ方言丸だし設計書にコミュニケーションもクソもあるかよ >>888
当たり前だぜー
オブジェクト指向も業務も知らねー奴なんて現場にゃいねーからよ やっぱこうなるかー
設計書厨は習慣を引き継いだだけで考えない奴ばっかだから
こういう時にろくな反論もできねえんだ 優れてるとか劣ってるとかいうと妙にたじろいでる気がする
なんかわるいことした コードに書いてあるのは方法であって目的じゃない
設計書で乱数とか現在日時とかsinΘとか書かれてるものについて
ばきばきに最適化された実装をみせられて意図がわかるだろうか? だいたい殆どのオブジェクト指向は実装の隠蔽を理念にしてる
外側のインターフェースと達成すべきことをきっちり決めて
内部は好きに手を入れたり最適化したりすげ変えたり自在にできるのがオブジェクト指向の利点
実装をみせて定義とするなんて考え方とは真っ向から精神が反している ところで、現在、English板が誰でもスレッドを立てられる状態に
陥っております。プログラマー板の皆さんの出張所とか避難所を
English板に立てておく事をお勧めします。 オブジェクト指向ってそれを使う側が中身を気にしなくていいのが利点とか言うけど
大抵の改修案件はその中身を変更するのが大半な気がするんだが どうせブリッジパトゥーンも理解してない雑魚のくせに
オブジェクツガーオブジェクツガーって喚くなよなぁ
Java覚えたてのチンパンジーかよ >>898
そりゃ全部オブジェクトだったら使う側もオブジェクトだしどれかの中身になるのはしょうがないだろ レス数が900を超えています。1000を超えると表示できなくなるよ。