を求めてくるプログラマ
要求仕様書や定義を机上だけで一発で完璧なものを作成しなければ、ならない。
こんなの無理に決まってんじゃんｗｗｗｗ
客は素人だぜ？
素人にいきなりすべてを完全網羅したミスが一切ないシステムに必要なもの等々を完璧にこなす
んなことができるなら、そもそも発注なんてする必要性がないだろｗｗｗｗ
異常だよ日本の開発体制は
世界で日本だけじゃんこんな非IT企業にプログラマがほとんどおらず、IT（奴隷派遣）に９割以上のプログラマがいる開発体型ってさ。
バグを発生させない為にリファクタリングするんだよ
おまえらだって「関係ないとこ全く触らずに修正するなんて無茶だよ、この糞コード。全部関係しちゃってるビッチなコードじゃねーか！！」って思ったことがあるだろう？
必要なとこだけ根元から処理ルート分けるという知恵はないのか
>>34
それをするなっていうほうが一般的でしょ
最初にその選択肢が出てくるなんてどんな幸せなプログラマ人生歩んでるんだよ >>35
銀行とかの昔からあるミスの許されない大規模スパゲティシステムで良くある方式だよね。ちょっと変えただけの双子のような関数がたくさん生まれて、そこに修正が必要となると複製された関数全部で同じ修正を入れて、ますます肥大化していく。
直近のバグを出したくないという目先のことしか考えずに、その結果、後になって皺寄せが来てメンテナンスを困難にするという負のスパイラル。 と本に書いてあったんだろう
実際はリグレッションテストは機能面からやるからそこがボトルネックになり
工数はたいして変わらないどころか
全部に影響する関数に手を入れるので増えてしまうことがほとんど
耳学問の頭でっかちがプロジェクトを破壊する
0038仕様書無しさん2020/07/16(木) 19:59:01.92
リファクタリングなんかやるなよ
本来、業務システムなんて5年くらいでまるごと更新が正しいんだから
0039仕様書無しさん2020/07/18(土) 07:14:51.57
>>38
ユーザーの担当者が変わる都度、更新が正しいよね
更新には業務知識が必要だから新担当者は必死に業務を学ぶから 開発1〜2年かかるとして運用で5年とかハードはともかくOSや外部のライブラリ等の
ライフサイクルはそれよりもっと短いから現実的ではないんだよな
運用2〜3年目くらいで新しく入ってきた人には化石システムに見えたりするから
この業界のビジネスモデルとか意識の問題がでかすぎるんだよ
0041仕様書無しさん2020/07/19(日) 13:01:25.27
現場が自分たちの仕事を全部手作業で出来なきゃ駄目だとだめぽが教えただろ
その勉強にシステムのリプレイスを利用するのは有り
0042仕様書無しさん2020/07/19(日) 16:27:32.57
俺もリファクタよりリプレイスが可能ならそっちを勧める
可能ならな
0044仕様書無しさん2020/07/19(日) 19:11:41.20
アプローチが変わるかもしれないのに
古いソースコード大事にしてどーすんの？
20〜30年使ってればアプローチの仕方は確かに変わるのだろうが
たかだか5年程度でアプローチなんてそんなに変わらんよ
アプローチが変われば別の問題が発生する
作り直せば問題が減るわけではない
出来合いのプログラム、ライブラリ、フレームワークで十分なことが
多いんだけどな。金かけて仕様通りに動かないソフト作って
何がうれしいんだかわからん。
出来合いのライブラリで作ると細かい修正に対応できなくて詰む
無理筋で実装するから結局工数短縮にならない
出来合いのプログラムだと拡張したくなったときに対応できない
フレームワークは使ってた機能ごっそりなくなったり
出来合いのものが10年後20年後残っているかは議論の余地があるとこだと思うけどね
毎年どころか毎月毎週更新しないと使い物になりませんってものを導入したいとは思わんでしょう
>>49
そこだけライブラリを使わなければいいだけでは？ >>51
例えばWindowsだとDataGridViewのライブラリは多いと思うけど
機能が足りなかったら別のものに入れ替えるのかってことだよ >>52
そりゃ拡張しても対応できないなら入れ替えるだろ？
最悪自分で同等のものを実装したり
コストが割に合わなければ諦める
それだけだろ 見積りの時点でできるかどうかわからない内容が多いときはやめるべきだね
それか素直に聞いちゃう
これできなかったら[代案]でいいですかね？って
駄目だこれができないと意味がないここは外せないって相手が強く言うならそもそもやり方知らんしって話じゃん
0055仕様書無しさん2020/07/21(火) 20:27:41.95
フレームワークもなれるまでは安定しないしなあ
んですぐに新しいフレームワークが現れる
本当にそんなに特殊な要件が多いのか?
よくよく聞いてみると世にあふれているプログラムで
十分なことが多い
>>56
担当者がバカでよくわかってないから代案を通すために話す相手もよくわからないのさ 0058仕様書無しさん2020/07/22(水) 06:19:20.93
>>56
んだ
だが最後の部分は会社独自
決裁様式！
だからまるごと作るのさw 0059仕様書無しさん2020/07/24(金) 08:43:15.02
どんなに言っても
客側に、仕様書のとおりですから。
だからなあ
実装より設計のほうが難しいしね
ビジネスフローの段階で間違ってる事が多いからどうにもならん
間違って仕事させた分の金払えば何も言わんよ
客の間違いなのにプログラマがサービス残業するのが解せぬ
0061仕様書無しさん2020/07/24(金) 11:56:15.28
仕様書のとおりです
といって
仕様書みると仕様書の通りではなかったりするw
0062仕様書無しさん2020/07/25(土) 03:08:30.05
ハンバーーーーグ！！
0065仕様書無しさん2020/07/26(日) 15:20:08.87
0066仕様書無しさん2020/07/26(日) 16:40:27.32
>>23だけは無視できないw
あいつらはホント嘘ばっかりいう 0067仕様書無しさん2020/07/27(月) 22:46:46.33
営業「「できます」と客に言った」：
↓
開発「できない」
↓
営業「なぜできないの！！！！」：
↓
開発「技術的には可能。でも事業部の方針でしょ。事業部長？本部長？クラスを説得できるの？」
↓
(たぶん、客が激怒）
↓
営業首
↓
もと営業、開発に新人として参加ｗ
そんなフローはない
開発「技術的には可能。」or「矛盾してて絶対無理！」
↓
営業「それをどうにかするのが仕事でしょ！？死んでもやって！」
↓
開発が体壊して入院。精神病院で一生を終える。
営業はがんばったところを見せたので昇進。
0069仕様書無しさん2020/07/27(月) 23:37:18.30
ない言われても実話ベース
結局助かったのは
動かしがたい技術的理由ではなく
本部の取り決めに関する見聞のおかげという
0071仕様書無しさん2020/07/28(火) 06:15:22.55
お前に命令権はない！
と今の上司はいうw
ヤダ素敵
契約始まった時点で
営業ってどこまで約束してるもんなんだ
「バグはつきもの」by プログラマ
「仕様変更はつきもの」by 発注者
まあ、お互いの自己弁護よ。
0075仕様書無しさん2020/08/02(日) 20:02:45.92
>>74
仕様変更は金取られてるからおなじじゃねーだろ 0078仕様書無しさん2020/12/28(月) 18:03:44.77
バグは憑きもの
0079仕様書無しさん2020/12/29(火) 14:38:59.86
>>1
そこでITコンサルを雇う
しかし完璧にはならない 完璧な要求定義があれば
10人6か月の60人月の案件も50人月になるかもしれない
数百万万円ぐらい経費が浮く
だから上流工程の優秀なSEなりITコンサルが求められる
しかし現実には曖昧・過不足な仕様でしばしばデスマーチ要因になり
恨みが向かうのでITコンサルは嫌われやすい
0083仕様書無しさん2024/03/29(金) 14:33:37.44
体感だが