スパゲッティプログラムの改修の仕事を任された

1 ：08/03/14 〜 最終レス ：11/08/30

やらねーよバーカ 
そんな糞仕事してる暇ねーよ 
もっとエキサイティングで技術力が身に付く仕事をよこせ 
もしくは月給１００万でやってやる 
万年人手不足のＩＴ業界なめんなよ 
売り手市場なんだよバカが 

2 ：

>>1
> 万年人手不足のＩＴ業界なめんなよ
これはその通りだが、
> 売り手市場なんだよバカが
なぜか常に買い手市場なんだよ不思議なことに。

3 ：

ＩＴ業界は気の弱い奴が多いからな
悪意に満ちた経営者どもが気の弱い技術者を奴隷扱いにして
喰ってるのが現状

4 ：

リファクタリングって楽しくない？

5 ：

たのしい。

6 ：

>>1
あのね、「スパゲッティー」なんてもう言わないんだよ。
今時はパスタコード。これだね。

7 ：

>>2
いや、売り手市場だと思うぞ？
買い叩かれてるんなら理解出来るが。
>>1
>もっとエキサイティングで技術力が身に付く仕事をよこせ
(´,_ゝ｀)ﾌﾟ

8 ：

作り直したほうが早い。

9 ：

「少しでもコストを抑えたい。だから今あるものを出発点にして修正しよう」
という素晴らしい理論によっていつの間にか理屈と目的が入れ替わる

10 ：

入社してから5年くらい、仕様書もないクソコードのメンテをさせられたおかげで
コードと現物の動作から仕様を書き起こすという果てしなく底辺な能力が身に付いた。
今は一から開発できる立場になってるが、今度はろくに時間がないから仕様書を残せないでいる。
数年後、俺のコードをメンテする奴は俺のことを罵りつつ仕様書を書き起こすんだろうなぁ

11 ：

仕様書を書く時間がないなら、仕様書がなくても分かるようなコードを書けばいいじゃない。

12 ：

>>10
暗黒循環だなｗ

13 ：

>>11
時々そういうコードあるよね。
逆にコメントに「死にたい」って書いてるコードもあるよね。

14 ：

コードが仕様書だ。

15 ：

ジャングルでは俺が法律とかそんな感じですかね

16 ：

↑
なんかワロタよ

17 ：

コボラやC屋がjava1.3時代に作ったFWを未だに新規案件に使ってる会社もあるからな
結構スパゲッティ見てるけど、あいつらほんと配列好きだな。

18 ：

ジャングルはハレのちうっ

19 ：

コードこそ仕様
バグなどこの世に存在しない

20 ：

しようがないなあ(^^;

21 ：

>>17
まさか単なる関数群をFWとか言ってないよな？w
コボラがFW組めるとはとても思えないんだが

22 ：

コボラが組めるのは以下の内どれか？
ア. FW　　イ. MF　　ウ. DF　　エ. GK

23 ：

オ

24 ：

で、>>1はいま泣きながらPC二向かってるんだね？

25 ：

>>21
自称しちまえばなんでもFWなんだよｗ
営業資料に堂々と「自社FWにより開発工数削減」

26 ：

>>26
脳内で処理全体を掴もうとするは諦めるこった。
ノートとかに一行一行の処理を箇条書きするとかで、
紙に記録残さないとムリ。
1関数5000行のゴミコードをメンテした時、書いた奴をSATSUGAIしたくなった。
>>6
個人的には「クトゥルー」とか「貞子」と呼びたいんだが。

27 ：

俺は何で自分にアンカーを？
なんかわからんでもないが orz　吊ってくる
>>1

28 ：

>>26 ほうら、頭の中がすでにスパゲティ（ry

29 ：

>>28
いやもうスパゲッティなんかじゃなくて、蟲毒の壷みたいな。
アレを思い出すと頭がいやあああああになる。
他にも、1関数2000行〜3000行のコードが10個くらいあったんだ……。

30 ：

某永遠の病気に挑む会社では
1ファイルに５０ｋステップの関数が3個あったよ
最終更新日が去年の9月だったｗ

31 ：

スパゲッティってんじゃないがこの前VB6で
public sheetvalue as string
sub SheetEvent()
sheetvalue = Sheet.Value(1,1)
end sub
sub Button_Click()
dim sheetvalue as string
sheetvalue = Sheet.Value(1,1)
Call func(sheetvalue)
end sub
sub func(value as string)
dim sheetval as string
sheetval = sheetvalue
' sheetvalで処理
end sub
こんなんあった。（func内のvalueは結局一度も使われてなかった）
全面的にこんなソースだから解析も苦労したけど、
一番驚いたのがほとんどバグが無かったこと。
こんなバグ出したがってるとしか思えないソースで
よくもまあそこまでテストしたもんだと感心した。

32 ：

いろんなところでグローバル弄られるのが一番つらい。
static変数一切なし。保持しなければいけない変数は全てグローバル。

33 ：

当然
・違う用途で同じ変数を使い回す
・(意図せず)別スレッドから書き換えられてバグる
ぐらいは前提条件だよな？

34 ：

>>31
そういうコードってなんか脱力するよな
無駄な労力使ってなにやってんだよ、っておもっちまう

35 ：

無駄な労力をつかって残業代を稼ぐんだろ

36 ：

>>32
会社とか部署によっては、グローバル変数を使うのになんの躊躇もないところがあるよなぁ。

37 ：

ポインタ使うとおかしくなるから
引数０で全部グローバルってとこ
今もあるよ

38 ：

グローバル変数も引数の参照渡しもヘッポコ

39 ：

>>10
これは解る

40 ：

>>17
配列はVectorなんかより処理が早いからだろ

41 ：

>>33
マルチスレッドではないんだけど、いろんなイベントタイミングで書き換えまくる。
どのイベントでどういった動きをするかすべて把握しないとデバッグすら困難。
>>36
まさにそう。とりあえずグローバル。
しかもすべてのファイルがincludeする共通ファイルの中で定義する。
カプセル化の概念とか持ち込む方が悪って感じがする。

42 ：

１．推理小説でも読むようにして、もつれた糸の謎を解く。
２．こんなプログラム書く奴は最低だなと思いつつ、解読の喜びに浸る。
３．綺麗に整理して、構造化されたプログラムに書き直す。
４．その後の保守が恐ろしく簡単になって、大儲け！
こんな楽しい仕事は無いと思うがな。　おまいら、どう思う。

43 ：

＞　４．その後の保守が恐ろしく簡単になって、大儲け！
４．その後、安いお金を貰って手を切られ、保守は別会社に
そして１．へ戻る

44 ：

4.その後、保守が恐ろしく簡単になり
『あいつはこんなもんにあんなに時間かけてたのか？』
『最初からそう作れ（初期担当でない事は棚上げ）』
…なら見た事がある

45 ：

>>44
あるあるwww
全俺が泣いた

46 ：

>>42
「直す」というレベルでは不足。
現行システムを問題点を発見するための踏み台であったと考えて、
再構築する。

47 ：

オリーブ油少々

48 ：

>>44
あるあるｗｗｗｗｗｗ

49 ：

>>41
グローバル変数別に悪いと思わんけどなぁ。
なんでもかんでもグローバルにするのはいただけないが。

50 ：

>>49
重要な変数とかは別にいいと思うよ。でもうちの場合はほんとに何でもかんでも。
一つの関数でしか参照されない、今後変更される予定も考えにくいものであっても普通にグローバル。
すべての関数で宣言されたローカル変数とグローバル変数の数が、グローバルの方が多いんじゃないかってくらい多い。

51 ：

>>49
グローバルは悪。
プログラムの規模が現在の二倍/三倍、あるいは十倍に拡大した場合を考慮されたい。
それでも「別に悪いと思わんけどなぁ」などと言われるならば、
こっちも「勝手にしろ。説得する義務なぞないわ」と考えざるを得ない。

52 ：

>>51
別にむやみやたらに使用するのが悪いと思わないということではないでしょう。
節度を守って使えば問題ないということでしょう。

53 ：

グローバル使わないと変数増えんだよバーカ

54 ：

スタックフレーム動かすのがマンドクサ

55 ：

>>52
でもなぁ、おそらくこの世にあるグローバル変数の、少なめに見積もって半分は
いちいち宣言が面倒だからそこにあると思うよ、実際。

56 ：

>>55
否定できねえ

57 ：

>>55
半分じゃすまねえだろ
グローバルに利用される変数なんてごくわずか
普通はそんな変数セッションに入れるし

58 ：

スパゲッティならまだいい。
今俺が面倒見てるのまるでまるでお湯を入れてないカップラーメンみたいだ。
ほぐしようがない。

59 ：

>>58
粉々にしてからソース振りかけて食うとそれはそれで旨いぜ。
現実に当てはめるのは無理だろうけど！

60 ：

>>58
俺んとこにはまるで固やきそば。

61 ：

うちは湯を入れてふやかした後にカピカピに乾かした物がある。
誰もが見て見ぬ振りを決め込んでいるようだ。

62 ：

スパゲティというか
打ち粉つけないで手でちぎったすいとんみたいなのを称して
ソフトウエアだと言い張る団塊とかポスト団塊が仕切ってると
すごいことになるよ。
（工程守らず、セオリーも知らず、材料だけを我流でこねまわすってことな）

63 ：

激マズ店に注文した客は後悔してるに違いない

64 ：

上司命令でこれから明示的にスパゲティを組むことになりそうだ
保守性一気に落ちる予感

65 ：

で、激まずというか腐ってるという事実を公表すると
結構インパクトがある場合どうする？

66 ：

>>65
ガン宣告はお早目に。

67 ：

>>65 墓場まで持っていけ

68 ：

いっそ、競合向けに改善策だけ公開すっかな。
連中が絶対みないチャネル経由で。

69 ：

>>65
今ならインパクト、公表を遅らせると即死薬

70 ：

とはいえ、必要以上い保守性にこだわって
無駄に工数増加させるSEには消えて欲しい
細かすぎる指摘で、作業量が2倍とか何考えてるのかと。
あと、杓子定規にメンテナンスに拘るのも勘弁
そんなユーザーニーズがそもそも無いのに
メンテする人が困るとか言って、作業量増やすな
メンテが自社に来る確証はあるのかと
これで、ウチにメンテが来なかったら
自分らの経営資源使って、他社のメンテのしやすさを確保したことになるがな
正直、経営のことを考えられない技術屋上がりのSEは手に負えない

71 ：

俺は、スパゲッティーコードを引継で全て前任者の作った既バグ
という事にして、（全て責任を擦り付けたw)今はなんとか丸く収まって
来たよw

72 ：

スパゲッティプログラムが出来上がる工程を
本にして出せばベストセラーかもな。

73 ：

>>71
前任者に擦り付けられるなんて幸せな職場だな
うちじゃ、「だけど今の担当はお前だろ？」の一言で撃沈だ

74 ：

バグだか仕様だかもう分からない爺さんソフト。
自分で定義したエラーがクリアできないと夜中に苦情電話。
マッチポンプでヒーロー気取り。
中身はどうみても腐ったそばがき。
早く死んでほしいが、俺より生命力強そうなので逃げるわ。

75 ：

ムカついたのでわざとスパゲティにしたやつを納品したことはある。
で、きれいに書いたやつは自分のＰＣの中に保存。

76 ：

それってなんか意味あるの？

77 ：

綺麗に書いた奴をライブラリやDLL化して自分の開発に再利用する、とかならともかくなぁ…

78 ：

>>70
> 自分らの経営資源使って、他社のメンテのしやすさを確保したことになるがな
お前みたいな奴がいるから、仕様書なしの屑プロジェクトのメンテナンスで
デスマる奴が多発するんだよ。

79 ：

>>77
普通は、自分が書いたコードの著作権は自分には無いので、再利用してはいけない

80 ：

>>70のような技術センスゼロの人間が開発に口を出したりすると
結果プロジェクトが大炎上して技術者を鬱にしてすんだよな。

81 ：

>>79
ありふれた手法(hello worldやframeworkなど)の場合
保護される著作権自体無いから再利用は可能。
マにとってはバグがないことが確認されていることが大事だからね。

82 ：

>>81
フレームワーク自体に著作権がない場合であっても、
フレームワークの実装には著作権が発生するから注意。
そもそも著作権が発生しない程度のコードは
再利用も糞もないという罠。

83 ：

つマージャードクトリン

84 ：

コードを納品するプロジェクトは、普通、著作財産権は発注側が持つことになる。
なので、自分が書いたからといって、勝手に他のプロジェクトで使用してはならない。
これを知らないアホ大杉。

85 ：

>>73
＞前任者に擦り付けられるなんて幸せな職場だな
＞うちじゃ、「だけど今の担当はお前だろ？」の一言で撃沈だ
乙wあまりにもスパゲティー過ぎて理解出来ない部分があったので、
「根本的にこの機能は、まともにテストもされていない為に長期の
運用を考えると障害を引き起こす事は必至です。一層の事この
機能を作りなおした方が良いです。」
と言ってバッサリ前任者のスパゲッティーコードは切り捨て
自分で作ってるよw
自分で作る時は、後で引継ぐヤツの事なんて考える必要が無いから
気が非常に楽。
（この流れでスパゲティーコードが生成されていくのだろうと思ったw)

86 ：

座右の銘にしたい格言
・触らぬ神に祟り無し
・李下に冠を正さず
・郷に入っては郷に従え

87 ：

>>84
”著作財産権”が発生していればねｗ

88 ：

単体テストなんかやった形跡もない。
それどころか設計をした形跡がない。
それでも動いてる何かが納品されてるってふしぎ。
あとでクレームてんこ盛りってふしぎ。
さわりたかないな、んなごみ。

89 ：

>>78>>80
悪いが俺も技術者上がりだよ
別に、保守性を著しく損なうように作れって言ってるわけじゃない
正直、規模がでかい物だと、メンバーだって出来る奴から新人ペーペーだって居るんだから
ごく細部の保守性は妥協すべきと言ってる
上流の設計が良ければ、ある程度のメンテナンス性は自然に確保できるんだから。
俺が文句言ったSEは、技術者はやみくもに技術者は保守性を高めればいいと思ってる奴で
そもそものユーザーニーズや、自社の人的資源を無駄遣いする奴のことを言ってるだけだよ。
そいつの場合、４０代で技術的にはすぐれてるが
経営の感覚がないから、どこまでも細かく突っ走る
既に要件も満たして動作確認されてる所までも、自分の趣味に近いレベルで
気に入らないと言ってコード修正させるんだから、逆に使われてる奴が可哀想
もう４０代で、一応肩書きは管理者なんだから
少しは経営管理とか、そっちの視点も身につけて仕事してほしいってだけ

90 ：

>>89
管理者=PM？なら自分の責任内の話でしょ、担当外ではあるけど。
経営的には要件＋αとか追加要件を呑んで次案件の材料にって考え方は大いにあるよ？

91 ：

ごく細部ってコーディングルール違反とかも妥協しろって感じに聞こえるが
そういうの許してくと、いつのまにかスパゲッティの出来上がりだよ。

92 ：

>>90
脊髄反射でする反論じゃなくて、もう少し理性的に反論しなよ。
言ってることもわからん。
70が言ってるのは「自分のこだわりのために工数を増やしたりするな、
いい年齢なんだから経営的判断も身に付けろ」だろ。
ほどほどに切り上げた方がいい部分は、確かにあると思う。
あなたの言い分なら、問題のSEは、次案件の要件につなげるどころか、
今の要件にこだわりすぎて止まっちゃってると思うよ。

93 ：

給料キッチリ払ってくれて工数確保してくれるなら別に文句はない
サビ残で納期厳しいなら言うこと聞かない

94 ：

>>92
理性的にって・・・
今回の利益分から次回の営業材料増やすってわからない？
営業材料って増やそうにも増やしにくい物なんだよ。
70,89読んでも現Projectが火吹いてる状況って書いてないしね。
89読む限りその人は管理者だろ。
70が知らない所で次期、他案件の動きがあって上からそれの材料作れっていわれてる可能性は考えた？

95 ：

>>92
＞あなたの言い分なら、問題のSEは、次案件の要件につなげるどころか、
＞今の要件にこだわりすぎて止まっちゃってると思うよ。
まぁ、止まることはないんだけどね
現実には、細かすぎる指摘で工数増やすけど
残業でメンバーに負担かけてるから。
そいつがSEやった案件は、どんなに簡単なものでも、残業の嵐が付きまとう
残業して当然と思ってるから
反りの合わない奴は多い。事実使えるベテランがそいつに嫌気さして辞めてるし
今現在、そいつのプロジェクトのメンバーにつくのは
奴隷気質の新人君が中心。
正直、保守性は技術者視点で大切だけれど
労務管理面で、人的資源を大事に扱って欲しいのよ
人がいなくなれば会社として元も子もないんだから

96 ：

70は問題のSEより上位か経営にタッチしてる人物だと受け取ったので、
>>92になったが、そうでなかったらひっこむ。
SEが言うこと聞かないんだと思ったが。
> 70が知らない所で次期、他案件の動きがあって上からそれの材料作れっていわれてる可能性は考えた？
それも書いてないことだから、70がどのような立場かわからない限り、
なんとも言いようがない。
70が社長だったら、無意味な指摘だろ。その可能性も考えたので>>92になってる。

97 ：

>>94>>96
すまん、そいつは管理者とは名ばかりの単なるSE
無論、そいつ次第で次の材料のきっかけを作ることも可能だけど
実際に営業の中心してるのは、もっと上の人間
ちなみに、プロジェクトはよく無駄に炎上してる
なんというか、機能・仕様以外の部分でユーザーニーズを吸い上げるのが下手
もっと問題なのは、向こうの要求に無い金にならない部分でも
良かれと思ってなのだろうか、自己判断で仕事作りはじめちゃうところ

98 ：

あー、ユーザーニーズの吸い上げは俺も苦手だなぁ
拡大解釈して仕事増やしちゃう

99 ：

>>96
人を脊髄反射とか言う前にちゃんと読んでからレスしてくれ。
89読んで
>70は問題のSEより上位か経営にタッチしてる人物だと受け取ったので
だったら素晴らしいよ。
>>97
管理者でもなんでもないじゃねーかｗ
んなもん単に開発者の暴走止められないPMのミスだろ。
もし70が上位（PM）にいるなら70の責任。
SE権限でタスクなんか増やさせるわけねーよ、ましてや自分以外の。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
ビルゲイツ「」←何言わせても勝ち組
プログラマー向けの勉強会
［ﾌﾘｰﾗﾝｽ］ｴﾝｼﾞﾆｱが各地の案件情報を共有するｽﾚ
しーげんご　たのしいです