プログラマの雑談部屋 ★26
■ このスレッドは過去ログ倉庫に格納されています
システムエラー吐いてもOKなところいくらでもあるしな >>360
そいつアスペか反日のキチガイだろうから、
別の人に交代させたら？ 今の現場凄い嫌だわ
設計がこのくらいコーダーで考えろやみたいな感じで仕事を丸投げする上に、出来上がってきた物に文句ばっかり言ってる
完全に上下関係が出来てて、コーダーを労働力としか見てない
一緒にやるって意識がまったくなくて奴隷かよって思う
気分悪いわ コーダーがアルゴリズム考えるのかw
そりゃあ効率悪いなw >>360
仕様通りに動いてれば問題ないという認識こそグローバルスタンダード >>365
for(false){
そのくらい自分で考えろ
なんでこんな仕様にしたんだ
}
は業界のデファクトスタンダード >>366
コーダは要件定義からに決まってるだろバカか そんなん自分で考えろ
なんでこんな仕様にしたんだ
使えない派遣だチェンジ
これで成り立ってるのがIT土方業界 >>365
一切忖度するな
「こうですかね？（全く違う）」
ってメール出しまくれ >>371
堂々と聞け
ccにできるだけ偉い人付けて
メール出せ >>365
コーダーなんて奴隷だし、使い物にならなかったら切り捨てて別の入れるだけ。
奴隷かよって思う、じゃなくて奴隷だよ。何言ってんの。 >>373
コーダーのクセに何わけわからん事言ってんの？
てかなんでそんな仕様にするんだよw >>360
社内の人間なら教育
社外の人間なら作業マニュアル作って
それでも役立たずなら交換 >>375
だから聞けよ
メールで
その際にccに偉い奴付けてくだんねーことほざけないようにしろ >>378
それそれ
そーゆーくだんねー返しは許さない
回答もらえるまで自社で作業あるからねｗ（ないけど） 詳細設計書は作らなくてもいいよね（社長部長先輩同期）
って意見に必要ですって答えたら
君は詳細設計書ないとプログラム作れないの？
って言われたことあるんだけど
プロジェクトの要員に追加されたり自分が作ってないプログラムの修正やらされる事になった場合って普通はどうしたらいいの？
webサイトとかwindowsプログラムをvisualstudio使って.netで開発がメインの会社です 作業をするうえで分からないことをリーダーか分かる人に質問すればいいんじゃない 基本設計の副次資料として詳細設計があるんだから、省略しても問題ないはず。
ただ、QAとして詳細設計が欲しいとか非エンジニア用の資料として必須なら日本語で作らなきゃいけない。
・基本設計にI/Oがない
・可読性の悪いソース
・コメント、docなし
・ステップ数を圧縮する要件がある
などエンジニアに不利な話があるときだけエンジニア向けの詳細設計があればいいんじゃね。
普段から子供でもわかるような簡単で整理されたスコープの読みやすいコーディングが出来るかが技量だと思うね。 C#でいちいちコード書くやつって、ネイティブコードを直に書けない池沼だよね ここの人たちは賢すぎたりワンラインナーで書くから詳細が必要なんだよ。 大丈夫って言ったから確認しませんでした
みたいな話でしょ？
問題が起きた時に収集がつかなくなるリスクをどう捉えるか
あと作りっぱなしの売り切りなら問題ないけど、仕様変更とかあったら分析コストが実費になるリスクもあるな 正確でエレガントな詳細設計: 必要
日本で一般的な私大文系の書いた詳細設計: 足を引っ張るだけのゴミ そうやって学歴とかでマウント取り始める奴がいるから話が進まないんだよなぁ プログラマはドロップアウトしたゴミが30歳まで食いつなぐための仕事
30超えたら大体精神病んで生活保護
もしくは自殺 いまの30代は高卒も大卒も就職氷河期だったからろくな経歴積めてない。
経歴がまともな30代は貴重だから適当にちやほやして使い倒したほうがいい。 仕様がなくても忖度してコードを書くことを要求されるのが
日本のプログラマ 要求仕様書からの機能一覧の抽出ですべての勝負は決まっている 機能一覧漏れてるのにオブジェクト指向だのインターフェースだのウンコクラスだの拡張性だの汎用性だの意味ねぇんだよ
お前はすでに
死んでいるんだ
友達なーんーだー >>396
わかってねえなぁ
仕様がスカスカで間違いだらけだから変更に強いオブジェクト指向を使うんだよ
完璧な仕様書なんて存在しないって当たり前の現実を素直に受け容れろ >>397
いやいや
要件定義からやってるなら
お前が頑張れよ 偉そうな元請けのやつらにこっちの手取りを教えてやると
「え！？それだけしか貰ってないの・・・」みたいな反応して対応が優しくなるからオススメ >>400
仕様変更に強い代わりに
バグを直すのが難しくなる。 >>400
変更に強いんじゃないよ。ラッピングが得意なだけだよ。 >>396
オブジェクトができてるなら機能の追加とかすぐだろ >>401
だよなぁ
俺もCの時代から変更に弱いコードってのがわからないからいまいちピンとこないんだよな
何がいいんだろオブジェクト指向って >>360
システムエラーが出るという設計なら問題ないだろう
未定義なら例外シナリオの設計漏れだろう >>407
例えば機能追加
ドメイン内のオブジェクトが揃ってればその組み合わせで大抵実現できるだろ
まあ比較対象によるけどな
手続き型のみでもデータ構造をしっかり設計してればそんなに変わらない
けどそれってオブジェクト指向プログラミングでないだけでオブジェクト指向設計だよね >>402
バグ治すのも簡単になるよ
特定が楽になる
修正もしやすい
テストも楽ちん >>409
はぁ？
必要な機能（もちろん処理も）は変わらないはずなのにどっから湧いてくんのそれ？ そもそも大体のバグは見つけるのは難しいけど直すのは簡単だからな
オブジェクト指向関係あるんかそれ？ >>414
良いオブジェクト指向のプログラムは一つのクラスが一つの関心ごとに、
逆に一つの関心ごとが一つのクラスに紐付いてるんだよ
だからバグの症状から即座に問題の候補はあれとこれだな、それらと紐付いてるクラスはあれとこれだな
といった具合に障害点の候補がすぐに見つかる オブジェクト指向はユニットテストと相性が良い
障害データログからユニットテストを失敗させるテストケースを簡単に追加できる
テストケースを追加できれば自動的に問題点が浮かび上がり、そのテストケースを通すと自然とバグが解消される
場合によってはデバッグで障害を特定する必要すらなくなってしまう >>416-417
何言ってるのかさっぱりわからない
こんなくだらないこと
今までやってきたのか？ オブジェクト指向なんて採用したら教育コストが跳ね上がるよ！！
VBで関数使うだけで「わかりにくい！！」って怒られるし！
「全部１つに収まってるほうがわかりやすいよね」っていう業界だよ！！！ >>420
データベース系はハゲてるイメージ
ネットワーク系は長髪
プログラマは生えてるけど洗ってなくて汚い どんなに勉強しても大学入試程度の問題も解けない人がたくさんいる
それってつまり個人の理解力には限界があるってことだよね
オブジェクト指向もそれと同じで理解できるラインってのがどこかにあるんだよ
みんながみんな理解できるわけじゃない
こればかりは仕方がないことと諦めるしかない
申し訳ないけどわかる人だけで楽をさせてもらおう 自分１人でやるならオブジェクト指向が楽
集団作業だとオブジェクト指向っていってもVB風が最適解だと思うわ
WEB系フレームワーク風といってもいいけどさ 学生の頃からプログラミングばかりしてた層と
３０才超えてからプログラミングをスタートした層では
やっぱ超えられない壁はあると思うんだよ
現場で教える人なんて要するに
プログラミングが出来ないからマネージャーになったような人ばかり 僭越ながらここまでの意見をまとめると
オブジェクト指向信者は学生の頃から筋金入りのハゲ >>411
>>396で機能漏れってのが発端だから機能は増えるんだろ ひろゆきぐらいの世代のプログラマーだと
小学生の頃からBASICとかやってたんだよな
あの世代のベテランエンジニアは優秀な人が多い >>424
まぁそれをオブラートに包むと、センスがある、無い、と言うんだけどね。 >>430
そうかなぁ
あの世代はスタティックおじさん山盛りだろw
まあひろゆきは私大バブル時代の中央大学だから頭は良いと思うよ
今のプログラマーであのレベルの学歴ならエリート >>425
開発手法にルールを設けて名前をつけるのは
自分への制約もあるけど
チームで共有するため
だから一人ならなんだっていいし名前もいらない
デザインパターンみたいなもん 知識経験が豊富だと応用が効くよな
lispとか仕事で使ったことないけど
様々なことの理解を助けてる むしろひろゆきは実務経験の豊富さに注目するべきでは バカなら2ちゃんねる作れないだろ
当時の貧弱なインフラ環境で良くこんなもの作ったと思うわ オブジェクト指向が理解できない人もいれば、
ツール補助もなしに秘伝のタレをさらっと読み切る化け物までいるから、
自分がやりやすい方法と周りとの協調の適当な塩梅でいいんじゃないですかね 当時は掲示板作るだけでも大変だったもんね
今みたいにアマチュアでもDB当たり前って時代じゃなかったし 客観的な指標なんてない。
個人としてはこれは出来るこれは出来ないの判断ができるあればいい。
管理する側としてはあいつはこれならここまでって判断が出来ればいい。
才能がとか言うのは、個人を見るのを拒否してるだけだろ。
よく才能がとか言う人がいるけど、そう言う人からよく聞くのは自分が使いやすい人を才能がとか言って、潰れるまで評価を投げ出してるってパターンが多い。 オブジェクト指向は相変わらずメリットの説明がないな
お金が儲かる仕組みにちっともオブジェクト指向が絡まないじゃん
見積り作成したときに利益なんて決まってるのに
設計段階でなんか差なんかつかねーよばぁーか
自分の貢献度が明らかに低いゴミが設計とか熱く語ってると可哀想になってくるな ・メーカーがライブラリ作るのに都合がいい
・オーダーベースの業務システムで一回完成したあと業務フローを一周消化したあとの改修がやりやすい
俺が感じてるのはまずこの二点。
そこじゃないと思う人もいると思うけどね。 見積もりしたときに決まるのは売り上げ
設計、製造段階で決まるのは仕入れの価格だ
利益考えなくてどうするよ >>442
引いたスケジュール守ってさえいれば
どう働いてもかまわんよ
早く終わってもピッタリでも会社の利益は変わらんけどね
まあ、プロなら終わらせるのが当然だよね >>443
いや、仕事量じゃなくて仕事の価値を高めてより多い金稼ぐのが企業と会社員の仕事だろw
一時間仕事してその分のお金が同じなら誰も一ヶ月で辞めちゃうよw >>445
早く終わったなら他の人間のも手伝うでござるよ 人月の神話って古典だよね。
最近だと秋にやった「ドリーム」って映画で60年代に同じ作業でもと賃金待遇交渉しまくったアメリカの事例を面白おかしく扱った映画がやってたよ。 >>448
それやって賃金上がらないなら仕事やってる意味ないじゃん >>450
そこだろ。
営業に金を決める仕事投げたら何も変わらない。
自分の金の根拠を他人に任せてどうするのって話。 >>440
儲かるのは今まで誰もやらなかった所で多くは処理性能の問題があるからな
オブジェクト指向は性能の改善はしやすいが最高性能は基本捨ててる
コスト的には初期投資多くして保守費を減らしやすい開発を早くしやすい だからさ、作業の大小を説明してこういうのが必要でこれ実現すればこうなるんだから金くださいって主張するのがエンジニアでしょ。
できないの？しないの？ 予算は決まってる
この(全ての)機能は必ず必要だ
マのサービス残業で自分が楽して利益あげようとする無能SEまたはクライアント
一部のマがマージン取りすぎるせいもあるかもしんない
私は一貫性のある見積もり出すけど >>457
営業が話つけてんじゃん
お前らは作成に必要な工数を出せばいいんだよ 営業が決めてきた工数
エンジニアが算出した工数
実際にかかった工数
それぞれどういう相関関係があるの？
営業工数 − 実工数 ＝ 利益 だよね？
エンジニアが工程管理する意味あんの？ ■ このスレッドは過去ログ倉庫に格納されています
