人気サイト様 最新記事

博士ちゃんねる ヘッドライン

レスの強調ウゼェー!というドクターへ

レス内の強調表示をOFFにする コチラをクリックして切り替えてください。設定は30日間Cookieに保存されます。
現在のステータス:強調有効

ソースコードが汚いことで発生する問題点 @ [プログラマー板]


ソースコードが汚いことで発生する問題点 @ [プログラマー板]
1: 仕様書無しさん 2016/06/01(水) 00:51:12.80 .net
修正するたびにバグが増える。
修正にかかる見積が大幅にずれる
2: 仕様書無しさん 2016/06/01(水) 03:42:41.54 .net
ソース汚いのは初心者にありがち。
3: 仕様書無しさん 2016/06/01(水) 05:15:53.72 .net
従業員が辞めていく
5: 仕様書無しさん 2016/06/01(水) 10:26:08.61 .net
>>1
ちょっとした修正でも、ソース解析やテストに膨大な時間がかかるから、ユーザにとっても保守費用がかさむ。

おそらく、きれいに作っていれば、DBのデータとか設定ファイルの変更で対応できそうなことを、数日かけてソース解析して改修してるシステムを実際に見たことがある。
正社員で入ってきたプログラマが入社1週間くらいで辞めてた。
6: 仕様書無しさん 2016/06/01(水) 13:50:27.02 .net
やる気がでない
7: 仕様書無しさん 2016/06/01(水) 14:10:28.90 .net
まさに今の俺
資料はおろかコメントすらないVB6.0のプロジェクトを引き継いじまった
8: 仕様書無しさん 2016/06/01(水) 14:50:45.69 .net
ソースが仕様です! (`・ω・´)キリッ
9: 仕様書無しさん 2016/06/01(水) 15:19:46.40 .net
きれいに作ってたら納期に間に合わん。
短期で過剰の成果を要求するな。
10: 仕様書無しさん 2016/06/01(水) 19:17:15.73 .net
>>9
開発と保守の違いがわかってないおばかさん
16: 仕様書無しさん 2016/06/01(水) 22:40:12.92 .net
>>10
大抵の開発は、保守と同じようなことしてるけどな。
プロトタイプの開発でもない限り。

バグがあったら修正するわけだし、ソースコードが汚いと自分で書いたコードに苦しめられるw
13: 仕様書無しさん 2016/06/01(水) 22:26:06.73 .net
>>9
今はソースコードが汚いことで発生する問題点の話をしている。
綺麗にするかどうかは別問題
11: 仕様書無しさん 2016/06/01(水) 20:51:12.62 .net
if() {
	if() {
		if() {
			if() {
				if() {
					if () {
					}
				}
			}
		}
	}
}
12: 仕様書無しさん 2016/06/01(水) 21:14:13.31 .net
汚い奴ソースを書く人は概して頭が悪い
コードスメルを認識できないほと頭が悪い
15: 仕様書無しさん 2016/06/01(水) 22:28:44.04 .net
汚く作れるのってある意味才能だよな
18: 仕様書無しさん 2016/06/02(木) 18:29:38.03 .net
仕様が曖昧で二転三転する中、なんとかそれっぽいものをでっち上げたら、それぞれのメソッドからの返り値が迷路のように複雑に絡み合う、超難解ソースが出来上がりましたとさ。

メンテ不能だから、これ。
19: 仕様書無しさん 2016/06/02(木) 20:50:49.25 .net
それは仕様変更の時に、機能を満たす事だけ考えて、「まいっか、後で直せばいいや」と、場当たり的な対応してるからです

場当たり的な対応をせざるを得ない場合であっても、メモるなり、TODO書くなりすればよいのです
後に直す事を覚えて、徐々に直していけば、どんなに仕様が二転三転しても、そこまで酷くはならないです

もう一度繰り返します
殆どのケースでは「まいっか、後で直せばいいや => メモを取らない」が元凶です
22: 仕様書無しさん 2016/06/03(金) 02:08:30.83 .net
>>19
TODO: だらけのコードになるわけですね
21: 仕様書無しさん 2016/06/03(金) 01:00:09.32 .net
>>19
動いたからOK。
あとで直す?何を?動いているのに?
26: 仕様書無しさん 2016/06/03(金) 20:09:19.88 .net
>>25
それは違うよ
派遣が多いから「どうせずっとかかわるシステムじゃないし」と思って雑になるんだよ
ソースが汚くても苦労するのは自分じゃないからね
酷い現場だとわざと汚くしたりするのさ
23: 仕様書無しさん 2016/06/03(金) 03:30:35.82 .net
クソコード書く奴等ってなんでまともな形にせずに逃げるの?
25: 仕様書無しさん 2016/06/03(金) 05:23:26.56 .net
>>23
俺も長年疑問に思っていたが、だんだんわかってきたよ
彼らは"まともな形"が分からない人たちなんだよ
「動いたこれでよし」と思うからそれで終わってしまう


>>21みたいに、何を直すのか分からない
あなたは知ってそうだから、それでいい
24: 仕様書無しさん 2016/06/03(金) 04:57:37.11 .net
契約終了と言ったのはそちらですよ
29: 仕様書無しさん 2016/06/03(金) 21:39:13.77 .net
自宅で書くコードは美しいんだけど職場だとどうしても汚くなる
仕事だとしがらみが多すぎてな
38: 仕様書無しさん 2016/06/04(土) 19:22:38.02 .net
理論は完璧そうなあいつほど、ソースがクソ汚いはありがち
39: 仕様書無しさん 2016/06/04(土) 19:34:57.67 .net
>>38
そういうやつは文章を書かせると難解な文章を書くから見抜けるよ。
44: 仕様書無しさん 2016/06/10(金) 20:46:17.90 .net
>>39
頭混乱してるから文章回りくどいよな
42: 仕様書無しさん 2016/06/10(金) 03:37:11.48 .net
綺麗に書いたコードでも3ヶ月後には汚くみえる
ただ元々汚いコードは3ヶ月後には解読不可能になる
45: 仕様書無しさん 2016/06/10(金) 21:21:27.38 .net
汚いと解析できないから、改修時にビクビク怯えてコピペで追加する汚いコードが増える
綺麗なコードは簡単に見てわかるから、手を入れられる
46: 仕様書無しさん 2016/06/10(金) 23:04:56.06 .net
改修のしやすさは綺麗汚いじゃなくて設計と規約が良くできてるかどうかだろ
47: 仕様書無しさん 2016/06/10(金) 23:16:28.41 .net
設計と規約が良くできていることを綺麗だって表現するんだよ

水が飲めるかどうかは、綺麗汚いじゃなくて、不純物が少なく透き通っているかどうかだろ、って言ってるようなもの。
48: 仕様書無しさん 2016/06/10(金) 23:53:22.95 .net
つまり美少女はウンコしないのに美少女のウンコなら食えるって言うようなものだな、了解した
55: 仕様書無しさん 2016/07/05(火) 16:00:31.84 .net
コード書きながらこれ汚いなって思うけど、ローンチしたらどうせプロジェクトを外れるわけで、わざわざ時間をかけて綺麗にしようというインセンティブがない
56: 仕様書無しさん 2016/07/05(火) 16:07:03.85 .net
>>55
開発プロジェクトを開発が終わったらはずれる立場を繰り返していると、運用・保守の観点がなかなか身につかない。
57: 仕様書無しさん 2016/07/05(火) 18:24:36.38 .net
>>56
運用保守を含む契約での仕事もしてるから大丈夫
>>55は開発で契約したときの話
59: 仕様書無しさん 2016/07/06(水) 10:54:49.28 .net
まぁ2度と関わらない会社の案件ならそうなるわな
60: 仕様書無しさん 2016/07/06(水) 19:30:33.13 .net
ソースが汚くて保守せいが悪い?
工数が増えていいことじゃないか。
67: 名無しさん@そうだ選挙に行こう! Go to vote! 2016/07/10(日) 13:39:17.75 .net
>>60
正確に見積もれる程度の汚さで収まってるならな。
実際は地雷踏まされたり、延焼したり、二次遭難したりするのが普通だからなあ。
61: 仕様書無しさん 2016/07/06(水) 19:39:30.37 .net
ソースが汚ないぐらいで工数が増えるってどんだけ低スキルなんだよw
63: 仕様書無しさん 2016/07/06(水) 20:24:19.84 .net
汚いだけなら整形アプリで整えちまえば済む。
64: 仕様書無しさん 2016/07/06(水) 23:31:05.95 .net
>>63
「汚いコードとは、整形されていないコードのことなのだ!」
管理人より:分かりづらい流れですが、汚いコード=整形されてないコード、「だけ」ではありませんので、念のため。
68: 仕様書無しさん 2016/07/11(月) 18:04:56.13 .net
インデントがめちゃくちゃで}が余計にあるのか足りないのかわからなくなる
73: 仕様書無しさん 2016/07/13(水) 21:50:55.33 .net
>>68
あるあるw
69: 仕様書無しさん 2016/07/11(月) 18:21:44.82 .net
名前と意味と役割が合ってないと困るな
isXxxとisNotXxxが逆の意味とか、未使用だったDBカラムに全く別の意味持たせたりとか

そいつの書いた物が全部信用出来なくなる
77: 仕様書無しさん 2016/07/13(水) 22:00:40.21 .net
>>69
今日はそれではまったw
validationなんちゃらという名前なのに、validationに全然関係のない値をこっそり変更するの、やめてほしいわw
管理人より:「validation」というのは、本来の意味とは若干違う使われ方をしてますが、ここではユーザー入力値のチェック、または変換・確認のこと。
70: 仕様書無しさん 2016/07/13(水) 20:12:56.89 .net
if文のなかで目茶苦茶に5個くらいandとorが入り交じったわけわからん判定文がある

それが1つのファイル内に30個以上ある
72: 仕様書無しさん 2016/07/13(水) 21:25:06.75 .net
>>70
普通はネストでわかりやすく分割するんだけどな。
74: 仕様書無しさん 2016/07/13(水) 21:54:36.21 .net
>>70
こういうのはお好き?
(_はspacex2)
if_((
_____(expression1)
_____&&
_____(
______(expression2-1)
______||
______(expression2-1)
_____)
____)
___) {
...
}
75: 仕様書無しさん 2016/07/13(水) 21:55:08.23 .net
あ、なんか括弧が1つ余分だったw
76: 仕様書無しさん 2016/07/13(水) 21:57:57.39 .net
>>74は実際にはやらないけどね

expressionの評価値を簡潔でリーダブルな変数に格納しておいて
if (enabled && (published || deleted)) {
}
みたいな感じで俺なら書く
71: 仕様書無しさん 2016/07/13(水) 21:02:20.21 .net
ふっ
そんな条件式の途中がコメントアウトされてて、似た様な式が幾つもあるみたいな奴なんかザラだぜw
80: 仕様書無しさん 2016/07/14(木) 07:20:47.09 .net
改行LFとCRLFの混在ファイルは汚ねぇの一言
いったいどんなエディタ使ったらそんなハイブリッド風になるんだよw
vimで表示すると^Mだらけなんだよ!
81: 仕様書無しさん 2016/07/14(木) 16:30:55.79 .net
vimってダメなテキストエディタなんだな
83: 仕様書無しさん 2016/07/14(木) 20:02:48.27 .net
>>81
vimはダメやないけどvim使いがダメなんやで
84: 仕様書無しさん 2016/07/15(金) 00:49:36.44 .net
>>81
emacsよりマシですわ
管理人より:古来より続く「vi」 vs 「emacs」の終わりなき闘争。テキストエディタを巡る争いは根が深いのです。秀丸勢の管理人、低みの見物。
改行用の文字はふたつあり「LF(ラインフィード)」と「CR(キャリッジリターン」。これはタイプライター時代の名残で、「末尾で改行して1行下に移動」「キャレットを先頭に戻す」をそれぞれ意味しています。PC時代では当然ふたつもいらないのですが、なぜかOS間で差異が激しく、Linux系と今のMac…LF、Windows…CRLF、昔のMac…CR、となっております。今のMacはLFであってる?
4.15追記:公開後に思い出したので追記。昔のDOCOMOデコメール(2012年ごろ)は、メールヘッダがLF、本文がCRLFじゃないとメール本文の中身が空になってメールが届く仕様でした(通常メールヘッダはCRLFが正しい)。なんにせよ「DOCOMOだけなぜ空なのか」がよくわからず、解明するのに2日かかったものです。当時は、通常のプレーンテキストのメール、添付ファイルありのメール、デコメール(htmlメール)、テンプレート使用のデコメール、さらにスマホの場合…が携帯各社ちょっとづつ仕様が異なるため、それに加えて当然通常のメールクライアントへの対応もせねばならず、だいぶん大変でした。
91: 仕様書無しさん 2016/07/16(土) 15:33:17.43 .net
例外的な機能があったとき、無理やりマニュアル通りのやり方に合わせる・・・素人

マニュアル通りにやるには何が足りないのかを考え、問題点を、例えばフレームワークのプラグインなどを作成するなどして解決し、マニュアル通りのやり方ができる仕組みを作る ・・・ これが本来のプログラマ
97: 仕様書無しさん 2016/07/21(木) 06:34:18.22 .net
>>91
英語できない人は必ず前者を選ぶ
なぜか分からないけど
98: 仕様書無しさん 2016/07/21(木) 12:29:48.02 .net
どんな事にもすぐに「英語出来ない人は~」と言う
なぜか分からないけど
106: 仕様書無しさん 2016/07/29(金) 01:29:31.98 .net
>>98
英語できない奴はな、避けるんだよ
小中学レベルの英語力があれば読める、最悪グーグルさんに翻訳してもらえばいいだけなのに英語ってだけで一文字も読まないんだ
ググって一番上に出ててもな

別に英検何級レベルだとか難易度の話じゃない
単純に読まないからタチが悪いんだ
エラー文さえ読むの放棄する奴とかどうしろと
114: 仕様書無しさん 2016/08/07(日) 10:31:58.69 .net
>>106
エラー文を読まないのは単なる習慣だと思う。
一番最初に習ったときにとりあえず無視していいからとか、おまじないみたいなものだからとかでスルーしたまま、ある程度習熟した後にそういうものの意味とかをきちんと教わらなかったり、自分から学ぼうとしなくて手癖で続けてきたような人だと読まない、無視する。
155: 仕様書無しさん 2017/01/05(木) 10:13:42.18 .net
while文の中に多重for文があるのに、全体的にインデントがメチャクチャなので、プログラムの全体像の把握が困難
その中にはif文で細かい条件がいくつも指定され、一定条件を満たすと大元のwhileを抜け、後続処理を行うという変な作り
結果、ループを抜ける条件が多岐にわたる、かつ、それらのデータパターンをまるで網羅しておらずバグ発生しまくり

作った奴死ねよと本気で思った年末だった
156: 仕様書無しさん 2017/01/22(日) 15:25:07.20 .net
インデントは直しゃいいし、実際に条件が複雑ならしょうがなくね?
157: 仕様書無しさん 2017/02/13(月) 03:35:53.28 .net
ちゃんとオブジェクト指向なり守ってたらどんなに複雑でもそんな多重ネストになるわけない
ネストなんてサボって二重、それもスクロールせずに表示できる行数内で済むレベルのみ
三重超えるようなら設計がおかしい
144: 仕様書無しさん 2016/10/19(水) 00:21:15.61 .net
命名規則やコーディング規約を守っていても糞設計だと汚くなる
145: 仕様書無しさん 2016/10/19(水) 00:49:57.91 .net
クソ設計を直してもいい文化ならば、徐々にリファクタしていけば、だんだん綺麗になっていくよ

クソ設計&コード触るな!文化が全ての元凶
146: 仕様書無しさん 2016/10/23(日) 11:32:23.79 .net
>>145
でも直すの禁止なんだよなあ
148: 仕様書無しさん 2016/10/23(日) 20:35:19.15 .net
>>146
いや、直すのは別に禁止じゃないんですよ~
1年前の汚いクソが、度重なる改修を経て、今ではかなり綺麗になってきた
実体験を元に語ってますよ~
149: 仕様書無しさん 2016/10/23(日) 22:56:07.66 .net
>>148
誰でも自分のクソは綺麗にみえるらしいよw
147: 仕様書無しさん 2016/10/23(日) 18:27:24.64 .net
>>145
クソに別のクソが混ざるだけw
お前をクソミクサーと名付けようw

管理人ね、ついこないだ8年ものの社内システムを2年ぶりにメンテしてたんです。
8年前に作ったのは確かに管理人なのですが、8年前の自分のコードというのはもう平安時代の古文書を解読する気分ですよ。
そのうえ、8年の間に当初予定していた機能は大幅に追加され、方向性は180度は言い過ぎでも150度くらい変わり、そのうちの8割くらいは今はもう使っておらず、データにも謎のフラグとか山盛りでなにがなんだかよくわからない。

過去の自分がどんな意図を持ってこの処理を書いたのかよくわからず、「これいらないんじゃない…」と思って削除したり修正したりすると、思わぬところでバグが出る。そうだった、これの予防策でここをこうしてたんだった…なんてことはけっこうあるので、ウカツにいじれない。怖い!
しかし、このやっつけで増築しまくって、なんで正常に動いてるかよくわからないシステムが、過去に売り上げた額を考えると、ナントカとハサミは使いようだなと思います。

自分で書いたのでさえ年月が経つとこうですから、他人が書いたものともなれば、阿鼻叫喚です。

こうなる原因はいっぱいあるんですが、基本的にプログラマーは新規開発に比べると、メンテナンスはあまり情熱が持てない、ということがあります。
予算獲得の説得力としても、メンテ自体はお金を生まないため説得もしづらい。メンテというのはお金や機会の損失を避けるためのものだから重要なんですが、しかし新たにお金を生みだすものではない。苦しい。
マよりもインフラ関係のエンジニアの方は、もっとこのへんがツライです。

メンテというのはめんどくさいんですよね。
運用中のサービスに変更を適用する前にテストは散々やるんですが、それでも変更箇所が原因でバグることはあります。あ、そうだった、ここを変えたせいで(すっかり忘れてたけど)ここがおかしくなったのか…、ナンテコッタ…。('A`)
例えて言うならそれはハリ治療に似てるというか、クビのところにハリ指したらヒザの悪いのが治るんだけど、代わりに肩こりがひどくなった、みたいなね。マのひとはこの感覚わかりますよね?

本心を言えば、今の基準に合わせて過去のコードもぜーんぶ修正できたらいいのですが、マというのは3ヶ月くらいたったらもう別人のコードになるのです。忘れるという意味ではなく、書き方自体が最適化されていくからです。
昔はこれでいいと思ってたけど、3ヶ月もたてばもっといい方法があるんじゃん!となるのであって、これは誰でもそんな感じだと思うし、またそうでなくてはなりません。
同じ手法に固執してたら進歩もないから、そこは別に良いのですが、しかし!過去の自分のコードと現在の自分のコードはどんどん乖離していく。

だから、ある段階でマは悟るのです。
もうキリがないから、適当なところで妥協しよう…と。

マというのは繊細さと図太さを併せ持たなくてはやってけない職だということが、伝われば良いんですがねぇー。
4.15追記:なんか公開時間の設定間違って変な時間に公開されてしまいました。21時の更新待ってた方、ゴメンネ。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
Dustin Boswell Trevor Foucher
オライリージャパン
売り上げランキング: 352



人気サイト様 最新記事

博士ちゃんねる ヘッドライン

    • ※1 : ドクター・ノオ・ネーム
    • 2018.4.15 0:26
    switch caseでいいのに、
    わざわざ順番固定の関数ポインタ配列にして
    ソースを綺麗にしましたって言うやつなんなの?
      • ※5 : ドクター・ノオ・ネーム
      • 2018.4.15 8:35
      >※1
      enumと連動していて追加や削除が行われた時に
      switchだと対応箇所がわかりにくくないです?
    • ※2 : ドクター・ノオ・ネーム
    • 2018.4.15 0:48
    コードと本人のデスクの綺麗さには相関関係があると思ってる。
    貯まったペットボトルでデスクの上がカッパドキアみたくなってる奴のコードは本当酷かった。
    • ※3 : ドクター・ノオ・ネーム
    • 2018.4.15 0:48
    本当に難しい問題だと思う
    逆にIT先進国のアメリカではどうやってるんだろうか?
    • ※4 : ドクター・ノオ・ネーム
    • 2018.4.15 2:04
    アメリカはLINTでかなり強力な規約を強制してくるスタイルが多い。
    精神論で対応しようとする日本人とは考え方そのものが違う。
    • ※6 : ドクター・ノオ・ネーム
    • 2018.4.16 2:39
    ネストの深いループから一気に抜けるのはフラグとかでどうにかするんじゃなくて goto を使えと。goto のある言語はここと、資源開放が必要になるエラー処理が goto の使い所ですよと。まあ C は自前で資源管理やらねばならんから goto は使いますよね。

    ネストが三重になったら何かがおかしいと教条的に言うやつは goto 使っちゃいかんと複雑怪奇なフラグをこねくり回して結果非常に読みづらいコードを書くやつのごとし。3次元の座標処理で全部の点を舐めるなら三重ループが自然だしな。
    • ※7 : ドクター・ノオ・ネーム
    • 2018.4.16 3:07
    プログラミングの綺麗さって数学の成績と関係あるのかな
    論理的思考と問題解決能力が必要そうだし
    • ※8 : ドクター・ノオ・ネーム
    • 2018.4.16 8:50
    >※6
    input P(Nx,Ny,Nz)
    for nx=1...Nx
    for ny=1...Ny
    for nz=1...Nz
    P(nx,ny,nz)=f(P(nx,ny,nz),...)
    end
    end
    end


    単純なボクセルデータなら上みたいな三重ループが適切だけど、スパースな体積データやポリゴンデータの場合は座標的にベクトル化した方がいいと思う。
    • ※9 : ドクター・ノオ・ネーム
    • 2018.4.19 10:36
    Android2.x時代に設計が無能でAndroidガイドラインを無視した仕様書。エクセルでイメージされたデザイン。
    意見しても「顧客の印鑑が押されたから変更できない」で終わり。クソコードを生成する作業になったわ。
    • ※10 : ドクター・ノオ・ネーム
    • 2018.4.20 23:50
    > クビのところにハリ指したらヒザの悪いのが治るんだけど、代わりに肩こりがひどくなった
    客「クビに針さすだけなのに何でこんなにコストかかるんだ!」
    マ「クビに針さしても人体のどこにも影響ないのを確認するのに工数かかります」
    客「そんなの無駄だとっととやれ!」
    マ「はい」

    客「肩こりが酷くなったじゃないかどうしてくれる!」
  1. トラックバックはまだありません。


コメ欄での議論はおおいにけっこうですが、当サイトではドクター同士の罵り合いは禁止となっております。反論する際には、相手の意見・人格を尊重し、どうぞ冷静に。