プログラマの雑談部屋 ★26
■ このスレッドは過去ログ倉庫に格納されています
要求仕様書からの機能一覧の抽出ですべての勝負は決まっている 機能一覧漏れてるのにオブジェクト指向だのインターフェースだのウンコクラスだの拡張性だの汎用性だの意味ねぇんだよ
お前はすでに
死んでいるんだ
友達なーんーだー >>396
わかってねえなぁ
仕様がスカスカで間違いだらけだから変更に強いオブジェクト指向を使うんだよ
完璧な仕様書なんて存在しないって当たり前の現実を素直に受け容れろ >>397
いやいや
要件定義からやってるなら
お前が頑張れよ 偉そうな元請けのやつらにこっちの手取りを教えてやると
「え!?それだけしか貰ってないの・・・」みたいな反応して対応が優しくなるからオススメ >>400
仕様変更に強い代わりに
バグを直すのが難しくなる。 >>400
変更に強いんじゃないよ。ラッピングが得意なだけだよ。 >>396
オブジェクトができてるなら機能の追加とかすぐだろ >>401
だよなぁ
俺もCの時代から変更に弱いコードってのがわからないからいまいちピンとこないんだよな
何がいいんだろオブジェクト指向って >>360
システムエラーが出るという設計なら問題ないだろう
未定義なら例外シナリオの設計漏れだろう >>407
例えば機能追加
ドメイン内のオブジェクトが揃ってればその組み合わせで大抵実現できるだろ
まあ比較対象によるけどな
手続き型のみでもデータ構造をしっかり設計してればそんなに変わらない
けどそれってオブジェクト指向プログラミングでないだけでオブジェクト指向設計だよね >>402
バグ治すのも簡単になるよ
特定が楽になる
修正もしやすい
テストも楽ちん >>409
はぁ?
必要な機能(もちろん処理も)は変わらないはずなのにどっから湧いてくんのそれ? そもそも大体のバグは見つけるのは難しいけど直すのは簡単だからな
オブジェクト指向関係あるんかそれ? >>414
良いオブジェクト指向のプログラムは一つのクラスが一つの関心ごとに、
逆に一つの関心ごとが一つのクラスに紐付いてるんだよ
だからバグの症状から即座に問題の候補はあれとこれだな、それらと紐付いてるクラスはあれとこれだな
といった具合に障害点の候補がすぐに見つかる オブジェクト指向はユニットテストと相性が良い
障害データログからユニットテストを失敗させるテストケースを簡単に追加できる
テストケースを追加できれば自動的に問題点が浮かび上がり、そのテストケースを通すと自然とバグが解消される
場合によってはデバッグで障害を特定する必要すらなくなってしまう >>416-417
何言ってるのかさっぱりわからない
こんなくだらないこと
今までやってきたのか? オブジェクト指向なんて採用したら教育コストが跳ね上がるよ!!
VBで関数使うだけで「わかりにくい!!」って怒られるし!
「全部1つに収まってるほうがわかりやすいよね」っていう業界だよ!!! >>420
データベース系はハゲてるイメージ
ネットワーク系は長髪
プログラマは生えてるけど洗ってなくて汚い どんなに勉強しても大学入試程度の問題も解けない人がたくさんいる
それってつまり個人の理解力には限界があるってことだよね
オブジェクト指向もそれと同じで理解できるラインってのがどこかにあるんだよ
みんながみんな理解できるわけじゃない
こればかりは仕方がないことと諦めるしかない
申し訳ないけどわかる人だけで楽をさせてもらおう 自分1人でやるならオブジェクト指向が楽
集団作業だとオブジェクト指向っていってもVB風が最適解だと思うわ
WEB系フレームワーク風といってもいいけどさ 学生の頃からプログラミングばかりしてた層と
30才超えてからプログラミングをスタートした層では
やっぱ超えられない壁はあると思うんだよ
現場で教える人なんて要するに
プログラミングが出来ないからマネージャーになったような人ばかり 僭越ながらここまでの意見をまとめると
オブジェクト指向信者は学生の頃から筋金入りのハゲ >>411
>>396で機能漏れってのが発端だから機能は増えるんだろ ひろゆきぐらいの世代のプログラマーだと
小学生の頃からBASICとかやってたんだよな
あの世代のベテランエンジニアは優秀な人が多い >>424
まぁそれをオブラートに包むと、センスがある、無い、と言うんだけどね。 >>430
そうかなぁ
あの世代はスタティックおじさん山盛りだろw
まあひろゆきは私大バブル時代の中央大学だから頭は良いと思うよ
今のプログラマーであのレベルの学歴ならエリート >>425
開発手法にルールを設けて名前をつけるのは
自分への制約もあるけど
チームで共有するため
だから一人ならなんだっていいし名前もいらない
デザインパターンみたいなもん 知識経験が豊富だと応用が効くよな
lispとか仕事で使ったことないけど
様々なことの理解を助けてる むしろひろゆきは実務経験の豊富さに注目するべきでは バカなら2ちゃんねる作れないだろ
当時の貧弱なインフラ環境で良くこんなもの作ったと思うわ オブジェクト指向が理解できない人もいれば、
ツール補助もなしに秘伝のタレをさらっと読み切る化け物までいるから、
自分がやりやすい方法と周りとの協調の適当な塩梅でいいんじゃないですかね 当時は掲示板作るだけでも大変だったもんね
今みたいにアマチュアでもDB当たり前って時代じゃなかったし 客観的な指標なんてない。
個人としてはこれは出来るこれは出来ないの判断ができるあればいい。
管理する側としてはあいつはこれならここまでって判断が出来ればいい。
才能がとか言うのは、個人を見るのを拒否してるだけだろ。
よく才能がとか言う人がいるけど、そう言う人からよく聞くのは自分が使いやすい人を才能がとか言って、潰れるまで評価を投げ出してるってパターンが多い。 オブジェクト指向は相変わらずメリットの説明がないな
お金が儲かる仕組みにちっともオブジェクト指向が絡まないじゃん
見積り作成したときに利益なんて決まってるのに
設計段階でなんか差なんかつかねーよばぁーか
自分の貢献度が明らかに低いゴミが設計とか熱く語ってると可哀想になってくるな ・メーカーがライブラリ作るのに都合がいい
・オーダーベースの業務システムで一回完成したあと業務フローを一周消化したあとの改修がやりやすい
俺が感じてるのはまずこの二点。
そこじゃないと思う人もいると思うけどね。 見積もりしたときに決まるのは売り上げ
設計、製造段階で決まるのは仕入れの価格だ
利益考えなくてどうするよ >>442
引いたスケジュール守ってさえいれば
どう働いてもかまわんよ
早く終わってもピッタリでも会社の利益は変わらんけどね
まあ、プロなら終わらせるのが当然だよね >>443
いや、仕事量じゃなくて仕事の価値を高めてより多い金稼ぐのが企業と会社員の仕事だろw
一時間仕事してその分のお金が同じなら誰も一ヶ月で辞めちゃうよw >>445
早く終わったなら他の人間のも手伝うでござるよ 人月の神話って古典だよね。
最近だと秋にやった「ドリーム」って映画で60年代に同じ作業でもと賃金待遇交渉しまくったアメリカの事例を面白おかしく扱った映画がやってたよ。 >>448
それやって賃金上がらないなら仕事やってる意味ないじゃん >>450
そこだろ。
営業に金を決める仕事投げたら何も変わらない。
自分の金の根拠を他人に任せてどうするのって話。 >>440
儲かるのは今まで誰もやらなかった所で多くは処理性能の問題があるからな
オブジェクト指向は性能の改善はしやすいが最高性能は基本捨ててる
コスト的には初期投資多くして保守費を減らしやすい開発を早くしやすい だからさ、作業の大小を説明してこういうのが必要でこれ実現すればこうなるんだから金くださいって主張するのがエンジニアでしょ。
できないの?しないの? 予算は決まってる
この(全ての)機能は必ず必要だ
マのサービス残業で自分が楽して利益あげようとする無能SEまたはクライアント
一部のマがマージン取りすぎるせいもあるかもしんない
私は一貫性のある見積もり出すけど >>457
営業が話つけてんじゃん
お前らは作成に必要な工数を出せばいいんだよ 営業が決めてきた工数
エンジニアが算出した工数
実際にかかった工数
それぞれどういう相関関係があるの?
営業工数 − 実工数 = 利益 だよね?
エンジニアが工程管理する意味あんの? 金の話を顧客としたり、成果の証明ができないのに、給料の不満を言われてもな、ってやつだよね
嫌ならフリーランスでもやってろと 数字隠してんのに証明も何もないでしょ
情報の不均衡を利用して一方的な支配をする古典的な手法 >>460
エンジニアじゃないと工程管理なんてできないよ。
エンジニアの視点を持った人といえばなんでもいいとは言えるけどね。 >>460
営業が正確な工数出せるわけないだろ
契約の金額-人件費=利益。
見積り工数と実工数はどのくらい妥当だったか程度の意味しかないぞ つーか金額はエンジニアじゃない人が決めるので客観的に
この金額と思える作業すりゃいいだけとか思う人がこんなにいるとは思わなかった。 >>451
でもそれやって会社に利益が出せないなら
オブジェクト指向も貢献度はゼロだね オブジェクト指向が嫌われてるのはなんでだろう。
普通にクラスありきの実装でもの作ってるなら同じ流儀でやりゃいいじゃん。 OOPの話も値付けの話も結局愚痴以上の話はないんだろw >>469
だからさっきわかりやすく説明してやったじゃん
利益を決めてるのは見積りであって
オブジェクト指向が例え工数を縮めるモノであったとしてもそれは利益の計算式に絡まないものであると
だからこんなもんに力を入れてはいけんよ >>467
理解できないのと
人によって解釈がけっこう違うから
それなのにJavaとかオブジェクト指向を前提とした言語でやるから困る
本来、オブジェクト指向開発手法という分析設計からOOを取り入れなければならない
しかし我流設計でOOプログラムだけしろと言うから問題にしかならない >>455
並列処理を安全に行えるからオブジェクト指向の方が速くなるよ >>467
なぜって馬鹿には理解ができず
日本は馬鹿が多数派だからだよ コピペ乱用トランザクションスクリプト前提で工数見積もって金をぼったくる
オブジェクト指向で楽に製造して余った時間は悠々自適の休憩タイム
会社は差額を丸儲けして従業員はストレスレス
オブジェクト指向は最高だ なんでISPの資格名はダサいんだろう
情報処理安全確保支援士とか頭悪そう ITパスポートも名前しょぼ過ぎてビギナーも取得する気が起きないだろ この業界の人手不足煽って供給過多にしてから買い叩く手法はエンドレスで続くのかな
今の求人倍率見て参入する人多過ぎだわ
近々買い叩きに転じそう 【搾取】年収1,000万円以下はパートでやれ【対策】
☆料金増やすか生産減らして対策しろ☆
相場下がって迷惑だから年収1,000万円以下はパートでやれよ!
アメリカのSEは多重派遣なしで1,000万円以上高収入
日本のSEは多重派遣ありで1,000万円以下の低収入
【アメリカ】
スーパープログラマ
時給10万円だったり、ストックオプションで数億〜数十億円稼ぎだす
Javaフレームワーク
〜3600万円
PHP
〜2400万円
COBOL
〜1700万円
技術サポート
〜1200万円
年収中央値:1175万円(アメリカ労働統計局調査、サンプルは111万人)
70歳でも仕事があり、年収は下がらない数年単位で転職する(一つの
会社に長くいるのは危険)管理系の職種は雇用が不安定で、報酬も高くない。
【日本】
平均年収:430万円(情報処理推進機構調査)
Web/ゲーム業界(昔ほど報酬は高くない)以外は人月単位のため、報酬には上限あり年功賃金を採用する企業では20代後半までの給料は一
部の例外を除き低い間接雇用が基本(大手のSIerでも客先常駐派遣が少なくない)40歳以降になるとリストラ候補となり、一旦リストラされ
ると低賃金職か、長期間無職となる。大企業の場合は管理職トラックに進むためコーディングはしなくなり、プログラミング経験が昔あっても
35歳以降の転職は難しい。転職回数が3回超えるだけで大手には書類で落とす。
アメリカは多重派遣搾取しない
http://getlife.hateblo.jp/entry/2014/06/19/034109 >>481
ストでも何でもやって法規制が入らない限り変わらんだろ。
問題はプロパー様がストしても下請けや非正規がいればプロパー様いなくても数か月くらいは
仕事回せちゃって困らないからスト出来ないところだろうな。 >>481
心配しなくても今の10代、20代はプログラマーなんかじゃなくてユーチューバー目指してるから大丈夫 27億円の賠償巡り新たなIT裁判始まる
http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/00014/
文化シヤッターが開発やり直しを提案
アルミ建材の文化シヤッターが、販売管理システムの開発が頓挫した責任は
日本IBMにあるとして、約27億4000万円の損害賠償を求めて提訴していたことが
明らかになった。 クラスのメンバ変数ってクラスのメソッドから見た場合のグローバル変数だよね? >>488
そうだね
実はあんまり使わない方がいいプログラムが組める メンバ変数無しで状態を保存する方法はあるでしょうか >>491
なるべく使うなって話だろ
昔の構造体と関数でやってた頃のスタイルで組めば無駄な生存期間が多いことに気づく メンバー変数が無いなら、グローバル変数を使えばいいじゃない。 ■ このスレッドは過去ログ倉庫に格納されています