他人が作ったプログラムを修正する時の絶望感

1 ：11/09/15 〜 最終レス ：11/12/06

他人が作った素性の知れないプログラムを修正する時の絶望感を一般の人に理解してもらえる例えを考えてみまえんか？
私が考えたのは↓です
「お前、明日からライバルのラーメン屋にいって、その店のいつもの同じ味のラーメンを作れ。レシピは残ってる生ゴミや残飯から自力で調べろ。もちろん前任者への質問は禁止だ」

2 ：

20年この商売をやっているが、絶望感を感じた事はない。
確かに馬鹿なPGが少なくないことは感じるが、対処できない事はない。
もしそう思うのであれば、まずは自分の能力を疑う事をお勧めする。

3 ：

＞　みまえんか？
↑やっちまった･･･　Orz

4 ：

標準ヘッダ読み込んでもエラーがでるようなコードにはさすがにウンザリだ

5 ：

もとからあったバグまで俺のせいにされて徹夜で直してる時とか、
絶望感しかないよな。

6 ：

>>5
しかも、ラ管(=人力CVS)の履歴を調べたら、エンバグした犯人が、俺のバグのせいだと
会議で吊るし上げた張本人だと判明した時とか。
三菱MDISの無能なE.Zaitsu、お前のことだ!

7 ：

いつも思うこと。。
俺はソフトを組むたびにドキュメントをちゃんとしろだのソフト仕様書を作れだの
コメントをちゃんと書けだのうるさいこといわれてるのに、
他人が作ったプログラムにはまずそういうものがない！
一体どういうっちゃぁ！！(怒

8 ：

え？
俺は楽しいけどなぁ、
コードであれば尚良し。

9 ：

責任持たなくていいんなら楽しいよｗ

10 ：

責任なんて、仕様通りの範囲で動く限りは正常って以外無いだろw

11 ：

>>10
そんな大きな責任負いたくないわw

12 ：

↑プロ失格乙ｗ

13 ：

そもそも仕様が不明。

14 ：

思いっきり書き換えていいならともかく、ソースがあるから短期間で平気だよね
とか言われるのがかなり嫌だな。　元コードを読む分とそれを現有の仕様書と
すりあわせる、更に追加分の仕様を混ぜるとかなるとね、、、
それ以前に作らない人ってのはコード読んで理解する時間とか全く考えない
よな。ノータイムで読めると思っているというかなんというか、、、

15 ：

バカの作ったコードは絶対に引き継ぎたくないな。
正常系しか動かなくて、異常系を流すと取り返しがつかないほどの
ダメージを与えるっていう。
レアケースならともかく、入力データをちょっとミスっただけで人が5000万人死ぬ

16 ：

電力系の制御システムに派遣でかされた時、そんな案件テンコ盛りだったなぁ…
「お前には月単価120万以上払ってるんやぞ!」って言われたが、手取り10万切ってたしな。

17 ：

プロパーから残業代払うから残業しろ・休日出勤しろと言われても、
俺には残業代出ないんだけどっていうのもよくあるな。

18 ：

そもそも

19 ：

馬鹿が書いたコードが読みづらいっていったって限度があるでしょ
オブジェクトごとに事細かに分割して
名前がローマ字や英単語なら分かるとおもうんだけど

20 ：

馬鹿がそんな綺麗なコード書くと思ってるのか。

21 ：

>>19　←コイツ馬鹿な上に世間知らず。

22 ：

グラマな知り合いなんていないし

23 ：

他人が作ったかどうかより、仕様が全て表に見えてるかどうかの方が重要だな。
意味不明な変数の加算処理が、実はまったく関係無い機能の為の前処理だったとか、実際に出くわした事があるんだけど、それを知らずに適当に同じ処理加えて行ったら、とんでもない所で不具合が出やがった。
さすがに意覚えたなぁ

24 ：

コメントが1行も入ってないアプリケーションの修正頼まれたことあったなぁ。
まさに他人に読まれることを怖れているかのようにコメントが1行も書いていない。
なんの関数なのかもコードを読んでいかないといけない。
膨大な時間がかかった。

25 ：

NetBSDのソースコードなんて、著作権フリーの説明以外、一切、一行たりとも
コメントが入ってないソースなんてテンコ盛りだが、とても読み易いよ。
いちいちコメントを必要とするソースを書くのはプログラマとして低能。
変数名や関数名とかの「リテラル」に分かり易い命名しとけば、コメント不要。
むしろ邪魔。

26 ：

まあ、関数名が機能をまんま表してるとか、変数名が目的そのまんまとか
コメントなんて飾りです。　むしろ嘘コメントで紛らわしいので排除してください。

27 ：

バカがマネするから何のための関数なのかと、引数に入れてもいい値くらいは書いとけ。

28 ：

まさに飾りのコメントにだまされた
...True/Falseの意味が字面と逆だと分かったときのガッカリ缶orz

29 ：

それってコメントの有無の必要性とは全然別の次元の話だよね？
ホントにコメントが1行も必要ないと思ってるのは学生と個人企業でこじんまりやってるマぐらいのもんだぜ。
ちなみにxBSDはコミッタが管理してるから破綻するこたぁねーんだよ。
このスレで取り上げられてるような市井のどこの馬の骨が書いたか知らんようなクソプログラムといっしょにすんな。

30 ：

言っても無駄。
コイツらコメント無しのコード判読で泣きそうな思いしてない坊やばっかだから
ごちゃごちゃの意味不明なコードに遭遇して一度でも死にそうな思いしてりゃ「コメント必要ない」なんてゆとりかましてられないっての。

31 ：

>>26<-いかにも金とってないって感じのゆとり

32 ：

>>31
残念ながら、金取って仕事してるんだなｗ
しかもドキュメントは別料金でｗ

33 ：

どうせ100行程度のちっこい便利ツール程度だろ。
「もう納期過ぎちゃっててさぁ、担当者は今韓国に缶詰で定時連絡のみだから・・・、
カネはいくらでも払うから（←嘘）明後日までにおながいします。」とか言われて
1万行以上の超ごちゃごちゃなソースをコメント無しで渡されてみろよ。（実話）
それでもそんな涼しい顔ででるわけ無かろう。

34 ：

一人でやってるようなのはコメントなんかかかないよ。
３０後半あたりでコードの内容覚えきれなくなって破綻すると思うが

35 ：

>>34
ツールとして使われてるのは大抵そこからスタートする
そして気がつけば課内に正式展開されて
不具合対応や機能拡張をさせられる羽目に
その頃には初期verを書いた張本人は既に退職してたりする

36 ：

>>24
最初から作ったほうが早いじゃん

37 ：

ま、実際のところ、
赤の他人が作ったしょーもないノーコメントのソースを修正するなら、
｢しめた！｣と喜ぶくらいじゃないとフリーじゃやっていけんよね
いかんせん仕事あってのフリーだからね。

38 ：

元ソースの品質を工数に盛り込むことが出来ないからな
ひどいソースを書いても、そんなソースを受け入れても
本人は痛くも痒くもなくてリスクは全部修正者に押し付けるだもんな

39 ：

i=1; /* iに1を代入する */
こんなコメントはいちいち要らないんだよ >某三菱MDIS
目的は何の為にそんな代入するのか? "1"というmagic numberの意味を書けよ。
それでコメント率25%以上とかコーディングルール決めても、欠陥システムの
オンパレードなんだろうが!?

40 ：

ジョークとしか思えないなw

41 ：

>>38
言っちゃ悪いけどｗ
お前が選んだ職業なわけであって。　ゴミみたいな仕事やってんのが悪いんじゃね？
>>39
あるある
ソースコード中にマジックナンバーをただのひとつでも入れる奴は、AUTO
けど君もゴミみたいな仕事やってんのがわるいよね

42 ：

ゴミみたいな仕事にもありつけないニート君が何言っても…

43 ：

>>42
>ニート
↓
>>41
>ただのひとつでも入れる奴は、AUTO

44 ：

オートかよｗ

45 ：

一個の長い関数内部で順にいろんな処理を行なう場合は、大まかな流れぐらいコメント入れとけ。
でないと他人はその関数内から呼んでる関数の飛び先をひとつひとつ読んでいかないと全貌を把握できない。
/* 複数の選択をキーにDBを検索*/
/* 結果からバイアス計算 */
/* パラメータをセットして試験実行 */
　/* 試験1（オフライン） */
　/* 試験2（オンライン/サーバートリガ）*/
　/* 試験3（オンライン/ユーザートリガ）*/
/* 結果判定 */
/* 収集したデータを各所へ書き込み（書式加工） */
/* ローカル */
/* サーバ */

46 ：

// よくわからないけどとりあえず動いてるんでこのままとする
↑
こんなコメント書くなｗｗｗｗｗ

47 ：

/* 以降の処理は動作は保証しない（不具合は自力で解決してください） */

48 ：

i=1; // 何故か2回実行しないと正しく動作しない時が有る
i=1; // 何故か2回実行しないと正しく動作しない時が有る
…volatile宣言すべきなんじゃないの?

49 ：

>>43
アウトをAUTOと表記するのは最近時々見かけるスラング
とはいってもこの子の場合はマジで書いてる気がするが
kardだし

50 ：

アウトだったのか
マ板だけに普通にautoと読んで自動変数がなんの比喩なんだと悩んだ

51 ：

いや、こいつはVIPPERだからこういう書き方する
AUTO自体はかなり前から使われている

52 ：

>>51
常日頃からそういう唯我独尊なコードの書き方してんだろ。
コメント入れろって書いてあんのに修正箇所にコメント一言も入れなかったり、
{}の記述が　
kansuumei(){
}
で書かれたプログラムを自分のスタイルを押し通して以下のように書いたり
kansuumei
(　void　)
{
}

53 ：

>>52
餌やり禁止

54 ：

kusakabe(void){
　　　　return NULL;
}

55 ：

>>47
それ、あちこちで書いてるのオマエじゃね？

56 ：

他人でも１人で書いたコードを見る分には
癖や統一感があるから、まだいい
統一感も無く１０人くらいが、個々自由に書いてるコードを修正するときの
脳の疲労は半端ないｗ

57 ：

個々自由に書いてるコードなら、自分も自由に書けるから楽だな。
他人の癖を真似する方が疲れる。

58 ：

ニンゲンの書いたコードならまだましだが、Excelから自動生成しました的なコードを
その自動生成ツールなしで解析・修正しないといけないときとか、どんな刑罰だよと思う。

59 ：

>>57
バグ潰し専門だから
俺は１０人の癖を真似して書いてるぞｗ

60 ：

>>58
COSMOSとか、新幹線の制御システムがソレだったな。
RATFORだか何だか知らないが、FORTRANから機械的に変換してて、
関数名とか変数名とか、全部英数6文字の組合せ。
>どんな刑罰だよと思う。
電力とか鉄道関係の仕事は、金輪際、お断りすることにした。
自社内の人間で開発しろよな。

61 ：

>>60
最初からFORTRAN走らせればいいじゃない。
って思った。

62 ：

>>1
「ソースを解析するツール」でも作れば？
うまく作れば、見たくないソースの自動修正なんていうのも、有りかと...。

63 ：

>>62
>うまく作れば
「よくわかんないけど想像だけで書きました」みたいなﾚｽは結構。

64 ：

最初のCOSMOSのころはまだ77規格すら無かったしな。
英数6文字ってのはRatforのじゃなくてFORTRANの制限だよ。
新幹線のシステムをスクラッチからリプレースする、
なんて奇跡のような予算がどっかから出ない限り
Ratforのソースをメンテせにゃなるまい。
新規分までそれで書くのはよしたい気持ちはすごーくわかるが。

65 ：

うっかり違う文字コードで開いて上書きしちゃったw
２バイト文字が全部化けて、
コメントが意味をなさなくなったよ

66 ：

他人のコードを解析するときこそ評価を得るチャンスじゃないか！
この仕事は他人との評価の比較が難しくて
時には仕事できなくても残業時間だけで評価されたりしやがるけどｗ
こういうときこそ実力の違いを見せ付けるチャンスだと思う

67 ：

そんなんで評価しねーよ。
そもそもソースあるんだから、いちから作るより楽だろ？

68 ：

一から作った方が楽な場合もあるだろ。元のコードが
あまりにも酷い場合は。

69 ：

それはPGの立場で見た場合の評価であって、
評価をする側の人間の立場で見たときには >>67で書いたとおり。

70 ：

前派遣で行った会社で
言語PHPなのにforeachも録に使えないようなアルバイトが
「これを参考にして作ってください！」
って言って渡してきたソースを見たときは絶望した…
しかも、
「サンプルがあるから早くできますよね！」
とか異常に出来上がりをせっついてきてたけど
修正するのに時間かかって早くできるどころの騒ぎじゃなかった

71 ：

レベル低いヤツって持ち出す実例もレベル低いんだな
糞派遣（藁）
日本語から出来てねぇ

72 ：

>>71
レベルたっけぇ〜www

73 ：

>>66
そんなんが評価されるなら、他人との評価の比較が難しいにならん
>>70
急かすようなところだからクソみたいなソースが散乱するんだよね
それこそクソみたいなソースコードを取り合えず早く出すのはやればできるし

74 ：

構造化されてないCOBOLのコードを渡されたときは泣きそうになった

75 ：

>そもそもソースあるんだから、いちから作るより楽だろ？
↑
ど素人乙
いちから作った方が楽な場合なんていくらでもある。

76 ：

>>75
だったら穴だらけの低能Windowsをちゃちゃっと1から作り直しちゃってくださいよ。

77 ：

いちから作った方が楽な場合なんて無いよ。
そう思うのは勝手だけど、どんな系でもどこかに複雑さが隠れてる。
つうか、テスト仕様書とか試験結果報告書とか全部作るの考えたら、少しの修正だけで済ませたいと思うよ。

78 ：

自分が書いたソースならば、な。
スタレの通り「他人」がそれも低レベル文系君が書いたソースなら、>>75 さんの
言う通り。ってか人口的に、国公立情報系なんかより私立文系出の似非グラマの
方が圧倒的に多くて、捨てて1から作り直した方がdiffもCVSもスリムに成るケース
の方が多い。
>>77 みたいな「勘違い」をMDISも二言目には言ってたが、アノザマ。
結果が全てを物語ってる。

79 ：

>>78
おまいそんな事言っても、上は予算出してくれんの？
いちから書き直した方がマシなんてのは実務上無いんだよ。　素人君。

80 ：

採算が合うならやると思うよ。

81 ：

いまだにPC9801シリーズが現役で稼働してるとか、奴らマの意見なんざ完全無視だろ。

82 ：

>>78
現実問題としてそういうソースが存在するところでは
一から作り直したほうが早いというのは大体ありえない
そういうところは
・仕様書が残ってない
・テストは修正した処理しかやらない
・細かいログ出力や潜在してる不具合も含めて完全再現が必要
・一から作り直しにゴーサイン出す人に取って作り直しのメリット0
ってなってるから無理

83 ：

そして三菱MDISの二の舞ww

84 ：

ソフトウェアってのは過去の資産を使いまわすというのがビジネスの基本なんだよ。
何故インテル＋マイクロソフトの糞コンビがいまだに幅を利かせてるのかを考えれば分かるだろ。
作り変えが許されるなら、ハードの下位互換性なんて誰も気にもしないだろｗ

85 ：

はあ？

86 ：

リファクタリングは何度も繰り返してるが…
そもそも人手が足りないからといって、畑違いの文系君にプログラミングさせる
狂った国は、日本だけじゃないの?

87 ：

発展途上国から出稼ぎに来てるPGだって、一応情報系の大学出てるからなぁ。

88 ：

>>84
じゃあ使い回せないもん作ったヤツはクビでいいな

89 ：

使いまわせるものって何？
オブジェクトとヘッダとreadme？

90 ：

再利用とはいうけど、使い回すにも使い方覚えるためのコストがかかるしな。
使いこなせるまでの平均的学習時間でも記載されてれば別だけど、そうでなきゃリスク買う事になるよな。

91 ：

>>88
使い回せるかどうかは、使う側の裁量次第だけどな。

92 ：

使い回さない前提の設計が流れてくることも多い
拡張性皆無の設計仕様作るSEが絶滅するだけで、開発効率は数倍はねあがるだろうと

93 ：

妙に汎用的に作ると逆に苦しむことにならないか？

94 ：

>>91
使い回しにくいものを使い回す側の裁量でうまく使い回したことを評価されるといいけど
実際は使い回しにくいかどうかが評価の対象になるというのは聞いたこと無い
使い回して早く直したかどうかのみで評価される
だからこういうスレの流れになる

95 ：

>>93
それは、汎用性が無いからだろ。

96 ：

万能関数と汎用的な関数とは、全くの別物だからな。

97 ：

汎用性のあるものってやっぱり効率化とは逆の道だよね
コードの長さ的に

98 ：

>>97
そんなことないぞ。
複数プラットフォーム対応でコード量増えるとかの例外はあるけど。
「汎用」という名の元になんでも詰め込むやつがいるけど、それはダメだ。
むしろ、どこに持っていってもうまく嵌るように、汎用的じゃないコードは
削ぎ落とした小さなコードになることの方が多い。

99 ：

追記
UNIXの哲学にもあるけど「一つのことを、うまくやる」コードをたくさん書いておけば、
それらを組み合わせて使うのは比較的楽。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
49: イナズマイレブン (9)
50: 刑務所でプログラマを養成 (307)
2: 【２ちゃんねる全板】S-BananaのSって？【移転します】 (18)