ソフト業界全体の問題です。

ソフト業界全体の問題です。
『バグがないソフトなど無い、あって当たり前』という感じですが、
普通に考えればおかしな話ですよ。
お金を頂いて、商品を提供するのだから、完璧な商品でなければなりません。
購入前に、お客様がバグに納得していれば別ですが、そのためには
その時点での概知のバグを公開していなければなりません。

バグがあると言う事は欠陥商品な訳で、欠陥内容を詳しくしりたかったら
金払えなど言語道断。
ソフトウエア以外の商品でこんなのあります？

カレー

デリヘル

>>1
残業大変だけど頑張ってな！

設計をきちんとしようねまぁむりだけどゴミSEばっかじゃなﾃﾗﾔﾊﾞｽ

まぁ世界一のソフトウェア会社の商品がバグだらけやからな。

バグの公開で金取る企業＆ソフトウェアって、具体的になに？

ソフトウェアでは、他分野以上にマニュアルを厳密に書くべきなんだろうな。
そこに書かれた手順、実行環境に沿う限り動作保障とバグ対応します、
ただし無視した場合には責任を負いませんよと。

>>1
>ソフトウエア以外の商品でこんなのあります？
あなたは幸せな人ですね。

バグったら回収の車ｗｗｗ
食品とかも回収・廃棄だなｗｗｗ

北陸のある企業は
官公庁の情報化、電子自治体化で
自治体には適正価格を判断出来る職員が居ない事をいいことに
言値で売りつけ
工期管理も出来ないモラルの低いSoft馬鹿を遣って
それがまた、ある程度のシェアを占めているから始末に悪い。

バグといっても、乱暴に分けて、
・工程上のミスによって発生するもの
・想定外の入力や環境によって発生するもの
の2種類があると思う。

もし後者について、なくせ、というのであれば、
誰も読む気がしないような大量のドキュメントが必要になると思う。

医療ミスだってあるんだからバグがあるのはあたりまえだ。

誰か>>1に「でふぁくとすたんだーど」ってものを教えてやれ

>>1-13

欠陥が許される業界に身を置くとそうなるのかね〜
甘えるなよ。

しまった。アンカー間違えた。

>>2-13
欠陥が許される業界に身を置くとそうなるのかね〜
甘えるなよ

別に許されないよ。
仕様を満たさないもの、仕様から外れた物を出せば、
当然クレームがきて対応を行なう。

運用でカバー

つまり >>1 が言いたいのは

　　「ふざけんな Oracle」

と、そういう事ですね？

Oracleの事なの？ ＞バグリスト閲覧が有料

業界の問題として考えるなら、
完成度が高くてサポートが不要なソフトは儲からない
という業界構造が問題だと思う。

ソフトウェア自体では赤字で、
有償サポートやコンサルで黒字にする、
というやり方がはびこっているよね。

つか、一般個人向けソフトと、企業向けのシステム開発とじゃ
事情違ってるくし、一括りには語れないのでは。

完璧を求めるならそれなりの金を出しなさい。
完璧じゃないかわりに安く供給されてるんだよ。
あとユーザーは不正コピーを絶対にしない事。

たとえば、家を建てようと思って、工務店に発注するときに、
「どんな家にするか詳細は決まっていません。」
「一ヵ月後に住みたいのでそれまでに建てて。」
「3000万円かかる？高いから1500万円にして。」
「大工が足りない？24時間働いて建てればいいじゃない。」
「やっぱり、二階にも便所ほしいな。追加して。」
などというお客はいないよな。

>>1は
「甘え」や「いい加減さ」でバグが出来ていると思ってる

>>1は中学生くらいじゃね？

>>23
今まで気づかなかったけどほんとだ。
俺らソフト屋は普通に言われちゃうねorz

入社して数年目くらいに、工場立ち上げに管理システム担当で参加した時、
「装置とかハードの予算はどうにもなりませんが、ソフトはどうにでも融通利きますからねぇ、わははは」
とか客先と営業が会話してて目が点になった。

>>26
もちろん始末したんだよな？

数年目の人間に無茶言うない
立ち上げまでこき使われたがな

>>1
あるよ

また釣りスレですか？

>>1
ソフトウェアってのはコピーが簡単にできる。
しかもタダで。
ソースコードにバグがあるなら、それが簡単に修正できるものであれば
コンパイルされたバイナリ製品、あるいはサーバ製品でも
すぐに修正して渡すことができる。
修正パッチとかな。あとは、ライブアップデート機能とか使ってな。

>>1
じゃあさ、マイクロソフトが出しているWindowsやOffice製品の
バグについてはどう思っているの？

バグを沢山だしているから儲かって世界一の金持ちになれたビルゲイツ
>>1にはそれがわからないらしい

開発期間をもうちょっと長くしてくれ
それとユーザもシステムテストあたりから参画してくれ
3ヶ月でシステム作れってどういうことだ・・・レビューもドタキャンするし
まあ、そんな案件をうけてくる営業も営業だが・・・

欠陥が許されない環境と、多少の欠陥は当たり前の環境で比べた場合
出来上がるプログラムの質は違ってくるし、欠陥が見つかった時の対応も違ってくるわな。
志の問題で、多少の欠陥は当たり前になっている今の状況が大問題。

多少の欠陥は当たり前という環境で原発やスペースシャトル作ったら、100パーセント
大事故だわな。

で？

>>12
医療ミスにも及ばないたいしたことがないバグというものもある。
データフォーマットを変えたために
起きたバグとか。
データフォーマットを今まで通りの仕様に従わせれば
問題ないが、納得いかないという輩もいる。
そこでバグを修正する価値が人によってまちまち。
>>1のような愚かな完璧主義者にとっては
すべてのバグを修正することが最も大きな価値だと勘違いしている。
バグは無限に存在する。

一はソフトウェア工学を知らない。
ソフトウェア工学上、バグの無いプログラムなど理論上作れないことは
研究成果ですでにわかっていることである。

顧客に渡って初めて気づく潜在的なバグは無数に存在する。
機能を追加すれば追加するほどバグは増大する。
どんなことでも、
新しいことを始めようとすれば始めるほど、いくつもの新たな問題にでくわすのだ。
ソフトウェア開発も同じ。
エンジニアに使ったことがない新しい言語を使わせると使い慣れていない言語のために
バグに遭遇する確率は高くなる。
そして上司や顧客、マネージャは急げ急げとエンジニアに催促する、
それがさらにバグを増大させる。デバッグ、検証、テストをしっかり
やっておけばいいものを、上司や顧客、マネージャが「そんなことをやっている暇は無い！時間がないから
それを使うのはやめろ！急げ！」などと言って、結局すぐに直せると思ったら、
それが何日もかかってしまうのだ。しかも、時間がない、といってあるソフトを使わなかった、
あるクラスを自作しなかったために
かえって負担が増大した。ということもよくある。開発環境をしっかりととのえれば
こんなに何日もかからなかったろうに、。無駄で単純な作業、テスト用コードをコンパイルしてからファイルのアップロード、
テストが終わったらテスト用コードを無効にするために再度コンパイルしてからファイルのアップロード
という手間がかかる単調な作業をビルドツールなどによる自動化を行わなかったために
人為的ミスが発生しやすくなり、結局顧客に対して謝罪文を何度も送るつける羽目になるのだ。
顧客も顧客で問題が多いことも多いがな。問題なのは営業の無謀な要求。エンジニアに何も相談せずに
勝手に自分で判断して仕事を短納期で安い額で引き受けるという無茶な要求。結局赤字に。

営業はもちろんのこと、リーダーの独断で無茶な期間と予算で
機能追加を引き受けるやつもいるね
もちろん自分ではやらんけどなー

>>34
その営業、どうにかならんのかね。
うちのバイト先にもそういうバカ営業がいて困る。
学生アルバイトだからほとんど関係ねえけど。
効率悪すぎて呆れるぜ。
そいつは営業を兼ねているマネージャでかつ会社重役で
無能なくせに態度がでかくて威張ってるからみんなからの嫌われ者さ。
そいつのせいで社員は残業代無しで徹夜残業と休日出勤をさせられづけている。
事情に詳しいエンジニアに何も相談もせずに仕事を引き受けるヴァカだからどうしようもないったら
ありゃしないよ。計画性のなさと人望の薄さに呆れるぜその営業兼マネージャ兼会社重役には。
顧客や社長にたいしてはぺこぺこしてイエスマンで部下にたいしては手の平を返すような態度。
だからいつまでたってもデスマーチから抜け出せられない。

>>35
>
> 欠陥が許されない環境と、多少の欠陥は当たり前の環境で比べた場合
> 出来上がるプログラムの質は違ってくるし、欠陥が見つかった時の対応も違ってくるわな。
> 志の問題で、多少の欠陥は当たり前になっている今の状況が大問題。

はっきりいって、そういう問題を作り上げた原因はエンジニアではなく
顧客や営業の、エンジニアに対してきちんと接点を持たなかった怠慢としか思えないよ。
顧客や営業って、いつも、できないをできると勘違いしているし。
どう考えても技術的にできないこと(携帯電話開発で、携帯電話に無い機能呼び出しなど)を、
エンジニアに相談もせずできると決めつけてそんな仕事を安い額で引き受ける。
バカとしか言いようがない。みんなから嫌われて当たり前。

やつらの頭の中では1人日＝16時間換算でしょ
前あるプロジェクトでスケジュールみたら普通に土日まで線が引いてあったよ

>>35
> 多少の欠陥は当たり前という環境で原発やスペースシャトル作ったら、100パーセント
> 大事故だわな。

多少の欠陥は当たり前なんてものはいくらでもある。
それがスペースシャトルであっても。
まず、その100%という測定値は自然界に存在するものを測定した結果では
絶対にありえないことをよく覚えておけ。表記が100%とあってもそれは四捨五入、切り捨て、切り上げ、
目盛りの限界から省略して100%と表記しているに過ぎない。

物理学、工学を勉強したことがあるならそれくらいはわかるだろうが
>>1はちゃんと勉強してきたんだろうな？　それとも文系だからアフォなことが平気で言えるのか？

物理、工学をやったことがあるなら、どんなことでも必ず誤差というものがあることがわかるだろう。
数学の世界んは誤差というものは存在しないが、物理の世界では見事に存在する。

スペースシャトルだって、誤差の範囲内であれば安全と見なして運行する。
誤差があるから、もちろん100%完璧だ、なんてことはNASAは言わない。
どんなものでも誤差が何%か必ず存在する。バグだってそうだ。


世の中に、本やお話にでてくるような絶対的なものや「銀の弾丸」など存在しないし、理論値では絶対的でも
実測値では正確に実現できず必ず誤差というものは出る。

「誤差の無い実験レポートは価値が無い！」とよく言われるように。

誤差があるから自然界は成り立っている。

誤差の無い世界、すなわち>>1が望んでいるような原理主義者が好む理想郷、
数式理論だけで成り立つ実世界など
存在しえないのだ。この世にはエントロピーというものが存在するのだ。
エントロピーはいつまでも果てしなく増大するのだ。
これは避けられない。人はいつか死ぬのだ。これもさけられない。

だのに、>>1のような原理主義者は愚かにも不老不死が存在すると信じている。
バグが全くない理想のソフトウェアが存在すると。

とにかく、言いたいことは、この世に、絶対的なものなど存在し得ないということだ。

int main(void){

　printf("Hello_World\n");

　return 0;
}

こんなプログラムとはいえないような物ですら、すでに潜在的バグが
潜んでいる。

バグのないプログラムとは不可能

>>42
アジャイル開発手法のひとつである
eXtreme Programmingでは
プログラミングは週40時間やればいいと勧めている。
一日8時間5日やればいいと。
それ以上やりすぎると効率が悪くなるのだそうだ。
運動と同じ。運動はしすぎないのも問題だが、
しすぎると体を明らかに破壊する。
徹夜もそうだ。徹夜しすぎるとかえって仕事の能率が
悪化し、病院送りになって本末転倒になることも。
それをわかっていない顧客や営業がどれほど多いことか。
>>1にはそういう現実があることをどれだけわかっているだろうか。

１はどっかに丸投げして、ひどい目にあったのだろうか

>>45が今いいこと言った。
>>1もよく考えて見るがいい。

>>1はイスラム教原理主義者です。
爆破テロ予告をするかも知れませんので彼には気をつけましょう。

ム板でも昔こういう>>1みたいなバカなこと言ってる奴がいたな。

まだ残っているスレを見つけた。
あまりにもバカ過ぎてバカを通り越して呆れる。


完璧なプログラム
http://pc8.2ch.net/test/read.cgi/tech/1041126217/

>>44
> とにかく、言いたいことは、この世に、絶対的なものなど存在し得ないということだ。
そんな糞当たり前なことをとにかくいいたいのか、おまいは……

ピーデー 川俣 晶が書いた記事なのであてにしたくないが
>>1には多少参考になるだろう。

http://www.atmarkit.co.jp/fdotnet/tools/nunit22_01/nunit22_01_01.html


プログラム開発の効率をアップするための方法

　プログラム開発の効率を上げるために、最も効果があることは何だろうか。
いろいろな考え方があると思うが、設計、コーディング、テスト、デバッグとい
った大ざっぱな工程を思い浮かべたとき、デバッグこそが効率アップの対象
になりそうだな、という印象を持つことができる。設計、コーディングはプログ
ラムを生み出すうえでの必須の工程なので、除去はできない。また、テスト
は品質保証上必要とされる工程である。それに対して、デバッグは、バグさ
えなければ発生しない工程なのである。

　しかし、これは机上の空論に思えるだろう。

人間は間違いを犯す生き物であるから、バグのないプログラムなどというものを作ることは不可能だ。
しかし、そう思ってあきらめてしまうのは建設的ではない。バグがないプログラムはあり得なくても、
バグの早期検出、早期撲滅の可能性を高める方法は確かにあるからだ。

>>51
>>1にはそんな糞当たり前なこともわからないようなので
言わせて貰った

つか、大金かけてる原発やスペースシャトルでもヒューマンエラーあるのに。。
（=安い製品なんだからバグあるのは当然とも言いたげ）

みたいなこと言ってるな、ここの住人。

1mmでもユーザー側に立って言ってるとは思えないやね。

この記事なら説得力あるかな。

http://www-6.ibm.com/jp/domino07/lotus/home.nsf/Content/ldd_tsurezure_X_vol16
iconそもそもノーツサーバーはどうして落ちるのでしょうか。
それはハードウェアの障害であったりもしますが、多くの場合
ノーツサーバープログラム自身かそれを動かしているオペレーテ
ィングシステムのバグが原因でしょう。何かの処理の途中でバグにあたり、
サーバープログラムまたはオペレーティングシステムがおかしな状態にな
り続行不能になるのです。『そんなことは当たり前だから、早くノーツサー
バーやオペレーティングシステムの品質をあげてくれ』と怒りの声が聞こ
えてきそうです。確かにそのとおりです。



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　・　・　・　・　・　・　・　・　・　・　・　・　・　・　・　
ただ全てのソフトウェアに共通で言えることですが、バグのないプログラムなど存在しません。


ではこのバグとどう付き合っていけばよいのでしょう。

バグを完璧になくす方法があればいいんだけどね

>>54
お前は何のユーザだ？
工学を勉強したことがるエンジニアとは思えない発言が多い奴だな。
100%完璧に欠陥が一切ない商品があるとでも思っているのか？

液晶ディスプレイを例にとってみようか？
ドット欠けが1点や2点あっても製品として出荷するんだぜ。
4点まではオッケーなんだそうだ。
それで漏れのディスプレイは購入時から1点の目立つドット欠けを発見した。
当時2,3万程度の安い液晶ディスプレイだからな。

バグだって同じことだ。たった4点程度だったら仕事上支障を来さない。
だから出荷する。バグだって大事故につながらないたいしたことがないものならそのまま納品する。

農作物や魚介類だってなおさらだ。
すべてが全く100%同じ形をしたキュウリやメロンなどありえない。
ある程度の形状に従ったものだけに合格マークのシールが貼り付けられ、スーパーなどに出荷される。
合格マークが付かなかったものは自分で食べるか、親戚などにあげるか、自分で直売なりするなりして売りつける。

>>56
そういう原理主義者みたいなことを言う奴は仕事もできないし、
この世界で生き延びることもできないだろうよ。

今まで日本の治安(最近は若干悪くなって区手いるが)は高かった。
だが、いつまでもこの治安が維持できるとは限らないわけだ。
100%完璧に自分の命を守れる保証もないのだ。
いつ北朝鮮からのミサイル攻撃をうけるかもわからな世界で生きている。
だか、自分の命を奪われる可能性は非常に低いから安心していられるのだ。

ユーザー側も開発側に1mmでも立ってください

たとえバグが完全になくなっても
仕様書通りのシステムが出来たとしても
それが顧客の望むものとは限らない。

ttp://www.dashiblog.com/blog/archives/000140.html

>>1はソフトウェア業界云々を言う前に
自然界の法則について勉強したほうがよさそうだな。

>>1は釣った魚が自分が想像していたような
思い通りの形をしていなかったら駄々をこねるような奴なんだろうな。
すべての鮎(アユ)がまったく同じ形をしていたら気持ち悪いだろうし。
人間だっていろんな奴がいるように鮎(アユ)だっていろんな形の奴がいる。
まずい奴、上手い奴。それを>>1はちょっと味がわるかったからといって
たいしたことがなくても料亭に文句を言うんだろうな。
文句があるんだったらもっと金をたっぷり容易してもっと高い料亭に行って来いと。

エンジニアに対して、それなりの金(報酬)しか与えない奴には
それなりのソフトウェアしか作らせてもらえねぇっつーことだ。

>>1は営業やエンジニアと喧嘩しやすい顧客タイプだろう。
この業界ではうまくやっていけなさそうな奴だな。

営業やエンジニアに対しては曖昧なことをいって
>>1自身が何を作って欲しいかわかっていないため
営業やエンジニアと上手くコミュニケーションが取れず
すぐ喧嘩しそうな奴だな。

>>1みたいな奴はどのソフトハウスからも相手にされなさそうだ。
アフォな顧客は斬る！とかいわれてな。

>>1は数学の世界でしかあり得ない、
物理や工学では不可能な、無限というものが現実世界に
存在していると勘違いしている哀れな香具師なんだろう。


>>1は無限もコンピュータで完全に再現できると勘違いしているんだろう。

コンピュータというものは数学の世界と違って大小比較しかできない世界なのだ。
それを>>1はおそらくわかっていないのだろう。
数学の世界では数直線はマイナス方向、プラス方向とも無限に続く。
だがコンピュータの世界ではそれは有限だ。

小数点だって表すにはコンピュータで限界がある。
有理数ならまだしも、無理数などコンピュータで数値のみで
表すことは不可能だ。それを>>1は絶対にできると勘違いしているのだろう。
コンピュータで無理数を再現するのは抽象化などで置き換えるしかないのだ。
それも、>>1はわかっていないのだろう。

さらに、連続的なものも数値だけでは表現できない。
どうしても表現したければやはり抽象化するしかないのだ。
コンピュータの世界では連続的なものを表現する代わりに離散的なもので置き換える。
音楽を例にとればわかるが、
連続関数(アナログ)など完全に再現できないのだ。
だから離散数列(デジタル)によって抽象化するのだ。

>>35
> 多少の欠陥は当たり前という環境で原発やスペースシャトル作ったら、100パーセント大事故だわな。

ドアホ、逆だ、逆。

多少の欠陥は当たり前という前提で原発やスペースシャトルを作ってるから、100パーセント大事故にならないで済んでるの。
言い方を変えると、
多少の欠陥は当たり前という前提で原発やスペースシャトルを作らないと、100パーセント近い確率で大事故になる。

生音声をマイクで集音したアナログ音声をデジタルに変換してさらに圧縮などを行ってMP3に変換されて我々は
iPodなどで曲を再生して楽しむことができる。
それを>>1は何を勘違いしているのか完璧な生の音を再現することに拘ろうとしている。
MP3で不満なら圧縮前の音にすればいいし、それでも不満なら
サンプリング周波数やビットレートがもっと高めで録音された音声を購入して聴けばいいし、
それでも不満なら
何百万もする高価な巨大なスピーカとウーハー、超高価なアンプを6chサラウンドで接続して
自分の部屋において再生すればいいのに。


サラブライトマンの生の声を聞きたければコンサートに行くか
お金をかけてでも直接合いにいけばいいのに。それができなけれサラブライトマンの歌声を
デジタル音声に変換されたCDを買って我慢すればいいのに、>>1はそれができないのだろうかねぇ。

ようは、バグを徹底的に減らしたかったら、それだけお金がかかるってことだよ。

>>63

> 音楽を例にとればわかるが、

全然分かりません (w

>>65
最後だけ同意
まあ、それ以前にどうしようもないSE様をどうにかしてください

>>1はプログラマーじゃないことは確か。
マだったら絶対にそんな基地外な事は言えない。

>>1の知能は

「アイドルはウンコしない」
「赤ちゃんはコウノトリさんが運んでくる」

そういう風に物事を理解して脳内に格納するレベル

>>35=>>1は、本物の馬鹿だな。
「欠陥が許されないとは」どんなこと思ってるかといえば
本当にアホなこと言い出したな。

シャトルも原発も
使う人に専門の教育をして運用でカバーしてるだけ。

シャトルで宙返りをしたら墜落する。
進入角度を適当にやったら燃え尽きる。
バケツ使っていい加減にウラン溶解作業をやればバグが発生する。

わかったかクズ。

>>66
番号つけなかったのでわかりにくかったけど
>>63と>>65はつながってるので。

>>1用の喩えとしてはまあまあ妥当かと思うが
よろしく

>>1がほしがっているものは、
サンプリング周波数もビットレートも無限大の音楽！！
(何と！バグが完全に無い, >>1にとっての理想的なソフトウェア！)
んなもんあるわけねえーっつーの。

CDだって44.1kHzもあるんだし。人間が聞こえる音声の課長域は20Hz〜20,000Hzまでだし。
CDのサンプリング周波数はちょうどのその二倍で人間には十分な音声なのに。
>>1の耳が100,00Hzまで聞こえるっていうなら話は別だが、
そのときはその例外的な製品を特別にオーダーメイドで作るために
非常に時間と金を>>1がかけなければならないが。
>>1は貧乏人で雑音だけの大した音楽(些細なバグ)しか聴かない癖に音(実用上ほぼ無害に近いバグ)に拘る。

貧乏人(>>1)は安いコンポと安いヘッドホン(それ相応のバグだらけのソフトウェアとして)で
音楽でも聴いて(ソフトハウスに注文して)いなさいってこった。

>>62
>上手くコミュニケーションが取れず

むしろ業界の人の多いのが往々にしてこの手だったり(笑)
社会常識と乖離しちゃってるプログラマさんたち

全然問題じゃない。
欠陥が嫌ならソフト使わなければ良いだけ。作る側は大半が発注されたから作っているだけだし。
作る側は完璧だ／完全だなどとは口が裂けても言わない。
>>1も問題提起するなら、「欠陥の無いソフトを作る力もないのに
現代社会はなぜこんなにコンピュータに依存するようになっってしまったのか」
という文明批判から始めるといい。
作る側だけを責めるだけでは話が進まない

>>1を読んだときはどうなるかと思ったが
>>2-以降は結構参考になる話なね
特にmp3変換の話。説明につかえそう

1のクソさがこんな良スレを生むとはびっくりだなｗｗ

でもオブジェクト指向にしたらバグかなり減った。

>>75
>>65
これのこと？
どこがいいの？

逆に聞きたいのだけれど、バグが含まれるプログラムってどういう物を指しているの？

ここのスレの人はバグの無いプログラムは存在しないって言ってる気がするんだけれど、
それはなんで？

>>15
おまいもうだめだろｗｗｗｗｗｗｗｗｗ

そりゃテストにテストを重ねて万全の体制でソフトを開発すれば、バグは
劇的に減るだろうさ。ゼロにすることだって可能かもしれん。


でもたぶん、そんなソフト、>>1 さんの稼ぎでは買えないような値段に
なっちゃいますよ？

まさに文系未満の底辺だな>>1はﾃﾗｶﾜｲｿｽ

はじめまして！！ここのスレってプログラマー人せんようですか？？
今日はC言語について質問があるんですけど誰か教えてください。

>>79
現実解として、絶対にバグのないプログラムはつくれない。
証明ができないし、時間がないから（・・また、技術者の問題）。
その通りだよ。存在しない。
すべてのプログラムがバグを含む可能性がある。
ウィンドウズだって、一般保護エラーで強制終了するだろう。
ＵＮＩＸもクラックが絶対不可能って言わないだろう。
完全にセキュアなプログラムはクラッキングできないだろう。

(´-`).｡ｏＯ（シュレーディンガーの猫か・・・）

>>79

本当の意味でプログラムを作るプログラムは未だ存在せず
つまり、この世のプログラムは根本的にはすべて人間による手作り。
かつ、人間は必ず間違いを犯す。

納品したシステムにバグあっちゃまずいだろ。
少なくとも「バグがあるのは当たり前」って胸張るべきではないな。

すべての物にはバグは存在する

そして目立の製品は存在自体が悪

>>79
この世に完全に平らな板など存在しない。

超大国の威信をかけた巨額の費用を注ぎ込んだプロジェクト。
ハード、ソフトを問わず世界で最も優秀な技術者集団の一つが、
心血を注いで作り上げたものがスペースシャトルである。
乗組員たちも、選び抜かれた精鋭がさらに厳しい訓練を積んだ末のものである。

そうであっても、たかがキツツキがタイルに穴を空ければ爆発して木っ端微塵になる。

あたりまえだ。

人間の作る物に完璧は無い。
それだけの話だ。

バグのない人間なんてものも存在せんやろーな。
俺は朝起きれないバグが30前になっても直らない。

なんだなんだ、入れ食い状態だな。

>>19
おかしな挙動があっても、それがバグかどうかすら無料では教えてもらえない。
しかも契約で「他言無用」。素敵。

>>71
オナニーですっきりしたところ悪いが、喩えの誤謬だな。

>>81
ハードウェアという、予測不能の要素も忘れないでやってくれい。

バグの無い関数を組み合わせて作る新たな関数には必ずバグが含まれるということですか？
それともどんなに細分化しても必ずバグは含まれるということですか？

大きな範囲で話されていますけど、小さな範囲で話した場合「必ずバグは含まれる」というのは
どの時点になるのでしょうか？

そもそもなんで>>1はPC使ってんのだろうね

部品それぞれが完璧でも、
それを繋ぎ合わせかたに問題があったら、うまくないでしょ。

問題の無い繋ぎ合わせ方は無いということですか。

>>14
>>1が早速ミスってるところにﾜﾗﾀ

そもそも、バグがない関数という仮定が間違っている。
ある環境で、絶対に想定どおりの挙動を示すコードでも、
違う環境において、同様に動作するとは限らないし、
コンパイラにだって、バグとは言えないほどの「癖」が存在し、
それは時として致命的な「バグ」をプログラムに生じさせる。
つまり、あえて答えるなら、どんなに細分化しても、必ずバグは含まれる。
バグを、環境に依存する問題をも含むと定義すればだが。

10年くらい前、パソ通の時代に
なぜバグのないプログラムは作れないのですかと、NIFTYで質問したら、
「問題の定義が甘い。お前が調べてここに書け」といわれてしまった。
時代が変わり、やさしい人が多くなったなあ。
俺の中で10年越しの疑問が今まさに解決しようとしている瞬間だ。

>>1
「絶対にバグらない」ってどうやって証明するのさ？
そう思うなら自分で作ってみなよ。

なんで誰も「バグが含まれないパターンはあり得る」とは言わないの？
絶対にあり得ないから？
バグが含まれるプログラムがあり得るなら、バグが含まれないプログラムもあり得るのだと思うのだけれど。
なんで細分化しようとしてるのに膨らませる？

>>100
＞問題の定義が甘い
これが答え
10年たっても読み取れないおまえが低脳

たとえば、
2つの整数を足した結果を返す関数
というのを書いてみ?

それよりも。10年間何をしていたのか

整数の範囲は？

10年間、その問題を忘れてた

整数の範囲？

int add(int a, int b){ return a + b; }
これでいいんじゃね？

オーバーフローする可能性があるってことでしょ？
仕様決めないとバグが入り込む可能性が残る。

書いたら全ケースの試験の実行時間の見積もりを
・・・って言うわけかな？

あぼーん

1の言わんとするところを無視して、的外れな突っ込みでネタを披露するスレはここですか？
ここ、VIPじゃないよね？

>>113
> 1の言わんとするところを無視して、

おまえも>>1みたいなキ○ガイの仲間か？

>>102
「バグがない」事をどうやって証明するんだ？
検査仕様書の範囲内では、動作を満たす、という以上の保証はできない。

あと、「バグ」という言葉の意味が広すぎる。

>>109
addやintやreturnや+演算子に「バグ」がないことをきちんと説明してね。
あとこれの演算を行うすべてのCPUに不具合がないことも。

　　　＼　　__　　／ 　　　
　　　＿　（ｍ）　　ﾋﾟｺｰﾝ 　
　　　　　　|ミ| 　　　　全部アセンブラで書けばいいんだ！
　　　／ 　.｀´　 ＼ 　
　　　　　 ('A`)　　　
　　　　　 ノヽノヽ　　　　
　　　　　　 　くく 　

>>113
それはバグについてわかっていない意見。レスを何度も読み直すべし。
論点をずらしていると思っているのだろうけど、バグはあるのが常識。
それはどこの世界でも同じ。
無責任にもバグはないですよ、なんて言えるわけがない。

>>1よ
お前の脳みそにバグがあることについては棚にあげたままか？

たまに視界の隅を虫が這ってるんですが、
眼を向けると何もいないんです。
これってバグ？

飛蚊症

２ちゃんのやりすぎで飛蚊症になりました。

>>118
１は確かに頭悪そうだが、１の言わんとしてるところは
「この業界は、品質管理に対する認識が低すぎる」と言う事だろう。

その指摘は無視して、「バグのないものは世の中にはない」という
禅問答のようなレスを繰り返すのはちょっとアレじゃないの？

それとも　ソフト業界の品質管理に対する認識は他の業界に比べても
高いほうだとでも思ってる？

>>123

＞その時点での概知のバグを公開していなければなりません。
＞
＞バグがあると言う事は欠陥商品な訳で、欠陥内容を詳しくしりたかったら
＞金払えなど言語道断。
＞ソフトウエア以外の商品でこんなのあります？

見つけたバグは報告してるし、バグ情報で金なんて取ってないから、
そもそも>>1の問いかけに答えようがない。

>>123
後学のために是非「品質」の定義をお願いしたい

つか、ソフト業界全体の問題じゃなく、Oracelの話なんだろ？
>>19、>>93
ならOracelのサポート云々ってスレ立てろよ。

Oracelってなんだｗ

オラセルを知らんのか？

>>125
　なんで定義が必要なんだ？　状況によって解釈が大きく異なるような用語でもないと思うが。

君にとっては「品質」という言葉にさまざまな解釈が存在するのか？
よかったらそれを聞かせて欲しいんだが。

仕事の愚痴がいえるなんてうらやましいでつ

ま、ソフト自体が、簡単に直せるような類のものだから、
チェックが不十分なまま作業が進んでしまうんだよな。

他の形ある機械製品だと、不具合があるまま製造しちゃうと
膨大なコストロスになるから自然とチェックは厳しくなる。

>>129
要するに「品質管理されている、という基準」のことでしょ。
何を持って「品質管理をしている」と呼ぶのかと。
なんでそんなことも読み取れないの？

>>132
何が言いたいのかよくわからんが、
例えば「三菱自動車は品質管理に対する認識が甘いのではないか」
ということを誰がが言ったら、
君は「何を持って品質管理と呼ぶのか？」と食って掛かるのか？

＞完璧な商品でなければなりません
完璧なんてありえねー、というつっこみと、

＞バグがあると言う事は欠陥商品な訳で、欠陥内容を詳しくしりたかったら
＞金払えなど言語道断。
これを業界全体に適用すんなって言ってんだろボケ。

自動車の場合は国の基準があるから明朗だけど
ソフトウェアの場合はなかなか難しいよね
特定の条件で動いたり、動かなかったりするのは避けようがない

>>123
誰であっても、品質管理は徹底したいと思っている。
はじめに徹底的に煮詰めたほうが、絶対に手間がかからない。
そんなことは、誰でもわかっている。

全体的な品質管理と保守を徹底するための、優秀で必要な人材を雇う費用を
料金に含ませることが当然になり、顧客も払うのが当然となり、開発期間も
膨大なテスト期間を含めるのが当然になれば、品質管理はあがる。

期間にしろ、費用にしろ、見積もり計算してぎりぎりの線から
どこか削れないか必死になってさがして、無理に削ってるのが
よくあるパターンではないだろうか。
無理したぶんは、現場が無理をして吸収しているはず。

ソフトウェアは形がないからな。
で、日本で企業が提供する形のないものを探すとこんなものが見つかる。


　　「お客様サービス」


つまりソフトウェアはお客様サービスなので無料で当然。
コンピュータ本体は高い金出して買ったんだし無料でいいだろ。

ということで見積もりも価格も買い叩かれる。

そもそもサービスとは有料なものなんだが

>>129
「なんで定義が必要なんだ？」と来たか。そして同じ質問を返すか（苦笑）。
一例を挙げると「使用者が判断する価値」だ。
文脈から考えると貴方の定義は「欠陥が無い事」のように思えるから、確認の意味できいたんだよ。
同じ定義に見えるかい？。
貴方の定義をどうぞ。
も一度言うけど、品質の定義について論議する気は無いぞ
>>132
yes。それもあります。
>>133
違うって。>>123が品質管理というソフト業界において共通認識が形成されているとはいえない言葉を使ったから、
じゃあ少し品質について話してみようかと思って訊ねただけ。
それも品質の定義について話すのではなくて、「>>123の定義する品質」について話そうと思っただけ。

>>138
「サービス」を「客への無料奉仕」の語としてばら撒いた元凶って誰なんだろうね。

>>139
おいおい、スレの流れから判断すると「欠陥が無い事」という意味だということくらい
容易に想像つくんじゃないか？


> 違うって。>>123が品質管理というソフト業界において共通認識が形成されているとはいえない言葉を使ったから、
> じゃあ少し品質について話してみようかと思って訊ねただけ。
> それも品質の定義について話すのではなくて、「>>123の定義する品質」について話そうと思っただけ。
>

>>125の一行レスでそこまで読み取るのはむずかしいんじゃないか？ｗ

>>102
> なんで誰も「バグが含まれないパターンはあり得る」とは言わないの？
> 絶対にあり得ないから？
> バグが含まれるプログラムがあり得るなら、バグが含まれないプログラムもあり得るのだと思うのだけれど。


> なんで細分化しようとしてるのに膨らませる？

この「細分化」に拘りすぎることが原理主義者が陥る罠なのだ。


原理主義者の問題について知りたいことがあるなら、
養老 孟司の「バカの壁」、「死の壁」を読むことをおすすめする。

バカの壁 新潮新書 養老 孟司 (著)
http://www.amazon.co.jp/exec/obidos/ASIN/4106100037/250-7121376-1245845
　「現代人がいかに考えないままに、己の周囲に壁を作っているか」、つまりあの人たちと
は話が合わないという「一元論」が「バカの壁」の元凶であり、アメリカ対イスラムの構造
や日本の経済の停滞などもすべてこの理論で説明されるという。一方で、イチローや
松井秀喜、中田英寿の際立つ能力を、脳の構造で解明してみせたり、「学問とは生きて
いるもの、万物流転するものをいかに情報に換えるかという作業である」という骨太の
教育論をも展開している。
　我々人間は、自分の脳に入ることしか理解できない。学問が最終的に突き当たる壁
は自分の脳である。著者は、この状態を指して「バカの壁」と表現する。知りたくないこ
とは自主的に情報を遮断し、耳を貸さないというのも「バカの壁」の一種。その延長線
上には民族間の戦争やテロがあるという。

　現代人はいつの間にか、自分の周りに様々な「壁」を作ってしまった。例えば、情報は
日々刻々変化し続け、それを受け止める人間は変化しないという思い込みや、個性や独
創性を礼賛する風潮などはその典型例で、実態とは「あべこべ」だという。
　「バカの壁」は思考停止を招く。>>1のように安易に「わかる」「絶対の真実がある」と思い
込んでは、強固な「壁」の中に住むことになると戒めている。

死の壁
http://www.amazon.co.jp/exec/obidos/ASIN/4106100614/qid=1125644362/sr=1-2/ref=sr_1_10_2/250-7121376-1245845
　ガンやSARSで騒ぐことはない。そもそも人間の死亡率は100％なのだから――。
誰もが必ず通る道でありながら、目をそむけてしまう「死」の問題。死の恐怖といかに向きあうべきか。
なぜ人を殺してはいけないのか。生と死の境目はどこにあるのか。イラク戦争と学園紛争の関連性とは。
死にまつわるさまざまなテーマを通じて現代人が生きていくうえでの知恵を考える。

特に>>1にとっては「バカの壁」、「死の壁」は必読書だ。

>>141
ただ単にそれだけこの業界の速度が速くて難しい、てことじゃねの。
まあ、Windowsとかは出しすぎだと思うけど。

>>102
「1byteの整数」を2つ足すプログラムに限定しよう。

8bitCPUと32bitCPUでは、
コードを書いた人が想定していた以外の結果になるかもしれない。

8bitCPUに限定しても
6502とZ80では、オーバーフローを起こしたときの
ステータスレジスタの変化や、キャリーの扱いが変わるはずである。

「ソースコードレベルでは、バグが完全に無いものは書けない」
と言ってもよいはず。

　　　　　　　　　 　　　　　　　☆ ﾁﾝ　　　　　　　　ﾊﾗﾍｯﾀ〜
　　　　　　　　　　　　　　　　　　　　　ﾊﾗﾍｯﾀ〜
　☆　ﾁﾝ　　〃　　　　　　　 　 ／￣￣￣￣￣￣￣￣
　　ヽ　＿＿_＼（＼･ω･`）＜　Windows Me SP1 ﾏﾀﾞｰ？
　 　 　 ＼＿／⊂　⊂＿)　　　＼＿＿＿＿＿＿＿＿
　 　 ／￣￣￣￣￣￣￣／|
　　 | ￣ ￣￣￣￣￣￣:|　 |
　　 |　愛媛みかん　 　 .|／

>>145
1byteの一桁の自然数を二つ足すプログラムなら？

一桁なら一バイトという条件は必要ないなｗ

「一桁の自然数」というのは、運用でカバーすることになるのでは？

10以上の数を入力できるシステムならば、
かってに10以上を切ってしまうのは、使う人の求めてる結果と違うかもしれない。

再入力を促すならば、それこそユーザーの運用でカバーしていることになる。

>>147
あのさ、実用性のあるソフトにおける欠陥の話をしているんだよ。
欠陥零のソフトは無いという事を示すために、実用性のないソフトにおいてさえ欠陥零はこんなに困難だ
というサンプルが提示されているわけだ。
貴方のように「更に縮退したサンプル」を提示しても意味が無いのだよ

うーん自分でいったものの、149はなんかへんだなあ

>>149
すまん。意味がわからない。
「どんなに条件を限定しても、バグが完全にないプログラムはつくれない。
これは真か偽か？」ということを議論してるんじゃないの？

>>152
そう思っているの？
>>1から読んだ？

>>153
>>1「から」読んだなら方向性は間違ってないと思うぞ。
>>1だけ読んだなら間違ってるがね。

Z80限定でハンドアセンブルでプログラムを書くか、
アセンブリ言語でソースコードを書き、アセンブラをハンドアセンブラで自作し、
アセンブルするぐらいまでやれば、「正常にCPUが動きプログラムも動く環境である」
という条件さえなりたっていれば、正常に動くだろう。

システム全体で考えた場合、何かしらの不確定要素があるならば、
「バグったりしません。この先もずっと期待にこたえ続けます。」とは言い難いだろう。

つか、言ってることに意味があるのかどうかは、もうよく分からん。
だいぶ下らなくなってきてしまったので止めます。

>>150

>>102,>>145の話の流れでは「実用性のあるソフト」の話じゃなくて、
限定された条件でもバグが完全にないものは書けないという主張に
読めたんだが。

実用性のあるソフトの話をしてるんなら　「1byteの整数を二つ足す
プログラム」の例を出しても意味ないような気がするが、
ま、俺の読み違いだということで。

すまん。最後。

分かってるとは思うし、スレで既出だとおもうが、
145で言ってるのは、ソース以外の要素も、当然考慮しなければならない。

ソースコードが、ソースコード以外の要素に大きく左右されるならば、
ソースコードレベルでバグをなくすのは事実上難しい。
つか無理だろうってこと。

ビジネス系なんて要求自体が明瞭じゃないしブレまくるからな。
何がバグか分からん。

>>157
うーん、「バグ」の定義に誤りがあるような。
特定の条件下で期待通りの動きをしない＝バグというのは強引だろ。
「この条件では動作しません」とかうたってあれば、動かなくても
バグとはいわないよ、普通。
ＷＩＮのアプリがＭａｃで動かんのは、バグのせいではないｗ

>>159
> 特定の条件下で期待通りの動きをしない＝バグ
このスレの誰がどこでそんなことを言ったんだ…

>>159
> >>157
> うーん、「バグ」の定義に誤りがあるような。
> 特定の条件下で期待通りの動きをしない＝バグというのは強引だろ。
大抵の顧客がそういう強引な解釈をしている。
複雑で中身がわかりづらいものだと、なんでもかんでもバグだ。
Windowsだって、人によっては期待通りに動かないモノはバグと見なされる。
人によって何が大事で何が大事でないかは全然かわってくるし、
MSが提示した仕様どおりに動いてくれなければバグと見なされる。

バグってハニー

「おまえの頭がバグってるんだよ！！」

納期が３年あればバグ取るよ。

どうしてもバグが残るという人はすぐに未来の話をするね。
想定外の環境で動かしたら正しく動かないって、そんなの当たり前でしょ。

386用のプログラムがPowerPCで動かなかったらバグか？違うでしょ？
仕様を制定して、その仕様通りに動かなかったらバグでしょ？
一見バグに見えるものでも仕様通りに動いているなら胸張ってりゃいいんだよ。

それとも何か？
未知の環境に対応できないプログラムはバグ有りだっての？

80万ステップでもか？

開発元が仕様といえばバグも仕様になる
・・・書いててﾂﾏﾝﾈ

まぁ、バグは少ないに越したことはないけど、無くせないよな。
なんかソフトウェアと他のモノを比較してる輩も居るけど、
ソフトウェアというのは

a=a+b;
b=b*b;

と書くべきところを

b=b*b;
a=a+b;

と書いただけでバグになっちゃうんだから。
しかも二行なら誰でもわかるけど、これが何万行も続くんだからね。
この手のミスは文法ミスでないので、正しいか正しくないかは機械的に判断できない。
正しい場合もあるし間違いの場合もある。テストに委ねられるのだが、
十分なテストができない場合はある特定の入力が通ったら良しとする場合も。
その場合、他の入力をされたら、、、

しかも、仕様が変わらないなら、テストして問題無しでOK。
しかしころころ仕様変更、仕様追加だ。完成する前にだ。変わるたびに一からテストだ。
変更によって一貫性が無くなって想定外のモジュールでバグが出たりする。

これは時間とお金をもらっても複雑化しつづける一方で解決は難しいのじゃないかと俺は思う。
もちろん、だからこそ時間と金をかけないのは問題外で、
時間と金もかけないでいてやれ火を吹いただのデスマだの言ってるからおめでたい。

よくお金と時間をかければ解決するって思われてるフシがあるが、
じゃあ、世界一のソフトウェア会社の次期OSが、
これだけ金と時間をかけてリリースが遅れているのは疑問だと思わないのか。

もうだめぽ。

実務経験の出るスレだなぁ。


>>165
>386用のプログラムがPowerPCで動かなかったらバグか？違うでしょ？

ある種の顧客にとっては全く違わない。

それでは正解です
・・・と言いたいところだけど、正解はない。

>>104は仕様としては、あまりに漠然としている。
仕様を確認しないでコーディングすればかなりの高確立でバグのもとになる。

また、仕様がキッチリ決まっていて、さらに仕様をキッチリ満たすバグのない関数を書いても、
使う側が仕様を誤解していたり、仕様を知らなかったり、うっかり仕様外の使い方をすれば、それもバグになる。


ちなみに例題については、ちょっと知ってる人は数値の範囲を気にするけど、
そもそも入出力の形式すら明らかになってないんですよ。

(´-`).｡ｏＯ（仕様変更をバグとして飲まされているヘタレが多い気がする・・・）

ほう。個人の心がけの問題ですか。

つバグ(-)＋バグ(-) = 正常（＋）　　　・・・・といってみる。

田？

なぜバグが多いのかという議論と、そもそもバグとは何かという議論が
ごっちゃになってるな。

ttp://www.itmedia.co.jp/enterprise/articles/0509/02/news055.html

バグはここでは「ユーザーが欠陥だと判断する事象／事項」と定義するのが正しいかと。
#なかには「仕様書のままだからバグじゃない」って強弁したくなる場合もあるけど

>>172
>>171のような精神論はいまだに根強いな
対応者がヘタレだからとかそういうのじゃなくてさあ〜

精神論って、管理者の職務放棄だよな。

「おまえらだけで何とかしろ」と言ってるよーなもんだし、
現実には効果のある対策を打っているわけでもないし。


うちの会社では社長が、
赤字の原因は従業員の意識が旧態依然だからです、
みなさん各自でグローバルスタンダードな仕事のやり方を、
自宅で自習して意識改革をしてください
とか言ってるもんな・・・。
そりゃいつまでたっても赤字から脱出できないわけだ。

自宅での自習を促す訓示ってすごいヤだ…

情報処理試験の受験料と交通費と参考書代を出してやるから受けて合格しろとはいうけど、
合格するのに必要な勉強は就業時間外に勝手にやれ、という会社は多いんじゃないかな?

急激にＰＣが増えたものだから、０から会社に入った新人も全体的に多そうだ。
昔は需要が少なかっただろうから、それは無かったんだろう。
・・資料が少ない問題があっても。
ソフ開もってるけどデザインパターンは知らない、なんていたら嫌だなあ。
ＳＱＬインジェクションで動いてるＤＢとか ・・・・(゜Д゜)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
情報系の学校や学部なんかはどうなんだろうか。

ﾃｸﾈを持ってる俺が来ましたよ。

>>182
ソフ開は一夜漬けで受かりましたけど、デザインパターン知りませんよ。
俺がソフ開に必要な知識を身につけた時には、デザインパターンなんて呼び方はなかったしね。
こういうふうにするのが常套手段、という話はあったけどね。

大学の情報系の学部でも、プログラマ養成訓練校みたいなところはともかく、
まっとうなところでは、デザインパターンの内容までは十分に知らないし実践もしてないでしょう。

デザインパターン知ってる人の方が少ないんじゃない？
すぐに思い浮かぶのが５パターンほどだ・・・まあ、これは自分が不勉強なんだけど
それ以外はいきなり言われたらどんなんだっけって考えてしまうよ

人の需要と供給が完全に成りたっていないとは常々思う
新人でいきなり現場いっても役に立たないのは仕方ないとしても、それなりの勉強に
はなると思うけど、その新人を入れる予算と場所がないってところが多いのかな〜

>>181
参考書代はおろか受験料すら出してくれない会社の社員が来ましたよ。
もちろん報奨金なんて・・・、それ食べれるの？　おいしいの？

そのくせ社内には「口で言うだけじゃ（ｒｙ」のポスター貼りまくり・・・。


>>185
ある程度独学でもプログラミングの経験を積めば、デザパタに似た
テクニックは自然と編み出していけるような。
GoF の偉いところは、それらのテクニックを汎用目的に洗練させて名前を付けた、
というだけで、それ以上でもそれ以下でもない。

帰りの飛行気代を出張先で使いこんでしまった奴がいた。
生活費にも困っていた。それは分かるんだが、どうやって沖縄から帰ってくるつもりだったのか。

泳いで。

強制送還

沖縄支社設立

>>190
いいね！俺も沖縄で働きてぇーーーーー
コンビニのレジでビキニの娘に囲まれてぇーーーーーー

米軍人に囲まれる罠。

やらないか。

ビキニよりどちらかというとスク水にTシャツのほうが萌える。

>>191
沖縄くんだりまで行ってコンビニのレジのバイトか

>>195
ビキニの娘に囲まれるというオプション付きならそれも「有り」だと思う。

が、勘違いした関西弁のおばちゃんもビキニな罠。

場所選ばないとDQN観光客の相手ばかりになるぞ

沖縄のリゾートホテルのコテージでならデスマ缶詰も耐えられるかも。

午前：ダラダラとソースを眺めつつオイルマッサージ。
午後：遅めのランチの後、3時間ほど昼寝。
深夜：明け方までバグ取り。

沖縄のリゾートホテルのコテージで

午前：上司の買ってきたカップラーメンで朝食。昼までコーディング
午後：上司が>>191の働くコンビニで買ってきたおにぎりで昼食。夜までコーディング
深夜：上司の観光みやげ銘菓ちんすこうを食す。ついてに上司のちんこすう。夜中3時までコーディング

やらないか。

何べん注意してもホモがまぎれ込む件について

>>202
君の努力が足らんのだ

努力が足りないかどうかは別にして、上司のチンコ吸いたい・・・

まさに努力が足らんのではないんだろうか

どんな努力だよ

個人ではなくソフト業界全体の問題だと思う

ヲンナノマタジカラと書いて努力と読む、とツトム君がゆってた

　　ﾄﾞﾘｮｸ
　　女ノ又
　　　力

中国語かなんかですかね

ソフト業界と致しましてはホモが紛れ込んだり、上司のチンコを吸いたがる輩に
対応するための努力はこれを放棄することを宣言します。

部類としてはソフトと言うよりハードだよな＞ちんこすう

成人同士のプレイならソフトに分類する方がしっくりくると思う。

ソフトかハードかってのは演技者の年齢よりむしろシチュエーションだろ。
無理矢理ﾝｸﾞﾝｸﾞさせるのは紛れも無くハード

中学生や高校生同士はハードだと。





なんとなくわからんでもないが…

>>214
まあ、年齢的に愛情云々より純粋に快感追求がメインだろうからな。
ある意味で成人の同性愛行為よりはサバサバしてる面がなくもないと言えそう。

またホモがまぎれ込んでる件について

沖縄支社設立あたりから全く議論が噛み合っていない

>>200
ｶﾞｸｶﾞｸ(((( ；ﾟДﾟ))))

＞バグがあると言う事は欠陥商品な訳で、欠陥内容を詳しくしりたかったら
＞金払えなど言語道断。
＞ソフトウエア以外の商品でこんなのあります？
テレビのビフォーアフター見てないのかＹＯ！
もっともあれは建造物だからシロウトにも手抜きや欠陥が比較的分かりやすい
他のクルマや電化製品だって、シロウトにバレないというだけで手抜きや欠陥がてんこ盛りに
あると考えるのが自然だと思うが.....

テレビなんてここ何年も観る機会ないけど
ゴールデンタイムとかプライムタイムの番組なんて特に

つ環境の向上、またはバグの削減に効果的と思われる手段は以下のどれか。
１．粘着社長をｓａｇｅる。
２．ﾇﾙﾎﾟ設計は他で頼め。
３．ガッ顧客を手懐ける。
４．つＰＧにコピペをやめさせる。
５. 派遣をハケーンがないようにする。
６．営業などでデスマにならないようにみこみこナース。
７．必要であればフォーマットに従い、追加。逆に、なければ削除。

-----------------------------------------------------------------

> 他のクルマや電化製品だって、シロウトにバレないというだけで手抜きや欠陥がてんこ盛りに
> あると考えるのが自然だと思うが.....

手抜きがあったとしても、新しい製品に買い換えるまで使用上の実害がないんだったら、
何の問題もないだろう

車がエンストしたりペーパーロック起こしたりするのはバグかと言う話になるな。

運用で回避できるんだからバグじゃないだろ。
構造的なもんだから欠陥でもないし手抜きでもない。

結局はQCDの問題だろ？

>>223
今度言ってみるかな。
「エンストみたいなもんですよ。やり直せば大丈夫です」

Ｍ＄社のOSにもしも、
「２ちゃんねるでコテハン名を○崎と定義して、『これからもボクたちを応援してね』って
マルチ書き込みをしまくったらアク禁食らった」
なんてバグがあったとしたら、それってベンダ側で対処してくれると思うか？

俺のダチはそのような苦情を電話で申し立てたら、丁重に断られたってボヤいてたぞ。

行数減らせるような無駄な処理ないような
見やすいソース書け

無駄な処理を書く奴は、それが無駄だと認識出来ないから無駄な処理を書くのだ

だから無駄を無駄と認識できるようになれって言ってんだろ

どうやってかな？

いっそ全ソース削除してしまえ。

無駄な足掻きを

>>221
> つ環境の向上、またはバグの削減に効果的と思われる手段は以下のどれか。

> １．粘着社長をｓａｇｅる。

（･∀･）ｿﾚﾀﾞ!

>>228
だが、空の抽象クラスやインターフェースを作ることを無駄だと思っていたら痛いぞ。
オブジェクト指向は無駄に見えて無駄ではない。むしろ効率を上げる。
保険みたいなものとしても使える。
あとで大事故につながったとき、オブジェクト指向のおかげて助かることもある。
だからといって、起きもしないものに無駄に手がけることがオブジェクト指向とは限らない。

だれもそんな事は言っていないのに

>>235
妄想はげしいな

あほだな
どこをどう読んだらそんな妄想が

この業界も、いい社長さんと腹黒い社長がいるっち。
腹黒い社長のおかげで全体が白い目で見られるっち。
業界団体で自主規制や公表したらどうかね。

悪どい社長のために、業界全体が迷惑しているんだぜぃ。

>>180くらいまでは良スレ。後はいつもの流れだな。

>>177の結論になっちゃったら話すことも無くなるしね。
俺は、法律で品質保障を義務付けるとしたらどういう基準を作れるか、という流れになってほしかった。

仕様そのものに矛盾があるのにか！？

矛盾があるなら指摘しろよ。

要求に矛盾があるから、仕様に矛盾が残り、運用で逃げるという話になる。
そして相手の担当が代わり、追加工事の話が出たときにこじれる。

すぐにカオスな方向に持ってこうとするのな。
建設的じゃないっつーか、おまえはそこで干からびていけ？って感じ？

自殺して若くてかわいそうだと思われるのは２０代までだよな

３０代になると、死が身近になる。
１０代の時であれば、「自殺なんて、ありえない」とみんな思ってるだろうし、
すごいことを自分はするんだと思いながら死んで逝ける。
３０代だと、「死についていつも考えている」というのも、
当たり前すぎてアイデンティティにはならない。

逝くならお早めに。

完璧な商品

メーカーの存続にかかわるじゃないですか、そんなの作っちゃったら

もし、完璧な自動株取引プログラムが出来たら、業界は消えるな。　　（有り得ないが・・

完璧なら用途選ばないからオールマイティーなはず。
というか完璧なOSが最強？
んー、奥が深い…

品質とコストを図りに掛けて何処に落とすかってだけじゃないのか？
今はソフト業界では品質<<<コストなので若干のバグは無視してる

>>250は>>1を100万回読むべし。

スペースシャトルに搭載する品質のコードがほしけりゃ、
それだけの金と時間を用意しとけって。

>>252
少ない人材・時間でノーバグの製品を作る事が、現代の仕事なんだよ。

そう思ってるのが社会一般。

もちろん、リリースする限りバグは0であるべきだが、無理もあるわな。

>>253
ノーバグの製品何て、どこにあるの？
庭石とか？

bugゼロが現在の技術水準では達成出来ない
という事を理解していない奴がまだいるな

> bugゼロが現在の技術水準では達成出来ない

そんなことは誰でも理解している
それを逆手にとって減らす努力をしない奴が多いことを問題にしてるだけだろ

>>256
それって、M＄のこと？

>>257
はいはいマイクロソフト叩きは楽しいね

マイクロソフト叩いて一端のベテラン気取り
それを卒業するまでは初心者のままｗ

bugってハニー
ゲームは1日1時間！

>>253
Ｊａｖａで開発してるんだけど、
リーダーに言ってやってくれ、
漏れが勝手にクラス増やしたって怒るんだよ。

奴の思考はＣ言語だ。どうでもいいけど「構造体」って言うなよ。

>>261
まあ、Beanと構造体は似たようなものだし気にするな
俺はコンボボックスっていうのに未だに馴染めない
クラスを増やす事に関しては、ＰＪ毎にいろいろ決まりあるからなんともいえんな
某メーカーだとクラス追加するのに申請をして、品管が配布ってところもある

＞某メーカーだとクラス追加するのに申請をして、品管が配布ってところもある
品質めちゃめちゃ悪くなりそう

>>256
現状を知らない学生の理想論なんて、賛同得られるわけ無いでしょｗ

>>1
どこの3流ライターでつか？
なんの雑誌に掲載予定なんでつか？

てめぇがテストすれば見つかったバグを「バグを無くす事なんて出来ないからしょうがなかった」の一言で済ます奴は死んだほうがマシ。
ユニットテスト書けって言ったら「どんなにテスト書いてもバグ無くすことなんて出来ないですよ？」なんて素っ頓狂な返事する奴も死んだほうがマシ。
100点なんて無理でも98点と60点じゃ雲泥の差だろうが！
死ね！

>>266
>>255のことかｗ

>>266
死ぬつもりは無いけど。御愁傷様です。ｗ
ところで工程標準が無い組織でお仕事をされているのですか？
まあ試験の重要性が理解出来ない人には何を言っても無駄のような気がしますけど

>>266
テストとコーディングを別メンバーにしてしまえ

>>266
おまえもテストの意味を知らないから、現場からバカにされてるだけだろ？

品質管理工程のテスト項目は、納品時に添付され、品質を保証するためのもの。
プログラマのデバッグの為の物ではない。

はっきり言ってあんなに沢山バグ（欠陥）を含みながら作るのが信じられない。
ソフトウェアが比較的簡単に修正できるから
怠慢になっているんだろうな。

もし、ソフトウェアが家作りのように、簡単に修正が出来ないものなら、
バグを含みながら作ることはないだろう。
あとからテストするなんて行為自体を減らせる。

簡単に修正できるという性質は、変えられないから、
後はプログラマが、集中してバグを含まずに作るように基本的な技術力を上げろ。

ソフトウェアを家作りに例えると、
適当にクギ打って、適当に組み立てて、
あー。ここクギ曲がっていますね。って抜いてもう一度差しなおし。
あー。ちょっと組み方変ですねー。ばらして組みなおし。
そんなことばっかりやっているよ。

困難じゃボロボロになるのは当たり前。
プロなら、一回で綺麗にクギを差し、正しい組み方で
寸分の狂いも無く組み立てる物だ。

>>271,>>272
なんで「ソフト」ウエアなのか、知ってる？

>>271 >>272
ちと古いけど、現時点でも読む価値はある。
http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

>>272
最近の家は、そういう作りが少なくない。

＞困難じゃボロボロになるのは当たり前。
「こんなん」、誤変換ですか？
もっと集中して文章を書きましょう。

建築業界ってのは、部品も素材も規格化進んでる分野じゃなかろうか。

規格化は望まれているが、それを目指した巨大金食いプロジェクトがゴミとなっている現実を見ると、
コンピューターの進歩が頭打ちにないと無理だな。

やれやれ、既得権をまもろうと必死だな。
そんなに欠陥をあるのに、開き直りたいのか。

いい加減ソフトウェア業界にもPL法必須だな。
バグ1件につき1万ぐらい金返せ。

>>278
そんなにマの仕事が気に入らないならおまえがソフト作れ。

たった一万かよ

ＰＣの進歩はもう頭打ちになって良いんじゃないだろうか。
ぶっちゃけ、今のＰＣ以上のスペックが一般用途で必要かというと疑問。
ここでPL法だのなんだの言ってる奴は、研究・シミュレーションとかの
専用機について言ってるわけじゃあるましし。

>>281
>今のＰＣ以上のスペックが一般用途で必要かというと疑問
これは・・・もう何年も同じ事を言われていますね。
ベンダー側が新しい用途を必死に考えていますから
ご心配には及ばないかと。（笑）
#パーソナル天気予報とかね

PCの進化はソフトウェア技術の低下を招いているからなぁ。
ちょっと前ならプログラムの無駄を省いて
最少の労力で動くようにしていたのに、
今は無駄に速いから、適当な物を作っても
そこそこで動く。そうやって技術力も低下してる。

>>282
> >>281
> >今のＰＣ以上のスペックが一般用途で必要かというと疑問
> これは・・・もう何年も同じ事を言われていますね。

281って過去の例から何も学ばない奴なんだろうなw

>>283
少し違います。
サイズとか速度とかが重要な時代は確かにありましたが、
それはそのプログラムが動作する環境ゆえに重要であったに過ぎません。
ハードの低廉化によって動作環境が変化拡充した現在においては、
プログラムのサイズとか速度とかが殆ど重要では無くなりました。
そういう意味で「ソフトウェア技術そのものが変化した」と理解しています。
#現在のソフトウェア技術の主要なテーマの一つは「仕様の肥大化への対処」かな
もちろん「サイズとか速度とかがいまだに重要な分野もある」ことは理解していますが。

俺はバグ＝期待されるアウトプットが得られない状態と考えているが、ユーザーを教育することにパワーをかけることによって随分マシになった

あと>1は下請け法も勉強しといたほうがいい、訴えられるぜ

>>283
そういうことあるよね。
データベースソフトで検索が遅いの。
でもそれで我慢して使っていたらしい。
中身を見ると、もうぐちゃぐちゃ。

ちょっと前だったら絶対実用に耐えられなっかだろうけど、
CPUスペックを上げることでどうにか我慢できるレベルに持ってきてる。
昔の人にとっては当たり前の工夫という言葉を知らない。
CPUスペックを上げるという自作初心者程度の解決策しか技術を知らない。

OJT-T （OJTからトレーニングを引いた物ｗ）
なんかやっているからいつまでたっても技術がつかない。

>>284
同じ方法論繰り返す必要もないだろ？
バグが問題だろいうなら、それを防ぐ為の
規格の凍結ってのもアリだろ。
小型化、省エネ静穏化という方向もあるんだし。

>>287
DB検索でCPU性能がネックになってるのか？

普通になるだろｗ

メモリと記憶装置の方がネックじゃね、
大きなシステムなら尚更に。

>>290-292
不毛だ……不毛すぎる。

いや、ちょっと前→今のCPU載せかえで解消されるレベルなら、
CPU以前の問題じゃないんかなと。

>>292
それは正しく作られている場合。
作り方が悪くて無駄にCPUを消費して遅くなっているのに
CPUスペックが高いために無理やり動かしている。
CPU性能が上がってしまって技術力が低下している。

ちなみにメモリについても同じ事が言える。
作り方が悪いために必要以上に大きなメモリが必要になってしまっているのを
自作初心者的発想で、根本的な問題を治さずにメモリを増やすだけの
素人集団が増えつつある。

つ【インデックス】

遅いからアルゴリズムを再検討しよう
というのは支持出来るけど
でかいからデータの持ち方を工夫しよう
つうのは支持出来ない

>>297
同じ事なのに、何故、片方は支持出来てもう片方は支持出来ないの？？？

>>298
うーん。どちらも作りなおしであるのだけれど。
「データの持ち方を工夫しよう 」つうのは、開発工数が余計にかかるよね。
メモリに持ちきれないから二次記憶に移行するという作業が主体でしょ
当然、二次記憶上のデータの取り扱いはメモリ上のデータの取り扱いより大変なわけ
結局これはメモリサイズと開発工数のトレードオフにしか過ぎないのであって、
どちらが高価かといえば後者の場合のほうが圧倒的に多いという判断だよ
速度はソフト自体の価値を左右する問題だけど
サイズの問題はメモリを増やせば解決する問題である場合はメモリを増やすことで対応したいのですよ。
そういう意味で>>295の見解とは真逆なんだけど。素人呼ばわりする奴にはレスしたくないしね。
まあ295とは判断が逆であるということかな。
まあ多数のクライアントにインストールされるソフトの場合は話が違ってくるだろうけどね

SQL使えば？

>>295
>>294

だから、アルゴリズムとデータ構造は、表裏一体なのに…

そもそも現場のバグ指数ってのもおかしな話だと思う
1kステップあたり8個もでないよ
それより設計段階で起こりえない場合の処理を
考慮してない設計が多いのはなんとかして欲しいものだ

バカよけを華麗にこえるバカ
こえられるバカ

開発中に気づいてもよさそうなモノを
懸案なり周知なり出さずにリリースを迎えるヤツも居るがな。

いや、バカは言いすぎか。　役目は誠実にこなしてるからな……。

>>302
どこでそんな古くて使い物にならない知識を覚えて
かたくなに信じてるの？

>>306
ほらね。
最近の奴は基礎も知らないバカ。
だからバグなんて平気でいれて、
バグなんてなくならないとうそぶく。

もしバグなんてないのが当たり前な
世界になったら困るからねぇｗ

まさか本当にアルゴリズムとデータが表裏一体だと思ってるのか？？

×　データ
○　データ構造　

>>308
307は306で「表裏一体」を否定されたんじゃなくて、
「アルゴリズムやデータ構造を勉強すること」
を否定されたと思って煽ってるんじゃないか？
単に話の流れが読めないアホだと思う。

>>303
ステップ数とバグ個数を比較してる時点で馬鹿。

>>310
309の指摘しているようなすり変えが気にならないのは、ご本人だからかなｗ

>>307の
＞最近の奴は基礎も知らないバカ。
という発言は「アルゴリズムとデータ構造は表裏一体」というのが「基礎」だと
言ってるのか？
だったら時代遅れといわれてもしょうがないだろ。

「アルゴリズムやデータ構造」が基礎だと言ってるなら、誰もそのことを
否定してないわけだが。

今の話は297がやってるデータベースの事だろ。
基礎だのデータ構造だのアルゴリズムだの。

いい加減、バグ混入が当たり前という風潮をやめるべき。
クソコード書いて、遅いのをマシンスペックのせいにするのをやめるべき。
技術力をつけずに、言い訳して必死に自分を守ろうとしている奴はこの業界からやめるべき。

バグ混入が当たり前？
試験項目パスしたといいつつ、動かないとかなら当然対応するが、
試験項目にない物を後から言われても、それは別途対応になる。

データベースの開発においてデータ構造とアルゴリズムに関連性無い、
関連あるのは古臭いとか時代遅れとか主張するのが意味不明だと。
それとも、いつのまにかもっと抽象的な話題に変わってたのかな。

なんで「データベースの開発」に限った話になるのかが
理解出来ないのですが

みなさん大人なんだから、314さんの脳内を想像して話をあわせてあげましょう

ああ、最近の若い奴らは、クラスライブラリに頼り切って、データ構造とか全然考えてないんだろうな。
これだからアプリケーションプログラマは低能だって言われるんだよな。

>>320
> ああ、最近の若い奴らは、クラスライブラリに頼り切って、データ構造とか全然考えてないんだろうな。

どっからそんな妄想が？
この爺さん　もうボケが始まってんじゃないの？

>>320
ライブラリへの引数、戻り値もデータ構造じゃないの・・・？

>>322
リストやスタックや木構造のことを言ってるんだろうが、
そんな当たり前のことを知ってるだけでデカイ顔してる
勘違い馬鹿オヤジには関わらないほうがいい。

>>322
ｱｲﾀﾀﾀ

マジなのかギャグなのかわからん小学生のケンカみたいだぞおまえら。

バグ０当たり前の世界を作れ

おまえが作れ

おいらの存在がバグなので無理です。

>>246
あまりにも非建設的で気持ち悪いことを言う香具師だな
お前が逝け。
死ってのは自殺だけじゃない、
他殺、病死、事故死、安楽死、自然死などいくらでもある。

それに自殺は自分を殺すという殺人罪だぞ。
自殺未遂も犯罪だ。無理心中なんて言語道断。
それに30代になると死が身近になるって意味がわからんぞ。
20代の漏れに説明せい

>>253
> >>252
> 少ない人材・時間でノーバグの製品を作る事が、現代の仕事なんだよ。
>
> そう思ってるのが社会一般。

それは一部の日本社会に限定されていることであって
アメリカなどを含む世界全体の業界ではその考え方は通用しない。
だから日本でソフトを作っても世界的に売れるものはすくないのだ。
顧客がそれだけソフトウェアの品質に対しての意識が低すぎるってことだな。

日本の顧客は製造業に強いという歴史があるためは
「ソフトがなければただの箱」という考えよりも
「ハードがなければただの紙」という考えのほうが強いみたいだな。
だからハードウェア業界の連中はソフトウェアを見下し安い給料で
プログラマを働かせることばかり考える。
だからWinnyやSoftEtherのようなソフトが企業だけで作ることができず、
そのようなアイデアを考え付く有能な賢い顧客すらもいない。
だから日本のビルゲイツすら生まれない

>>262
構造体と比較していきなりBeanと言い出すのはなにかおかしい。
クラスの特徴として、ポリモーフィズム、継承、アクセス権が設定できることも重要だ。

クラスを増やすこともプロジェクトに縛られている？
なんてあふぉな会社なんだ。
頭悪すぎ。そこのメーカーはデザインパターンってものをよく理解してないんじゃないだろうか？

いちいち人のやり方にいちゃもんばかりつけているから開発効率がさがるんだと言ってやれよ。

分割統治とかよくしらない香具師がそういうウザイ制限をかけているんだろ

>>264
ソフトウェア工学を熟知しているなら、学生でもバグの無いプログラムを
作ることが不可能なことくらい知っているぞ

>>266
ねえ、サンプリング周波数ってご存知？

>>271
> はっきり言ってあんなに沢山バグ（欠陥）を含みながら作るのが信じられない。
> ソフトウェアが比較的簡単に修正できるから
> 怠慢になっているんだろうな。
甘い甘い。オブジェクト指向を知らない香具師がソフトを作ると
簡単に修正するなんて容易じゃないぞw
とくにハードコーディングばかりしてる香具師のコードを修正するのは
どれだけ大変なことか。おまいさんみたいな経験の浅いｳﾞｧｶには理解できまい。

>>271
> もし、ソフトウェアが家作りのように、簡単に修正が出来ないものなら、
> バグを含みながら作ることはないだろう。

家を建てるとき、角材に多少の不純物が含まれることはある。いたし方が無い。
エントロピーってものは必ず存在する。いたし方が無い。

君も物理学を勉強したことがあるなら、「剛体」なんてものがこの世に存在しないことくらいは
わかっているだろう。
家だって、築30,40年くらいの寿命しかもたないもんだ。
それがへーベルハウスだったとしても80年もてばいいだろう。
それを君は、永遠に長持ちする家を作って欲しいというありえない幻想を抱いているわけだ。

> あとからテストするなんて行為自体を減らせる。
> 簡単に修正できるという性質は、変えられないから、
> 後はプログラマが、集中してバグを含まずに作るように基本的な技術力を上げろ。

甘い甘い。テストは重要。君はテストの自動化ってものをわかっていないようだね。
JUnitというテスティングフレームワーク、やAnt, XDocletという自動化ツールを使ってみれば
テストの自動化ってものが徐々にわかってくるよ。

テストの行為事態を減らしてはだいぶソフトウェアの信頼度は下がる。
テストはますます必要になる。だが、テストの自動化によって、テストという行為にかかる
負担を減らすことはできるわけさ。

>>272
そこではもっと大事な話があるがな。
プロはそんな小さなところよりももっと設計をしっかりするってもんよ。
それに、釘を打つのも電動式にして自動化する。それが真のプロってもんだ。
「達人プログラマー」という本には、達人になりたければビルドツールを使って
自動化することが重要だと解説している。

高層ビルを建設するのに、クレーンも使わずに素手でIビームを50階建ての最上階まで
運ぶのは素人のやることだよ。

それから、テスト駆動開発を怠らなければ
釘を何度も打ち直すというような、
テストのためだけにコードを修正しなおす手間も減る。

それからデバッガも重要。単体テストのためにテストケースクラスを
作ることも重要ってことよ。

テストしながら開発する手法についてはケントベックが書いた「テスト駆動開発入門」
を参考にしてくれ

>>278
それだとかなりの不公平が生じてしまうもんだな。
whileループなどにバグがあった場合、
ループ回数が10000回を超えたら、その分だけ倍率をかけて
1億円を払えって？　馬鹿馬鹿しい。
それにバグ一件の単位をどうやって測定するのかな？
どこからどこまでをひとつのバグをみなすのやら。


だれもプログラムを作らなくなってしまうぞ。
そんなことよりも、オープン化のほうが重要だぞ。

君のやり方だと、道路を民営化しろといっているようなものだ。
ちなみに、道路公団を民営化してはいけない、といっている意味では無いぞ。
ある道路を歩くために、こっからここまで逝くのに定期券が必要？
だがブロックの裏側を迂回した場合はまた別の定期券が必要？
なんとも哀れだ。だからああいうことは鉄道と違って国がやるわけだ。
ソフトウェアでも国営とおなじような概念を導入するには
オープン化するしかないわけだ。
とにかく、必要不可欠な要素はオープンソース化するわけだ。
君にはオープンソースという概念が理解できるだろうか？

どうしてこの板には「××方法論ﾏﾝｾｰ厨」が多いのだろうか。
すべての方法論は　one of them に過ぎないことを理解出来ない
人間がこんなに多いことがとても不思議だ

>>277
> 規格化は望まれているが、それを目指した巨大金食いプロジェクトがゴミとなっている現実を見ると、
それはオープン化を怠ったから失敗しただけなんだよ。
独占すると規格化はうまくすすまないわけだ。

>>331
まあ、もちつけ
ひとまず各個人が勝手にクラスをぽんぽん作るのも問題じゃないか？
既に同じ機能のクラスがあったりすることあるでしょ
そのあたりを調整する人はいるでしょ
さすがに申請などで絞るのはかなり問題あると思うが

ちょっと前に、最近の若造は速度のことを考えずにコーディングしやがる、という話があったが・・・。
速度のことを考えないのは若造だけではないよ。30歳以上のベテランだって、速度を考えないのはいる。

まず、
「その処理のオーダーは?」
と聞いても、ぽかーん。

設計段階から処理のオーダーを考えてないから、
コーディングした人が自分でやるテストでも少量のデータしか与えない。
んで、後のほうの工程で、実稼働と同じだけのデータを与えると、気が遠くなるほど重い。

で、書いた本人の言い訳
「最初から最適化したコードを書くのはアホだ。
実際に動かしてみて、ネックになっているところだけ直せばいい。」

そう言うのなら、自分でテストした段階で見つけて直しておいてほしいし、
そもそも小手先のテクニックで速いコードを書くことなんて誰も求めてない。


それから、CPUがどんどん速くなっているのは、キャッシュにヒットした時の話で、
キャッシュにヒットしない場合の速度は、ほとんど変っていないことを、知らないのが多い。
2GHzでこの速度だから、3GHzのCPUを使えば目標値を達成できますね、なんて平気で言いやがる。
お客さんでも、知らない人が多いけどね。なんで遅いCPU使ってるの? とか言われる。

>>341
>「最初から最適化したコードを書くのはアホだ。
>実際に動かしてみて、ネックになっているところだけ直せばいい。」
これ気づくのが結合かシステムテストあたりかと思うけど
そのときに修正したらテストが大変そう

システム内やプログラム内の構成要素の結合度が密なＤＱＮシステムならそうだろうが、
直交性の高い構造になってれば問題ないだろ？

要求仕様を達成できる設計をした上で
>実際に動かしてみて、ネックになっているところだけ直せばいい。」
なら、密だろうが疎だろうが問題無いんじゃまいか。
問題にしてるのは実際に動かしてみないと達成できるかどうかわからないって言う奴。

自分で作る物の評価も出来ないのか？
おまえは機材の大きさ考えないでカラオケボックス作っちゃう荒井注なのか？
と言いたくなる。

自分で作った物を自分で評価しないで悪手良手が分かるようになるんですかね。

動かしてみたら、
まるでハングアップしているかのようにドンガメだった
というケースの場合、最初の設計からやり直し。

設計段階で、ちったぁ速度のことを考えろ、と言いたいのだが、
まるで考えない人が大杉。

速度のことばかり考えすぎて保守のしやすさを
考えてないやつもどうかと思うが。

>>344
342の「結合テスト時に気づいて直してたら、テストが大変そう」という
発言を受けて、結合度が疎なら問題ないだろといってるだけだろ。
文脈嫁

結合の密と疎じゃ、かなり保守で影響でるかと・・・
でもそのあたりにいつ気が付くが問題じゃない？
このあたりが結合までいってしまったら簡単に直せなくなるし

>>346
どんなに保守しやすくても、要求仕様を満たせなければアウト。
速い = 保守しにくい、というわけではない。
論外な例を挙げても不毛。

速度よりも保守性が大切だと言ってる人は、
O(n)の速度のことしか考えてないのだと思う。

O(n)なら、保守性を優先して冗長で遅いコードを書いても構わないんだよ。
速度を気にしないといけないのは、O(n^x)で、xに対してnが大きくなる場合。
そういうのは、保守性よりも優先しなくてはいけないし、
そもそも保守性とは相容れないものでもない。

納期一ヶ月しかないの15営業日を仕様策定と仕様変更に費やす
DQN撲滅しないかぎり何にも意味内

そういう奴に限ってPGなんか簡単でしょって言う罠

まず、偽装派遣を止める。
大手は直接、おれ達を雇用する。

話はそれからだ。

>>352
お前など、雇用するに値しない。

>>352
目をさませ

>>352
びっくりする程安くなるぞｗ

某大手にいました。

本社の正社員プログラマ = 月給20万残業代無し。
子会社の正社員プログラマ = 同上
派遣のプログラマ = 月給30万残業代満額支給

ちなみに
派遣の事務員 = 月給20万残業自体がない


悲しいけど、これが事実です。

神様がプログラミングした俺たちのDNA自体
バグだらけのスパゲッティコードなのにな。

神「冗長性が高いと言いたまえ」

密結合だね
どこか直したら何が起きるか予想できない

>>359
結構他の生物間で代替えの効く構造らしいぞ。

PRESIDENT　12月号　111ページ
全公開！日本人の給料

職業　平均年収　人数
プロ野球選手　3743万円　752人
弁護士　2101万円　2万人
歯科医師　1329万円　9万人
医師　1227万円 　26万人
警察官　840万円　23万人
優良上場企業サラリーマン　808万円　96万人 　←世界最強のトヨタ社員ですらこのぐらい
農家　765万円　368万人
地方公務員　728万円　314万人 　　　　　←給食のおばちゃんもこのぐらい
国家公務員　628万円　110万人
上場企業サラリーマン　576万円　426万人
プログラマー　412万円　13万人
サラリーマン平均　439万円　4453万人 　　　　　←日本人の平均
ボイラー工　403万円　1万人
百貨店店員　390万円　10万人
大工　365万円　5万人
幼稚園教諭　328万円　6万人
警備員　315万円　15万人
理容・美容師　295万円　3万人
ビル清掃員　233万円　9万人
フリーター　106万円　417万人 　　　←生きていけるの？

ぷれじでんとってソースに問題があるな。
赤旗あたりのソースなら信用していいかもしれね。

医者も公務員もそこまで高くないんじゃなかったっけ？
フリーターは少なすぎる気がする

フリーターの潜在的な総数は500万人はいる、というわけですね。

どこかの会社の社長がバグをゼロにしろとか言ってましたわ。
QCDで言ったらQ偏重だけど、昨今D→C→Qの順番で
要望が強いのが現場の実感。
ま、普通のカネと期間じゃあり得ない話なのでとりあえず
スルーしてます。

「バグをゼロ」
は素人の戯言にしか聞こえない

バグが無くなったら仕事が無くなる

>>366
「『バグをゼロ』は素人の戯言にしか聞こえない」は
素人の言い訳にしか聞こえない

>>368
バグゼロの（大きめの）システムの実例を提示出来るかい？

バグゼロなんてほぼ無理。
何十年も使ってりゃ別だが。

>>370
仕様通りの挙動です。

これで良いだろ。仕様書は後から直せばいいし

そりゃ、辻褄合わせてるだけで、解決にはなってないじゃんw
BUGゼロは不可能だと認めたく無いだけだろw

バグあったっていいんだよ。
使う側が文句を言わない種類のものであれば。
金もらってやってんだから、
バグを減らそうと努力するのはあたりまえ。
テストをちゃんとやるのもあたりまえ。
それができないっていうのは、

ス　キ　ル　の　問　題

スキルありません残業はしたくありませんでもお金欲しいです
気持ちはわかるよ。
でもさあ、言い訳ばかりしてないで仕事に情熱を持とうよ。

有名絵師さんたちのポスター原稿を見てると修正液の跡がない人の方が珍しいし
納品物の演奏シーケンスを見ると演奏に反映されないバンク切り替えとか結構入ってる
シナリオの盛り上がるところでのチェックをすり抜けてきたすべてをブチ壊す誤字とか
まあプログラムに限定はされないです(´ー｀)

完璧主義者って相手にも完璧を求めてそれが満たされないと執拗に攻撃するよねヽ(´ー｀)ノ

>>374
なんだエロゲ屋だったのか。

いやちょっと待て。
今時「修正液」だの「演奏シーケンス」だの、って何だ？

お客さんに「二ヶ月で作って。でも最初はバグがあっても、使いながら直していくから」とか言われて
「え！？」と逆に疑いの目で見てしまった。

まあ今まで品質悪すぎで諦めがついたということだと思うが。

>>375
そうなの？(;´Д`)このへんはロープレ屋にいた時の経験で書いてみた結果

>>376
俺はアナ(クロ|ログ)の話しかできない(´ー｀)統合失調で8年間おびえ続けていたからな

何この自己主張の強いコテ

>>373
> 金もらってやってんだから、
その金が足りないのですが

> 残業はしたくありません
残業したくても予算がありません

> テストをちゃんとやるのもあたりまえ。
ちゃんとテストをやるには、工数だけでなく期間も足りませんが?

>>374
納品前に修正されてるんだったら問題ないじゃん。

この業界でも偽造問題ですか

ドキュメントでっち上げまくり。
仕様書が後から完成

ついでにソースコードもかなりハック。

>>1
電子カルテ買った医者に多いよね、こういうこと言うやつ

>>385
まー。電算レセプト系では確かに多いけどな。
だが基本的にレセプト系は「保守料／月」という費用を払っているからな・・・。

>>374

完璧主義者は、自分が完璧では無いということに気付いていない。

ほっとけ！

統合失調を本当に８年やったなら、「新しい世界や新しい価値観」を持っているはずだ。

それは１００人いても９９人は、持ち得ない類まれな才能さ。

オレは統合失調は門外漢だからこれ以上はコメントしないが．．．．

糞コテラッシュだな

>>388
それもそうだな

糞スレばかりだからしょうがない

バグが無いことを証明するのは不可能です。
ソフトウエア工学を勉強すればわかります。

>>391
詳しく！

＞＞392
基本情報の出てます。
それぐらい、自分で調べてください。

>>393
しったかぶりはやめようよ

これはあげる必要がある

>>392
プログラミングに限らないぞ

いわゆる悪魔の証明ってやつだ。