コードが汚いと開発・修正の工数が10倍になると判明 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
納期に苦しんでいるSEさま必見の情報です。
今すぐコードが綺麗か汚いかを
ツールを使って調査してみましょう >>1
コードがクソなのは設計がクソなのはだからな。 >>3
設計通りに書くのは無能のコーダー
バイト君レベル
設計通りだと汚くなりそうなら提案する
実際に着手して初めて分かる問題点も見つかるだろうし、「設計がクソ」で終わるのは仕事の進め方がヘタクソ
設計の早期修正は他メンバーを楽にさせる点(1人のコストで10人のコスト削減)で重要
勿論その実績をまとめておいて後で賞与面接とかでアピールするんだぞ >>6
>設計通りだと汚くなりそうなら提案する
>実際に着手して初めて分かる問題点も見つかるだろうし、「設計がクソ」で終わるのは仕事の進め方がヘタクソ
報酬をケチるから、そういうバイト君しか来ないんだろ。
良い人材が欲しければ、それなりに払えよ。 どこかの研究か調査で分かったの?それならそのソースは?
昔から割と言われているプログラマーの生産性は数十倍違うってやつは
1950年代だったか1960年代だったかに実際計測して出た数字だから
今でも折にふれて言われているわけで。
>>1の根拠になるソースはどこ?体感()? 割り込み電話と、無駄な会議を減らせば、それだけで生産性10倍いきそうだな。 設計を直すだけならいいけど、そういう奴は大抵仕様を変更しようとするからな。 無能残業して時間報酬相場を下げるな
【知的財産と契約料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒
偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
無能残業
安売競争
利益提供
裁判苦手
対人障害
健康障害
孤独死
偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死 コードが汚いとかわりと関係無くて、関数やクラス分けがメチャクチャとかのがデスマーチになり易いよ。 0と1というビットの反転で済むところが全部 x = 1 - x; なんて書かれていたから
x ^= 1; へ修正するのに手間が掛かり過ぎた。 WebやDBなんてパートがやるべき
【知的財産と契約料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒
偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
無能残業
安売競争
利益提供
裁判苦手
対人障害
健康障害
孤独死
偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死 手入力を増やしてしまう低技術者
なんとかならないかな? >>18
わりとどうでもいい事の例えかな?
最近のコンパイラに掛かれば同じコードに変換されてるみたいな。 >>20
>手入力を増やしてしまう
どういう状況? >>23
そのシステムの画面か、データベースに直接、データを登録するとかじゃないの? よくSEがいう「運用で対応します」ってやつだろw
システム化に失敗しましたって意味でも有る。 >>25
設計や実装のまずさを手作業で修正、ってのは失敗だけどね。
ただ、システム化=オールコンピュータ化では必ずしもない。
機械に任せた方が良い部分と手作業が良い部分との区別は必要。
結果的に殆ど機械化というのも当然あり。
事務システムの移行で、氏名の一部が外字登録されてたケースがあったが、
手作業だと年7人日、機械化すると200万円くらい掛かるってんで、
今でもそこは手作業でやってる。 普通ならメインの処理メソッドの中に、処理Aの呼び出し、処理Bの呼び出し・・・って感じで書くと思うが
とある現場のプログラム見たら、メイン処理の末尾で処理Aの呼び出し、処理Aの末尾で処理Bの呼び出し・・・
って感じで書かれてて、眩暈がした
さらに再帰は全て関数で実現してるし、どんだけコールスタック積むつもりだよwww >>28
すまんが、お前の指摘は
コールスタックだけだよな? 結婚希望者は不適合
【知的財産と契約料金の搾取助長者ばかり】
[受注系SI生涯損害促進者を追放すべき]
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒
偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
無能残業
安売競争
利益提供
裁判苦手
対人障害
健康障害
孤独死
偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
貧困
非婚
離婚
鬱病
早死 コールスタックなんて真っ先にオプティマイズされちまう些細な問題だろ。 話がそれるかもだが、以前ローカル変数で1Mぐらいのバッファを宣言してるのを見てびっくりした。
スタック溢れないの?と聞いたら、ダイナミックスタックだから溢れない。と言われて、さらにびっくりした。 >>33
ダイナミックスタックって何よ?
足りなくなったらヒープから取るのか? >>34
アドレスだけ足りてればメモリはどっかから取ってくるよ。
仮想記憶を勉強してからまたおいで。 初めからちんたら綺麗なコード書いてても時間かかるの同じ >>37
きれいなコードを書くのに時間がかかるという前提が間違ってるよ。
むしろ綺麗なコードを書く人の方が開発速度速いから。
絵がうまい人が、絵を描くのも速いのと同じようなものかもしれないね。
綺麗なコードを書くのが遅いのは、綺麗なコードを書いたことがないから。
書いたことがないから、汚いコードを書く。それを直そうとすると時間がかかるのは当たり前
どうすればいいかわからないからね。初心者が書くのが遅いのも同じ理由。
でも綺麗なコードを書いたことがある人は、前にやったパターンを
なぞるだけだから、最初から綺麗なコードを書ける。だから速い。 デスマにしないとホクホクできないブラックさんが・・・ >>35
お前再帰関数のスレでも訳の分からん事書いてるだろ 関数の最後で関数コールしてるコードでは、普通ジャンプ命令に置き換わってるから、気にすんな。
みんなみんな賢いコンパイラさんが解決してくれてるよ。 >>39
デスマってもともとのスケジュールが悪いのが
大きな原因だけど、
技術力が低いっていうのもやっぱり原因の一つなんだよね。
自分のところの開発フローの効率化も出来ない奴が
他社のシステムの効率化なんて出来ないわけで。 >>43
はぁじゃねぇよw
俺がやったら5分で終わったバグの修正に
いちいち報告文とか書いて、これを修正するべきか?とかいう
やりとりをいちいちやってたからな。
技術力が低いから修正する時間がかかるから
やらなくて済むならやらずにいよう(ユーザー喜ばない)
そのために無駄な時間をかけて、そんなことだから
デスマになるんだと思ったね。 >>44
おまえマネジメントも上流工程もやったことないだろ? >>42
デスマについて多い勘違いだね。
デスマってのは、スケジュールひく前に運命が決まるんだよ? >>48
そうだよね。仕事の速度の問題じゃないからね。 うん。だから最初から余計なミーティングが問題だって言ってる。
ミーティングするにも時間はかかるわけで
簡単にすぐにできることにいちいちミーティングする?
そういう余計な会議で時間を無駄にしてるんだよ。 SEというのは血の巡りが悪いんだから、
プログラマからみれば会議していてもむだ
プログラマの頭の血のめぐりが悪いときは会議でなく散歩だね
会議でじっとしていることが、血行をわるくさせる
会議なんてものはSEの責任逃れ 頭にアホ置いた時点で確定するから始まった瞬間に運命決まってるようなもんだ >>36,40
スタック領域 自動拡張
でググったらすぐでるじゃん。
まさか検索もしないでそんな投稿するなんて思いもしないから、英語で検索しないと出ないのかと思っちゃったよ。
すぐに手を動かさない奴は伸びないよ。 無能残業者へ
SEの職務は、手入力を減らす事だと
わかってますか? 1行目と2行目がまるで噛み合ってない
本人は言いたいこと言えたと思ってるんだろうけど、伝えたいことがまるで伝わらない典型例みたいな文章だな 一行目は二行目以降のメッセージを伝えたい相手を特定してるだけだから
噛み合うとか噛み合わないの問題ではない。 コードが汚くてもコストは変わらん
人月契約の作業者が疲弊するだけ 工数を増やすために汚くしておくんだ
短くきれいで安いのでは困る >>69
プログラミングの価値を、コード量で測ろうとしてるもんな。
重要なのは、改善効果の金額換算だろ。 今時、日立ですらコード量で仕事量ははからないんだが
どこの話なんだろうか 中華の作ったゴミ見るたびに全部書き換えたくなる
つーかあいつら書いたコードゴミすぎてみてるだけで吐きそう 開発終わるとステップ数数えさせられるんだが、今時そんなことしないの? >>73
ステップ数はコストだよ?
同じ機能をある人は100行で作りました。
ある人は全く同じものを10000行かけて作りました。
どちらがコストがかかってるでしょう?
言うまでもなく後者だよね。
バグや機能修正が入った時、100行のコードから該当箇所を修正します。
ある人は、10000行の中から該当箇所を探し出します。
どっちがコストがかかるでしょう?
言うまでもなく後者だよね。
それを理解して、ステップ数を数えてこの人は行数が多い!
たったこれだけの機能をこんなに時間かけて作るんじゃねーよ
大赤字じゃねーか。っていう判断に使うのなら問題ない。 ステップ数が多いほど生産性が高いとかのたまうのが東証一部上場企業のPMだから終わってるわ
いしど きれいなコードだなぁと思ったら異常処理が一切書かれてなかったでござる 異常系は基本何もしないのが唯一解なんだけど、なぜか昔から誤解されてるよなあ。 使うのが自分自身だけなら問題はない
他人が使うもので非対策はゴミ以下 異常系からのリカバリーを要求されるシステムだって世の中にごまんとあんのにな リカバリ出来るのは正常系やで
それを異常系と呼んで場当たり的な対処で済まそうとするから
見るもおぞましいソースコードが出来上がるんや >>79
> 異常系は基本何もしないのが唯一解なんだけど、なぜか昔から誤解されてるよなあ。
わかってるねw
異常系に対するだめなコードは、エラーが発生する可能性があるから
発生した時に何かしなきゃいけない。と可能性がある場所毎に
何か書くこと。その場でログを出力するとかね。
そんなことやるから、あちらこちらに異常系のコードが大量に
生産されてしまうし、見逃しも沢山生まれる。
そんなことせずに、異常になった時に絶対呼ばれる部分があるんだから
そこにコードを一つ、または数個かけばいいだけ。
あとはまれにそれだけじゃ不十分な時に、追加のコードを
書くだけでいいんだよ。リカバリできる異常状態も
まれなんだから、リカバリできる場合に限って対処すればいい。
やり方が正反対なんだよな。 >>84
Windowsで言うところのブルースクリーンだな
復帰不能 >>85
悔しいからって、負け惜しみ言うだけで
消えるなよw >>87
それは論点ずれすぎてるw
わかってないよお前。 俺わわかってる。
要はエンジョイコーディングってことだろ? >>83
そうなんだよね。
リカバリー出来る様にするならそれは正常系なんだよ。
設計のバカが担当が異常系で処理させれば済むって事で
初期の設計に入れてないんだよw エラーを無視すれば、どんなエラーが出ても
続行できる。 >>93
エラーが物理的な要因による物でもそう言えるならあんた帰っていいよ。 >>71
未だにやってるよ
設計もしてないのにステップ数から
見積りとかバカかと言ったら
逆ギレされた 俺は綺麗なコードや汚いコードに基本文句を言わない。
ある程度スパゲティでも構わないし (いや実際には構うんだけど) 苦情や文句を言うこともない。
2ちゃんねるとかで質問者が変な書き方したがっててもいちいち突っ込まない。
同じ書き方で回答を提示する。
しかしそんな俺でも許せないものが一つある。
書き方が一貫してないコード。
特に複数人で修正して回ったようなスパゲティコードは手に追えない。
たぶん納期に追われてプログラマが辞めながら作って行ったらしきコードなんだろうけど、
これだけは本当にどうにかしてほしい。 思想が一貫してれば書き方なんかどうでもいいわ
>>96は多分思想がバラバラなんだろうけど 昔関数作ったら関数仕様書を作るプロジェクトがあった
その場合人は関数を作らないようにするためその関数の中で修正してしまう
こうして数千行の関数が量産されていく
そこで新たに関数を作ろうものなら空気が読めない人間になる
生きて行くって難しい >>99
意図的にそれで手続きが問題ないならたいしたスキルだよ ■ このスレッドは過去ログ倉庫に格納されています