上流工程やりたくない [無断転載禁止]©2ch.net
>>81
いいやスカイツリーも俺が乗るわけじゃないのでシングルトンで作る 例えばスカイツリーを何十個も複製するならシングルトンではダメだが
1つなのでシングルトンの出番となる >>101
Object.cloneでコピーできますけど? そうさ〜 僕らは〜♪ 世界に一つだけのシングルトン〜♪
一つ一つ違うインスタントを持つ♪ 上流って整合性云々は二の次で、とりあえず判子もらう資料作ったら終わりやん
後の辻褄合わせは全部下流に丸投げして、スケジュール管理という名の下流の尻叩き
納期遅れようが、赤が出ようが、全部下流のせい
楽な商売だよ >>106
最近俺のまわりでは上流と下流は分かれてないかな?
少なくとも設計からテストまではセット >>107
そんな現場では働きたくないな
上流だけやっていたい >>108
多分多くの会社でここ分けるメリットねぇなって学習したんと違うかな?
設計だけだとあまりにも投げっぱなしのジャーマンを炸裂する奴多すぎ問題で >>107
どうせ犬小屋程度のものしか作ってないんだろ
だったらシングルトンで十分だ >>111
っていうか、そんなシームレスに際限なく馬鹿でかいプロジェクトあってたまるかよ
よっぽど担当者の脳みそ腐ってんだろ
まあ、実際に腐ってるケースもあったが
インターフェイス定義してプロジェクト分けろと >>112
プロジェクトを分けてたくさん犬小屋を作るつもりか シングルトンでは犬小屋しか作れないのだよ
ピラミッド状に組織を作ってやらないと大規模なものは作れない
スカイツリー作った人のほとんどは土木作業員
設計者はそれに比べればほんの僅か
大規模な作業は役割を分担して組織化することによってはじめて実現できる
誰もかれもが現場作業やればいいってもんじゃない
長妻なんとか元パワハラ大臣が手計算で年金計算してたようなもの
組織というものがなんたるかを知らない人間が上に立つとできることもできなくなる デザパタで馬鹿にできるのがシングルトンだけだから
シングルトンを集中攻撃してるのかな?
ネタバレされたらなんか間抜けだよねw >>115
シングルトンひいてはデザパタが攻撃されてると思うの?
自意識過剰じゃない?
どういう意味でシングルトンという言葉を使っているのか
頭を冷やして冷静に考えみなよ
ヒントはデザパタは役立たずのクソ シングルトンの一本槍で戦ってるのはデザパタさんの方じゃないか >>116
いや、シングルトン以外の話をしろよってことだよw
お前のことだ。シングルトンを一回忘れて
他のデザパタの話をしようか。 くらえ!ひっさつちぇいんおぶれすぽんしびりてぃいいい!!!とかやればいいじゃん
なに黙ってんの インタプリタとか業務で使うことまずないよな
アブストラクトファクトリもフレームワークとか作るのでない限り使わぬし
シングルトンも別にグローバル変数で間に合ってるし
結局使うのってコマンドパターンくらいかコマンドパターンも一般的過ぎて
もはやコマンドパターンと呼べる代物じゃない
ただのインターフェースだしファクトリはゴミ デザパタさんの応答がないとき使えるデザパタを募集します プロキシか?プロキシを挟んで誰か別の人間が応答すればいいのか
その間にデザパタさんの初期化を頑張ればパフォーマンス出るんじゃないか? >>115
デザパタをムリに適用しようとしたらオーバースペックというか
interface狂というか
「あるクラスは別のクラスに交換可能であるべきじゃい主義者」
になる印象はある
フレームワーク書いてるとか、JSRに従ったAPI書いてるとか
エライ人の怒声により2コのシステムを無理に共通化しようとしてるとか(X社は先日弊社が買収しますた)
そういう時でないとデザパタがフル稼働する状況は思い浮かばない
例えばコーヒー豆小売店用のBtoCサイトだとGoFのデザパタなんか1/10も使わんかも 特に意識しなくても気付いたらデザインパターン多用してる
というか必然の設計をするとあ、この形はよく見たらなんとかパターンだなってなる >>136
受けた仕事をそのまま外注に出すこと
打合せの会議すら参加しない 正社員になるとずっとプログラマでいるとこはできない悲劇 >>1
上流って早い話が、システムの設計ができるってことだろ?
なんの設計権もないプログラミングなんて面白くもクソもないだろ コーダーだって設計ができなきゃ
渡された設計書が適切であるかどうかも判断できないよ >>142
算数ドリルやってるだけで楽しいか?って話だろが 適切な設計がわかると低脳SEの書いたクソ設計に従って作業する苦痛に耐えられなくなる
コーダーは設計なんてわからないほうが幸せ >>1
まあ上流工程がゼロから価値を創出するところだしね
その分多様なスキルを求められて精神体力ともに凄くキツイ
やらなくていいのなら絶対やらない方がいい 価値を考えてるだけで
創出はしてないだろw
価値を考えるだけなら誰でもできるわけで コーディング下請けの上にいるのはSEちゃうで上級コーダーや 要求は自由にならないけど、
それを満たす仕様(アイデア)を自分で考えられる権利を持ってるのって上流だけじゃん
ものづくりで一番楽しいのってそこじゃない?
そのアイデアが最終的にどれだけ効果をもたらしたか?
この二つが無いところの仕事って何が楽しいの? >>150
hello worldが出力されたら楽しい
それがプログラマ 書いたとおりにプログラムが動く
プログラミングとは世界が自分の思い通りだと認識させる麻薬のようなもの >>150
他人の作った、しかも低品質すぎてめまいがするような設計に服従してコード書く仕事って、ほんと何が楽しいんだろうな? >>153
その思いがSEは的はずれだからな
顧客(=素人)が言ってることを伝えてるだけ 概ねこんなことがやりたいんだけど
ってのは客の要望で決まってて
上流がやるのなんて他で悪影響があるかないか目を皿のようにして調べるだけ
アホはその工程を飛ばすから下流での尻拭いが酷い
クリエイティブな箇所なんて欠片も存在しないので安心してほしい
そういうのがやりたければ日本を出ろ
日本のベンチャーという手もあるが契約が稚拙なので食い物にされるだけ
本気でクリエイティブな仕事がしたければ海を渡る必要がある >>158
勝手にレッテル貼ってるけど、低偏差値のおまえが思ってることをなんで他の頭のいい人が思考してないと? PG>>経営者>>営業職>>事務って感じがする
営業が仕様書を書くけど、よく怒られてる
若い社長だと、変わるのかな? 何も準備なしで客先行かされて翌日から用件定義書かされてリジェクトされる毎日だ いま入っている所だけど、上流はダルそうに仕事しているよ。
私が単体テスト仕様書をつくったのでみてもらってOKは出たけど、テスト実施して間違っていたら、そちらの設計がわるいからでしょといったよ。
確かに作った自分が悪いけど、その時この人にレビューしてもらっても意味が無いなと私は思ったよ。
プロジェクト内で同じようなコードがかなり重複しているのに、コードは同じもののコピペしか奨励されていないというかコピペ以外やってはいけないという時点で創造性なんてないと思うよ。
狭い範囲だけど市内の現場ほぼ同じ考えだった。 うちは同じ処理が場所によって違う方法で実装されてるから統一してほしい DRY原則なんて嘘っぱちだよな
仕様書がコピペで別に作られてるならコードもコピペで別に作るべき
見積もりに面倒がないし
改修のとき下手にまとめられてるよりはるかに楽 >>167
設計書にまとめた設計で書いてないのにコードでまとめてあると
修正するときに見積もれない工数がヤバイよね
10箇所から呼ばれていて各パートの帳尻合わせもやっていたりする場合が多い
前担当者の家をシンゴジラに踏んでもらいたい >>164みたいなとこだと間違ってても同様に直していけばいいけど
>>166は一つ一つ直すべきかどうかから見当しなきゃならないし
影響範囲も一個一個見定めなきゃならないし
割りとリスクある。 >>169
機能数と修正箇所数が一致してるなら問題ないじゃん
問題はコードを辿ってみて初めて影響範囲が巨大であることがわかる場合
これは設計書に書かれない下手くそな共通化が引き起こす場合が多い モジュール化すると影響範囲がわからなくなるっていうのは嘘
モジュールの依存関係が明確になるから影響範囲はむしろわかりやすくなる
コピペだとコピペしたコードがどこにあるかから探し始めないといけないから影響範囲の特定に余計に時間がかかる
上流は仕事をしないのでドキュメントを信じてコピペを探すと確実に漏れが出るのでコードを注意深くgrepするしかない
見つかったコードが単純なコピペならまだしもそれぞれが個別にメンテナンスされて微妙なバリエーションを持っているとそれぞれに対して詳細な影響調査をしなければならないので工数が数十倍に膨れ上がる事もある 共通化をするのは結構
だがそれを設計書に記述しないのはギルティ >172
コーダーの分際で上級SE様の責任まで背負い込もうとするから
そんなわけのわからん状況になるんだ
おかしい設計書よこしてきたら
動かないコードぶん投げてあんたのせいだって言い返せばいいじゃない
むしろそうしてくれないと後を引き継ぐ人たちがみんな困る 内部機能が共通だと思ったらどんどん共通化してくれていいけど
別の設計書に書かれてる機能は
せめて窓口は別にしてあげてください… 設計通りなんていう幻想は存在しない
本当に設計通りに作ったら100%動作しない
動作しないどころかビルドも通らない
存在しないモジュールに依存していたり
インターフェース仕様が設計書間で矛盾していたりする
そもそも曖昧で解釈の幅が広すぎて「設計書通り」を定義できない設計書も少なくない
下流はそういった上流の不始末を吸収してマトモに動作するものを出さないといけない
上流が無責任だから動作しないものを出すと下流の責任に転化される
言い換えると下流は設計書と違うコードを書く責任がある
最終的なコードと設計書の差分の吸収は流石に設計書の担当である上流の仕事だろう
設計書まで下流が弄ってしまったら上流がなんのために存在するかわからなくなる 上「これくらい理解してくれるよね?こんなとこまで書いてたら一生終わんねー」
P1「うちのP2はアホだから書かれた文字通り作るだろう。結合するためには、アホな設計に合わせないと…」
P2「うちのP1はアホだから書かれた文字通り作るだろう。結合するためには、アホな設計に合わせないと…」
誰もが正しい答えを知ってるのに
誰にもどうにもできない悲しい世界
だれかどうにかして… プログラムという客観的な地面から離れて成果が他者に依存するようになると
誰もが認識が歪んでおかしくなっていく プログラマを経験して実装レベルを知っている人が
上流に居ないと悲劇は繰り返される
知らんヤツが決裁権を持つと面倒 分業する方向が違うんだろうな
作業工程で分業するよりもエリックの言う通りサブシステム単位で分業した方がいい >>182
機能一覧が出せるほど仕様が決まっているならはじめから問題など起きない
機能一覧すら出せないから工程で分離して終わっていない工程をさも終わっているかのように見せる
ガチでクズだから平気でこのシステムを選択する 個人があーだこーだ言ってもどうにもならん
利害関係者全員が意識を高く持たなきゃ上手くいかない
一人で意識高く持っても辛いだけ
だから業務では心を殺してゴミを生産するしかない
休日に自分のシステムで頑張ろう
政治と同じだね
マイノリティにとっては民主主義なんて馬鹿馬鹿しいだけだよ モチの絵描く腕なんか欲しくない
モチ作れる腕が欲しい >>188
描けなきゃ、パック詰めしかやらせてもらえないよ 餅を描きたい欲求があるわけじゃないけど他人に描かせるとひどい目にあうから自分で描きたい人が多数派 他人が描いた餅の絵でひどい目にあうってどういう状況だよw
ひょっとして闇が深い話なんかこれ?w やりたいこと:もちつき
やっていること:もちの絵をかく
現場のしごと:もちのパック詰め
もちつきがやりたいなら、もちつきをしている会社にいかないとね
量産品つくってるメーカーで、もちつきやりたいっていっても困るんだわ プログラミングが好きで
プログラミングしたくてこの業界に来たのに、
Sierはほぼ設計でExcel、客との折衝ばかりで製造は外注丸投げ。
ソフトハウスはどうか?→ほぼSierからの下請けで、客先常駐でのプログラミング。SEより待遇悪し。
ほんとにプログラミングやりたいなら、Webサービス企業、ゲーム企業に入るべし。 ゲームはやだなぁ
Webサービスは上流工程やらないの? SIerではなくメーカで組み込み担当してる。
俺は要件定義は結構好きだな。次期製品の仕様を他社ベンチしたり、営業部隊とワイワイ議論しながら決めてくのは結構楽しい。
コーディングは安全性重視のため、比較的既存ソースを流用することが多く、自由度も低いので。 >>200
俺のとこ(メーカー)はコーディングしてるよ。
ソフト技術者はコーディングするのが当たり前という風潮。
自分でコーディングしていないとコードの良し悪しは
分からないので後輩指導も仕入先とのレビューも出来ないと思う。 >早く要件定義
>プロジェクト管理
>できるように頑張りなさい」
>プログラマ「そんなスキルは興味ありません」
まぁ >プロジェクト管理 はいいとして
>早く要件定義
を「そんなスキルは興味ありません」
と言っちゃうバカは消えてほしいわ。どんだけプログラマの地位を貶めるつもりだ? >>200
おまえのやってるのは、プログラミングではなく、コーディング又はキーパンチ >>205
そんなスキル要らない。
PGと顧客の間に挟まれるニュータイプの
ブリッジSEを作ればいい。
口が上手くて両方の言うことが分かるやつ。 >>207
口がうまいwww
そんなレベル客も別に求めてないですが?
普通にしゃべれれば何にも問題ありませんが?
プログラマ=しゃべることもできないコミュ障=キチガイ
って自分たちから自分たちをゴミにしないように >>208
お前未経験なのが分かったわ、相手して損した 口も上手いプログラマになればいいだけだろが
なに、僕出来ませーんって泣き言言ってんだよ 客から要求を聞き出し現場を観察して手段を提案し設計をし法的責任の確認から金まで全部終了。
「そこから『だけ』」しかできない作業なんて何が面白いんだ? >>204
開発するソフトウェアが会社(組織)のコア技術になるなら
自社社員にコーディングさせると思う。 上流もプログラミングもしたくない
というか仕事もしたくない PGだSEだと区切りが明確な会社はだいたい給料が低い
上流も100万ユーザのサービスなのか20人が使う勤怠システムなのかによっても違うけどね うち実装してからそれを元に設計書出してるわ
有能PGにはコーディングに集中してもらった方が効率いい まず、設計書っていうのは工数の計算する元となる資料
設計書を軽視する人はおそらく金銭交渉しない人 はぁ?設計書書く工数はどうやって見積もってんだよwwww >>219
サブスクリプションに近い契約方式も使えるからな
その場合工数うんぬんより「要件のうちコレとコレやりましょう」で済むわけで >>202
全く同じや。組み込みだったら要件定義のが創造性発揮できて楽しい。
プログラミングへの欲求はテスト用ツールを作ったりで満たしてる。 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
TN79BEQ89A ☆ 私たち日本の、改憲を行いましょう。現在、衆議員と
参議院の両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
H28VG PMやれってずーっと言われてて、あっ、はい…って答えてた。
そしたらついに来月から1本プロジェクト任されることになった。納品終えて一息ついたタイミングで。
PMってなにやりゃいいのよ…。
とりあえず本1冊買ってきた。 見積もりはちゃんと書いておいたほうがいいらしいぞ。
それでヨソに仕事とられるなら素直にそいつらにくれてやれ。
どうせそいつらが後になって、その仕事をもってきてくれるんだ。 ところがどっこいウチの営業が拾ってきてくれるんだわ
次に繋がるからここは頑張りどころと 大手の開発部長が製造は仕事がほとんど消えるから技術の勉強は不要で、要件定義のためのコミュ力磨けといっていた そもそも、要件定義やプロジェクト管理は多くの機密情報を知る側だから
身内の縁故採用でないと無理だと大学キャリアサポートから教わった。 自らの価値を証明するエビデンスに乏しくて、奴隷風情にマウントを取るくらいでしか承認欲求を満たせないようなキャリアには興味が無いなあ
クッソつまんなそう マネジメント、顧客対応くそつまんない。プログラミングやってるほうが全然やりがいあって、楽しい。 プレミアが1軍にもめぼしい選手はそれできついだろう
気付いた同僚が無理矢理終了したらしく >>146
というか空前絶後のバカだな
ホテル暮らしなんだろうかと思うけど。 物事を決めたくない
自分の責任で進めたくない
間違っていたらすぐに責任転嫁できる
夜のAVは速攻で決めるのに
仕事の内容は一切決めようとしない
人間のカス、クズ、ゴミ