プログラマの雑談部屋 ★37
レス数が950を超えています。1000を超えると書き込みができなくなります。
プログラマは
こちらで雑談してください。
ユーザ、SEが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。
※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/ >>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
そりゃ全部オブジェクトだったら使う側もオブジェクトだしどれかの中身になるのはしょうがないだろ >>898
フレームワークのソースコードいちいち追ってるのかい? オブジェクツ嗜好を勘違いしてるチンパンが多いから教えてやるけど
オブジェクツ嗜好って例えるなら”無駄”を少なくして最適化してるようなもんだから
”正しく”オブジェクツ嗜好された設計で使う側も”同レベル”の知識があって初めて工数を削減できる
現実はここで喚いてるようななんちゃって指向のチンパンとなんちゃって設計する奴とド新人のコンボで
コボル顔負けのソースより遥かに生産性と保守性が悪い凶悪なシステムが出来上がってるのほとんど 言ってる内容があまりに主観的で独りよがりなせいで
前のやつと同一人物にしかみえん 例えばC#でのテキストボックス的なものもオブジェクト指向で作られてるってことなの?
中身は知らんがプロパティに値を入れればいろんな振る舞いをするわけだし >>904
オブジェクト指向じゃなかったらなんだというんだ? ジャップ島に産まれたら、このいい加減な精神論に毒されてオブジェクト指向型言語なんて使えなくなるわな
アメリカに産まれたかった フェルディナント・ブラウンと菩提達磨はどっちの方が頭が良いですか? >>895
それはそれでいいんだよ
メソッド名とドキュメントコメントでわかるから
重要なポイントは然るべき一箇所にそれがあるって容易に見つけられるということな
注文クラスに合計注文金額が定義されてること
これがポイント
設計書だとこれがどこにあるかわからんし重複してることもある 注文情報1件分でクラスになっててそれだけってケースが多いようだ。 オブジェクト指向なんて、やりたくても出来ないんだな。
担当者が途中で辞めることが多いもんだから。 そう、人件費を安く抑えるために、こういうバカでも出来る手法を
考えなくちゃいけないわけだが、オブジェクト指向はそういう点では
まったくダメ。 無になってもう二度と有になりたくない。
これが最大の夢。 バカでもメンテナンスできるからオブジェクト指向は便利なんだよ
無茶苦茶なスパゲティと化したトランザクションスクリプトはメンテナンスのために高度な情報処理能力を有した頭脳が必要
バカにはメンテナンスできない ブロックチェーン開発エンジニアは、頑張れば年収3億円以上も夢ではないですか? 【貧困】3億円以下低生涯所得者は辞めろ【非婚】
☆不利益で迷惑だから料金増やすか生産減らせ☆
時間外労働違反して離職率上げるな!
料金以上に生産して利益率下げるな!
偽装請負多重派遣業界SEは3億円以下の低生涯収入
[NTTデータの例]
設立年月日
1988年5月23日
平均年齢
38.0歳
平均年収
8,120千円
https://m.finance.yahoo.co.jp/stock/fundamental?code=9613.T よくわかってないやつが専門用語使ってそれに合わせる新卒pgの図に見えた そこそこの技術持ってるやつってこのスレにいるのか
いたらイライラしっぱなしだろ
それか寛大なんだろうな あのね、寛大かつ寛容でなければ
プログラマもPMもPLもSEもできないよ。
なので若い奴らに何言われても平気な顔してます。
ちょっと腹立つことありますけどね。
怒りませんよ。 スペースプレーンっていつになったら実用化されるの? なんの仕事だろうが、
大声で怒鳴るヤツは無能なヤツだからな。 閻魔大王とエウクレイデスはどっちの方が凄いですか? >>926
そのとおりですな。
無能な人は怒鳴るだけ。
できる人ほど怒らないで冷静に話をしてくれる。 まあ有能だろが卑屈、陰険、後ろ向き、怒鳴る、そういったやつと一緒に仕事したくない イギリス軍の名将ウィリアム・スリムは日本兵を酷評している。
日本兵はどんな命令でも疑わずに服従する。
「ビルマでの出来事だが、イギリス軍が北岸に待ち受けるイラワジ川を日本兵が山から出てきて粛々と川に入った。全く無意味な死だった。」とスリムは回想する。
「日本兵を理解するには、彼らを人間、いや動物とさえ思ってはいけない、インドで見かける”兵隊アリ”なのだ」と 新人が100個くらいグローバル変数作って状態管理してる
若者の頭は柔らかいな
表情は消えてるけど >>924
おまえは違うだろうけど、このスレってたまにベテランっぽい人いるよな この職業は他人の目に見えないから本当理解されない
そりゃ性格も捻くれるわ オブジェクト指向がバカでもメンテできるだと?
プログラマじゃないのがバレバレ
オブジェクト指向も全く理解していない
口先だけの馬鹿
ああ、いやなものみた
塩撒いとこ >>929
暗い奴より明るいやつのほうがやだ
同じノリを強要してくると目眩する
さらに暗い奴を見下すタイプだと最悪 >>939
人を見下すようなやつは論外
寡黙なだけならいいけど
ネガティブなことばっかり言うやつは不快じゃない? 生産性落ちてきた
何も考えずに邁進してたらすぐなのに ナイスミドルになる為には、手取りは50万は無いとダメだろうな。 >>940
この仕事って楽観論者が多すぎると思う
ネガティヴからスタートする人材は必要だよ
沢山いたらうざいけど ネガティヴからスタートしたら、この業界なんて続かないよ。
ウヌボレ屋なぐらいがちょうどいいんだ。 できる人間はツイッターで本名で活動してる
ここにいるのはゴミカスだけ 執行したんか
なんか隠したいニュースでもあったん? 昔ポジティブ屋に仕事任せたら、簡単と思ったけどやっぱり出来ませんアハハと笑って言ってきてキレそうになった
ちなみに各国語対応の多機能カレンダーjsライブラリ
APIのコールバックでDBと連携させて世界各国の言語と表記法と休日でレスポンシブ表示するヤツを工数50時間で作るという案件 日本が負けたから、なにかオメデテー記事でも、とか思ったのだろう。 >>950
ちなみに今まで楽勝と言ってたのにラスト8時間の時点で急に白旗あげてきて、周りが大慌て >>949
元号末だからな。今元号の汚れ、今元号のうちにの精神
>>950
>世界各国の言語と表記法
ヒジュラ、ヒンドー、ユダヤだのってその辺ってことか レス数が950を超えています。1000を超えると書き込みができなくなります。