上流工程やりたくない [無断転載禁止]©2ch.net

2017/02/18(土) 16:32:46.00
意識高い系社長「君もスキル磨いて
早く要件定義やプロジェクト管理
できるように頑張りなさい」
プログラマ「そんなスキルは興味ありません」
81仕様書無しさん
垢版 |
2017/02/19(日) 19:24:27.76
>>79
犬小屋作るのならシングルトンでもいいだろうが
スカイツリーはシングルトンじゃ無理
82仕様書無しさん
垢版 |
2017/02/19(日) 19:33:38.16
>>35
結婚障害は深刻過ぎるからな
2017/02/19(日) 19:45:31.98
なぜそんなにシングルトンを持ち出すのか？
その理由はわかっている。
シングルトンにしか勝てないからだ。
2017/02/19(日) 20:17:06.16
これからもシングルトン
2017/02/19(日) 20:18:28.93
インスタンスが常に一つなのは保証されている
2017/02/19(日) 20:21:44.52
デザパタを否定するやつがシングルトンパターンを
持ち出してくるのは、シングルトンパターンしか
理解できないからだって聞いたことがある。
理解できない時点で否定する資格がないと笑われていた
2017/02/19(日) 20:24:19.66
グローバル変数を拒否された唯一の希望がシングルトンだからだ
88仕様書無しさん
垢版 |
2017/02/19(日) 20:29:40.79
>>86
お前にデザパタを語る資格はない
89仕様書無しさん
垢版 |
2017/02/19(日) 20:31:47.74
上流工程について語るときにデザパタを持ち出すやつは
デザインパターンが何なのか、上流工程の仕事が何なのかを
理解せずに語っている、デザインパターンをデザパタと略して
さもわかってるかのように語るやつは初心者を脱しただけの
一番危ない人間だ
90仕様書無しさん
垢版 |
2017/02/19(日) 20:33:34.01
>>86
ブリッジパターンの使いどころ教えて？
カンニングすんなよｗ
5分以内に実践的な使い方答えて
91仕様書無しさん
垢版 |
2017/02/19(日) 20:35:55.40
デザインパターンを作ったGang of fourでさえ
デザインパターンを否定しているわけだが
有用性を理解できる人間がいるとは思えないが
92仕様書無しさん
垢版 |
2017/02/19(日) 20:38:33.53
オブジェクトに状態を持たせるってやり方が
100年前の考え方だってこと
関数型の方がよほど合理的なわけで
Gang of fourもそこを指摘している
いまごろデザインパターンがどうとか言ってたら
プログラマとして危険人物だろ
93仕様書無しさん
垢版 |
2017/02/19(日) 20:38:55.34
あれ5分経ったけど
94仕様書無しさん
垢版 |
2017/02/19(日) 20:40:18.80
やはりデザインパターンを語るやつはまともじゃない
下流土方としても3流
95仕様書無しさん
垢版 |
2017/02/19(日) 20:49:51.96
DDD難民に捧げる
Domain-Driven Designのエッセンス
第1回　ドメイン駆動設計とは
https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html

こっちの方が役に立つんじゃないかな
そもそも設計やってるのか疑わしいが
96仕様書無しさん
垢版 |
2017/02/19(日) 20:54:47.08
よしわかった、じゃあここはシングルトンについて語るスレにしよう
97仕様書無しさん
垢版 |
2017/02/19(日) 20:55:21.89
シングルトンすごいよな
2017/02/19(日) 20:59:15.66
シングルトン最強!
99仕様書無しさん
垢版 |
2017/02/19(日) 21:02:40.20
シングルトンよ、データは一度だけ読めばいいのだ。
と言ってるのに、言うこときかない。なんで？
2017/02/19(日) 21:02:52.16
>>81
いいやスカイツリーも俺が乗るわけじゃないのでシングルトンで作る
2017/02/19(日) 21:04:11.24
例えばスカイツリーを何十個も複製するならシングルトンではダメだが
1つなのでシングルトンの出番となる
102仕様書無しさん
垢版 |
2017/02/19(日) 21:08:35.63
>>100
さようか
103仕様書無しさん
垢版 |
2017/02/19(日) 21:09:30.71
>>101
Object.cloneでコピーできますけど？
2017/02/19(日) 22:29:59.28
そうさ〜 僕らは〜♪ 世界に一つだけのシングルトン〜♪
一つ一つ違うインスタントを持つ♪
2017/02/19(日) 22:33:42.47
>>103
ぶっ潰す
2017/02/19(日) 23:19:29.56
上流って整合性云々は二の次で、とりあえず判子もらう資料作ったら終わりやん
後の辻褄合わせは全部下流に丸投げして、スケジュール管理という名の下流の尻叩き
納期遅れようが、赤が出ようが、全部下流のせい
楽な商売だよ
2017/02/20(月) 00:28:34.71
>>106
最近俺のまわりでは上流と下流は分かれてないかな?
少なくとも設計からテストまではセット
2017/02/20(月) 03:07:32.42
>>107
そんな現場では働きたくないな
上流だけやっていたい
2017/02/20(月) 04:36:16.32
>>108
糞な設計しか出来なさそうだな。
2017/02/20(月) 07:12:36.47
>>108
多分多くの会社でここ分けるメリットねぇなって学習したんと違うかな?
設計だけだとあまりにも投げっぱなしのジャーマンを炸裂する奴多すぎ問題で
2017/02/20(月) 08:30:29.44
>>107
どうせ犬小屋程度のものしか作ってないんだろ
だったらシングルトンで十分だ
2017/02/20(月) 22:06:19.41
>>111
っていうか、そんなシームレスに際限なく馬鹿でかいプロジェクトあってたまるかよ
よっぽど担当者の脳みそ腐ってんだろ
まあ、実際に腐ってるケースもあったが
インターフェイス定義してプロジェクト分けろと
113仕様書無しさん
垢版 |
2017/02/20(月) 22:21:10.75
>>112
プロジェクトを分けてたくさん犬小屋を作るつもりか
114仕様書無しさん
垢版 |
2017/02/20(月) 22:26:41.86
シングルトンでは犬小屋しか作れないのだよ
ピラミッド状に組織を作ってやらないと大規模なものは作れない
スカイツリー作った人のほとんどは土木作業員
設計者はそれに比べればほんの僅か
大規模な作業は役割を分担して組織化することによってはじめて実現できる
誰もかれもが現場作業やればいいってもんじゃない
長妻なんとか元パワハラ大臣が手計算で年金計算してたようなもの
組織というものがなんたるかを知らない人間が上に立つとできることもできなくなる
2017/02/20(月) 22:32:15.77
デザパタで馬鹿にできるのがシングルトンだけだから
シングルトンを集中攻撃してるのかな？
ネタバレされたらなんか間抜けだよねｗ
116仕様書無しさん
垢版 |
2017/02/20(月) 23:09:16.81
>>115
シングルトンひいてはデザパタが攻撃されてると思うの？
自意識過剰じゃない？
どういう意味でシングルトンという言葉を使っているのか
頭を冷やして冷静に考えみなよ
ヒントはデザパタは役立たずのクソ
117仕様書無しさん
垢版 |
2017/02/20(月) 23:09:59.45
シングルトンの一本槍で戦ってるのはデザパタさんの方じゃないか
118仕様書無しさん
垢版 |
2017/02/20(月) 23:10:49.90
コマンドパターンでかかって来いよ
119仕様書無しさん
垢版 |
2017/02/20(月) 23:15:03.70
デザパタさんシングルトンしか知らないんじゃ……
2017/02/20(月) 23:16:14.01
>>116
いや、シングルトン以外の話をしろよってことだよｗ
お前のことだ。シングルトンを一回忘れて
他のデザパタの話をしようか。
121仕様書無しさん
垢版 |
2017/02/20(月) 23:16:51.24
>>120
じゃあどうぞｗ
122仕様書無しさん
垢版 |
2017/02/20(月) 23:23:36.85
くらえ！ひっさつちぇいんおぶれすぽんしびりてぃいいい！！！とかやればいいじゃん
なに黙ってんの
123仕様書無しさん
垢版 |
2017/02/20(月) 23:24:19.54
デザパタさん口下手すぎるわ、まじめか
124仕様書無しさん
垢版 |
2017/02/20(月) 23:28:05.23
デザパタさん？大丈夫？シングルトンする？
125仕様書無しさん
垢版 |
2017/02/20(月) 23:30:52.21
インタプリタとか業務で使うことまずないよな
アブストラクトファクトリもフレームワークとか作るのでない限り使わぬし
シングルトンも別にグローバル変数で間に合ってるし
結局使うのってコマンドパターンくらいかコマンドパターンも一般的過ぎて
もはやコマンドパターンと呼べる代物じゃない
ただのインターフェースだしファクトリはゴミ
126仕様書無しさん
垢版 |
2017/02/20(月) 23:33:50.74
メディエイタはUI作るときいいかも
127仕様書無しさん
垢版 |
2017/02/20(月) 23:35:40.88
デザパタさんの応答がないとき使えるデザパタを募集します
128仕様書無しさん
垢版 |
2017/02/20(月) 23:40:23.91
プロキシか？プロキシを挟んで誰か別の人間が応答すればいいのか
その間にデザパタさんの初期化を頑張ればパフォーマンス出るんじゃないか？
129仕様書無しさん
垢版 |
2017/02/20(月) 23:45:17.64
ぼっちすぎて死にそうなんだけど？
130仕様書無しさん
垢版 |
2017/02/20(月) 23:45:47.08
俺がシングルトンなんだけど？
2017/02/21(火) 04:31:29.49
>>115
デザパタをムリに適用しようとしたらオーバースペックというか
interface狂というか
「あるクラスは別のクラスに交換可能であるべきじゃい主義者」
になる印象はある

フレームワーク書いてるとか、JSRに従ったAPI書いてるとか
エライ人の怒声により2コのシステムを無理に共通化しようとしてるとか（X社は先日弊社が買収しますた）
そういう時でないとデザパタがフル稼働する状況は思い浮かばない

例えばコーヒー豆小売店用のBtoCサイトだとGoFのデザパタなんか1/10も使わんかも
132仕様書無しさん
垢版 |
2017/02/21(火) 19:08:43.33
一次受けって上流？
2017/02/21(火) 19:22:27.26
>>132
いいや、丸投げ
2017/02/21(火) 19:34:58.61
特に意識しなくても気付いたらデザインパターン多用してる
というか必然の設計をするとあ、この形はよく見たらなんとかパターンだなってなる
135仕様書無しさん
垢版 |
2017/02/21(火) 20:43:54.57
あやしい
136仕様書無しさん
垢版 |
2017/02/21(火) 22:13:43.23
>>133
丸投げってなんなん？
2017/02/22(水) 01:23:50.11
>>136
受けた仕事をそのまま外注に出すこと
打合せの会議すら参加しない
138仕様書無しさん
垢版 |
2017/02/22(水) 10:05:45.96
>>137
なるほどー、ありがと！
2017/02/22(水) 19:53:54.51
情報システム板に帰れよ
2017/02/23(木) 01:35:53.12
正社員になるとずっとプログラマでいるとこはできない悲劇
141仕様書無しさん
垢版 |
2017/02/23(木) 19:08:31.94
>>1
上流って早い話が、システムの設計ができるってことだろ？
なんの設計権もないプログラミングなんて面白くもクソもないだろ
2017/02/23(木) 21:54:03.03
コーダーだって設計ができなきゃ
渡された設計書が適切であるかどうかも判断できないよ
143仕様書無しさん
垢版 |
2017/02/23(木) 21:55:10.93
>>142
算数ドリルやってるだけで楽しいか？って話だろが
2017/02/23(木) 22:00:05.26
適切な設計がわかると低脳SEの書いたクソ設計に従って作業する苦痛に耐えられなくなる
コーダーは設計なんてわからないほうが幸せ
2017/02/23(木) 22:39:05.98
>>1
まあ上流工程がゼロから価値を創出するところだしね
その分多様なスキルを求められて精神体力ともに凄くキツイ
やらなくていいのなら絶対やらない方がいい
2017/02/24(金) 00:04:03.99
価値を考えてるだけで
創出はしてないだろｗ

価値を考えるだけなら誰でもできるわけで
2017/02/24(金) 07:34:41.08
むしろ負債を創造しているSEのなんと多いことか
148仕様書無しさん
垢版 |
2017/02/24(金) 22:27:03.80
コーディング下請けの上にいるのはSEちゃうで上級コーダーや
2017/02/25(土) 10:59:15.00
低級顧客では？
150仕様書無しさん
垢版 |
2017/02/25(土) 12:44:19.79
要求は自由にならないけど、
それを満たす仕様（アイデア）を自分で考えられる権利を持ってるのって上流だけじゃん

ものづくりで一番楽しいのってそこじゃない？
そのアイデアが最終的にどれだけ効果をもたらしたか？
この二つが無いところの仕事って何が楽しいの？
151仕様書無しさん
垢版 |
2017/02/25(土) 12:45:58.19
>>150
hello worldが出力されたら楽しい
それがプログラマ
152仕様書無しさん
垢版 |
2017/02/25(土) 12:47:11.92
書いたとおりにプログラムが動く
プログラミングとは世界が自分の思い通りだと認識させる麻薬のようなもの
2017/02/25(土) 13:08:59.06
思い通りの世界が作れるワケではないのだが
154仕様書無しさん
垢版 |
2017/02/25(土) 13:40:26.87
>>146
>>153
2017/02/25(土) 15:28:58.98
>>150
他人の作った、しかも低品質すぎてめまいがするような設計に服従してコード書く仕事って、ほんと何が楽しいんだろうな？
2017/02/25(土) 15:43:10.41
>>153
その思いがSEは的はずれだからな
顧客（＝素人）が言ってることを伝えてるだけ
2017/02/25(土) 17:56:30.22
>>150
仕事やったことねーなお前
2017/02/25(土) 18:01:57.75
概ねこんなことがやりたいんだけど
ってのは客の要望で決まってて
上流がやるのなんて他で悪影響があるかないか目を皿のようにして調べるだけ
アホはその工程を飛ばすから下流での尻拭いが酷い

クリエイティブな箇所なんて欠片も存在しないので安心してほしい

そういうのがやりたければ日本を出ろ
日本のベンチャーという手もあるが契約が稚拙なので食い物にされるだけ
本気でクリエイティブな仕事がしたければ海を渡る必要がある
159仕様書無しさん
垢版 |
2017/02/25(土) 18:03:42.41
>>158
勝手にレッテル貼ってるけど、低偏差値のおまえが思ってることをなんで他の頭のいい人が思考してないと？
160仕様書無しさん
垢版 |
2017/02/25(土) 18:14:40.54
PG>>経営者>>営業職>>事務って感じがする

営業が仕様書を書くけど、よく怒られてる

若い社長だと、変わるのかな？
2017/02/25(土) 18:21:24.34
>>159
は?
早く死んでね
2017/02/25(土) 19:09:02.85
何も準備なしで客先行かされて翌日から用件定義書かされてリジェクトされる毎日だ
2017/02/25(土) 21:04:44.29
お使いでちゅか？
用件はなんでちゅか？
164仕様書無しさん
垢版 |
2017/02/25(土) 21:43:47.05
いま入っている所だけど、上流はダルそうに仕事しているよ。
私が単体テスト仕様書をつくったのでみてもらってOKは出たけど、テスト実施して間違っていたら、そちらの設計がわるいからでしょといったよ。
確かに作った自分が悪いけど、その時この人にレビューしてもらっても意味が無いなと私は思ったよ。

プロジェクト内で同じようなコードがかなり重複しているのに、コードは同じもののコピペしか奨励されていないというかコピペ以外やってはいけないという時点で創造性なんてないと思うよ。
狭い範囲だけど市内の現場ほぼ同じ考えだった。
2017/02/26(日) 00:24:07.14
この業界は意識高く持とうとすると絶望する
2017/02/26(日) 01:43:52.58
うちは同じ処理が場所によって違う方法で実装されてるから統一してほしい
2017/02/26(日) 07:46:29.32
DRY原則なんて嘘っぱちだよな
仕様書がコピペで別に作られてるならコードもコピペで別に作るべき

見積もりに面倒がないし
改修のとき下手にまとめられてるよりはるかに楽
2017/02/26(日) 10:02:00.69
>>167
設計書にまとめた設計で書いてないのにコードでまとめてあると
修正するときに見積もれない工数がヤバイよね
10箇所から呼ばれていて各パートの帳尻合わせもやっていたりする場合が多い
前担当者の家をシンゴジラに踏んでもらいたい
2017/02/26(日) 10:16:57.93
>>164みたいなとこだと間違ってても同様に直していけばいいけど
>>166は一つ一つ直すべきかどうかから見当しなきゃならないし
影響範囲も一個一個見定めなきゃならないし
割りとリスクある。
2017/02/26(日) 10:29:10.54
これがジャップランドか
2017/02/26(日) 10:31:10.43
>>169
機能数と修正箇所数が一致してるなら問題ないじゃん
問題はコードを辿ってみて初めて影響範囲が巨大であることがわかる場合
これは設計書に書かれない下手くそな共通化が引き起こす場合が多い
2017/02/26(日) 10:44:23.07
モジュール化すると影響範囲がわからなくなるっていうのは嘘
モジュールの依存関係が明確になるから影響範囲はむしろわかりやすくなる
コピペだとコピペしたコードがどこにあるかから探し始めないといけないから影響範囲の特定に余計に時間がかかる
上流は仕事をしないのでドキュメントを信じてコピペを探すと確実に漏れが出るのでコードを注意深くgrepするしかない
見つかったコードが単純なコピペならまだしもそれぞれが個別にメンテナンスされて微妙なバリエーションを持っているとそれぞれに対して詳細な影響調査をしなければならないので工数が数十倍に膨れ上がる事もある
2017/02/26(日) 10:45:49.83
>>172
それを設計書にも書けばね
2017/02/26(日) 10:49:46.62
共通化をするのは結構
だがそれを設計書に記述しないのはギルティ
2017/02/26(日) 10:53:26.38
>172
コーダーの分際で上級SE様の責任まで背負い込もうとするから
そんなわけのわからん状況になるんだ

おかしい設計書よこしてきたら
動かないコードぶん投げてあんたのせいだって言い返せばいいじゃない

むしろそうしてくれないと後を引き継ぐ人たちがみんな困る
2017/02/26(日) 11:01:54.94
内部機能が共通だと思ったらどんどん共通化してくれていいけど
別の設計書に書かれてる機能は
せめて窓口は別にしてあげてください…
2017/02/26(日) 11:11:54.14
設計通りなんていう幻想は存在しない
本当に設計通りに作ったら100%動作しない
動作しないどころかビルドも通らない
存在しないモジュールに依存していたり
インターフェース仕様が設計書間で矛盾していたりする
そもそも曖昧で解釈の幅が広すぎて「設計書通り」を定義できない設計書も少なくない
下流はそういった上流の不始末を吸収してマトモに動作するものを出さないといけない
上流が無責任だから動作しないものを出すと下流の責任に転化される
言い換えると下流は設計書と違うコードを書く責任がある
最終的なコードと設計書の差分の吸収は流石に設計書の担当である上流の仕事だろう
設計書まで下流が弄ってしまったら上流がなんのために存在するかわからなくなる
2017/02/26(日) 11:21:40.78
上「これくらい理解してくれるよね？こんなとこまで書いてたら一生終わんねー」
P1「うちのP2はアホだから書かれた文字通り作るだろう。結合するためには、アホな設計に合わせないと…」
P2「うちのP1はアホだから書かれた文字通り作るだろう。結合するためには、アホな設計に合わせないと…」

誰もが正しい答えを知ってるのに
誰にもどうにもできない悲しい世界

だれかどうにかして…
2017/02/26(日) 11:25:07.33
プログラムという客観的な地面から離れて成果が他者に依存するようになると
誰もが認識が歪んでおかしくなっていく
2017/02/26(日) 11:30:19.81
プログラマを経験して実装レベルを知っている人が
上流に居ないと悲劇は繰り返される
知らんヤツが決裁権を持つと面倒
2017/02/26(日) 11:54:27.06
早く仕様決めて
それか仕様固まってから期間決めて
新着レスの表示
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況