5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

動けばイイじゃん。ウダウダ能書き垂れる奴って何なの?

1 :デフォルトの名無しさん:2006/05/14(日) 13:14:19
ちゃんと動くプログラム書いてるのに、あれこれ屁理屈言ってくる奴。

オマエは自己満できていい気になってるかもしれんが、
俺たちは動くプログラムを作るのが仕事なんだよ。
屁理屈のために無駄な時間掛けてるほどヒマじゃねぇんだよ。

2 :デフォルトの名無しさん:2006/05/14(日) 13:18:30
でも、そんなこと使ってる奴らにとってはどうでもいい話。

3 :デフォルトの名無しさん:2006/05/14(日) 13:21:59
いいじゃん別に。
2chなんかひまつぶしなんだからよう!

4 :デフォルトの名無しさん:2006/05/14(日) 13:22:43
ここはお前の日記帳ではありません

5 :デフォルトの名無しさん:2006/05/14(日) 13:29:18
>>1
詳しい話は違うかもしれんが、
チーム開発だと、「ちゃんと動くプログラム」だけじゃだめなんすよ
プログラミングのスキルや知識はあるんだけど、
すごく雑なプログラム書く人がいる
そういう人は所詮、日曜プログラマなんだよ

6 :デフォルトの名無しさん:2006/05/14(日) 13:38:05
>>5
>プログラミングのスキルや知識はあるんだけど、 
>すごく雑なプログラム書く人がいる 

その「雑だ」という例を挙げてみて。

もしかして、配列に値を設定する前に
"念の為に"
memset で 0 クリアする事をやっていない、
とかの話?(w


7 :デフォルトの名無しさん:2006/05/14(日) 13:41:20
>>5
全然理由になってないよ。
仕事だからこそ、無駄なことに時間を使っちゃダメなんだよ。
半日で終ってるモノを屁理屈で何度もやり直して丸1日とか2日とか掛けるのは、
仕事を舐めてる自己中自己満のやることだよ。


8 :デフォルトの名無しさん:2006/05/14(日) 14:01:00

[プログラマー] 動けばイイじゃん。ウダウダ能書き垂れる奴って何なの?
http://pc8.2ch.net/test/read.cgi/prog/1147580092/

9 :デフォルトの名無しさん:2006/05/14(日) 14:06:20
保守する人の気持ちになろう

10 :デフォルトの名無しさん:2006/05/14(日) 14:07:45
雑ってのもあれだよな。
変更がありそうなところにちょっと変更があっただけでもバグになる雑さは問題だが、
屁理屈だけの能書きにあってない、って雑さは実際は問題にならないかも。

11 :デフォルトの名無しさん:2006/05/14(日) 14:10:41
>>10
>屁理屈だけの能書き

ってどんなの?
それともウダウダ2ch で愚痴垂れてるだけ?

12 :デフォルトの名無しさん:2006/05/14(日) 14:19:09
>屁理屈
いやまぁ、だからさ その1の言う屁理屈が何かがはっきりわからんと・・・
俺は最初に断わりとして「詳しい話は違うかもしれんが」ってかいてあるので
話がずれている可能性はある

>その「雑だ」という例を挙げてみて。
俺が言っているのは、例えば動画変換ライブラリとか作れちゃう知識の持ち主でも
普通のプログラム書かせるとソースとしては複数開発には向かないものになる
「雑」というのは「煩雑」ということ


13 :デフォルトの名無しさん:2006/05/14(日) 14:21:30
>>12
>普通のプログラム書かせるとソースとしては複数開発には向かないものになる 
>「雑」というのは「煩雑」ということ 

ようするに「俺には理解できないものを書く」ってことね(w

ま、そんなことだろうとは思っていたが。


14 :デフォルトの名無しさん:2006/05/14(日) 14:25:24
Q.ウダウダ能書き垂れる奴って何なの?
A.女の腐ったような奴なの。

15 :デフォルトの名無しさん:2006/05/14(日) 14:25:44
もうちゃんと動いてるのに、
もとから依存してるオブジェクトで、そこを切り替えるなんてありえねぇってのに、
「コンストラクタ使っちゃダメだろ」「依存が強まっちゃうよ」とか。
切り出してもそこ以外で使う事なんてあり得ないのに、
「この辺は別クラスに切り出せるよね」とか。
そこ以外やることはあり得ない処理だし、それが出来ちゃう公開メソッド用意してるくせに、
「この処理はこっちのクラスでやるべきだな」とか。

おれらがやってるのは宗教じゃねぇんだよ、仕事なんだよ、仕事。と。


16 :デフォルトの名無しさん:2006/05/14(日) 14:27:03
いや。ある意味宗教に近い。
大司教(クライアント)の言うことは絶対だしな。

17 :デフォルトの名無しさん:2006/05/14(日) 14:28:17
>俺たちは動くプログラムを作るのが仕事なんだよ。
仕事なんだろ?引継ぎ可能な形で収めるのが普通
変数をa,b,cとか書くと、それだけ理解する工数が増えるだけだよ
すごく長くて、入れ子の多い関数書かれても、後輩がやる気なくすだけだよ
読み手のスキルに関係なく、そういうソースを扱うのは後々工数がかかるということ
「動けばいい」というのは目先の判断であって将来的にかかる費用が考慮されていない

18 :デフォルトの名無しさん:2006/05/14(日) 14:28:17
こんなこと言うクライアントなんかいねぇよw
つうか、クライアントの要求を納期通りに仕上げることの邪魔でしかない。

19 :デフォルトの名無しさん:2006/05/14(日) 14:30:30
キモオタヒョロヒョロ大卒厨

20 :デフォルトの名無しさん:2006/05/14(日) 14:31:16
それだけじゃ良く分からんな。
全体的にレベルが低い職場なのかもしれないし、>>1 の説明能力が低いだけかもしれないし、
両方かもしれないし。

21 :デフォルトの名無しさん:2006/05/14(日) 14:31:47
世の中、何が雑だと言えば、
「雑」と「煩雑」の区別をつけず、
一緒くたに「雑」の一言で
片付けることほど雑なことはないと思う。


22 :デフォルトの名無しさん:2006/05/14(日) 14:33:24
>>17
俺は変数名はちゃんと付けてるが、
保守の専門卒の奴らは英語が分からないので意味なし。
あと、納めた後の工数×単価が、開発時の無駄な工数×単価以上に本当に節約されるのか?
それに、会社として納品までの商売だったら?

23 :デフォルトの名無しさん:2006/05/14(日) 14:33:26
>>15
それは、オブジェクト指向の話だったということか?
どれをどこでやれば言いなんていうのを突っ込まれるということは、
突っ込まれる人がソース全体を把握せずに修正しているって言うことだな
大きく言えばソースコード規約違反
ただ単純に「動く」物作っても、他の人から見れば「こいつ、やっつけ仕事で修正しているな」と思われるだけだよ


24 :デフォルトの名無しさん:2006/05/14(日) 14:33:48
>>17
>「動けばいい」というのは目先の判断であって将来的にかかる費用が考慮されていない 

ところで、
そこで削減した「将来的にかかる費用」は、
俺達に還元されるのか?


25 :デフォルトの名無しさん:2006/05/14(日) 14:37:37
>>23
>突っ込まれる人がソース全体を把握せずに修正しているって言うことだな 

はい。そもそも把握するべきソース全体(及び仕様書)が
見れないものですので・・・


26 :デフォルトの名無しさん:2006/05/14(日) 14:37:56
>そこで削減した「将来的にかかる費用」は、
>俺達に還元されるのか?

会社側に不利益だからだめだということだ
その理解する時間分他の仕事をお願いできるわけだからな

「俺たちに還元」って、「俺たちに還元されなきゃ意味が無い」っていうことか?
おいおい、待ってくれよ「仕事」といったのは>>1のほうだぞ?


27 :デフォルトの名無しさん:2006/05/14(日) 14:38:03
>>23
しつこいけど、全然理由になってないよ。
教義はイイから、利益を説明してくれ。
宗教じゃなくて仕事でやっているんなら。

28 :デフォルトの名無しさん:2006/05/14(日) 14:40:45
>>26
「俺達」を会社まで範囲を広げちゃいけない訳じゃないぜ。
それに、自主的に会社まで範囲を広げて、ちゃんと評価されるのかい?
評価もされないのに勝手にやっても、それはお節介かボランティアだぜ?

29 :デフォルトの名無しさん:2006/05/14(日) 14:41:23
一回他人が書いた雑なプログラムを保守してみれば分かるだろ。
まして自分が書いたモノを1年後に自分で保守した時に
あまりに汚すぎて他のスケジュール押してまで修正する羽目になった身としては、
極力綺麗なコードを心がけるようにしてる。自分のためにも。

30 :デフォルトの名無しさん:2006/05/14(日) 14:42:16
>>28
そこまでいうのなら、君がどこかの会社に入るとき面接でなんていうのかね?

31 :デフォルトの名無しさん:2006/05/14(日) 14:43:42
>「俺達」を会社まで範囲を広げちゃいけない訳じゃないぜ。
>それに、自主的に会社まで範囲を広げて、ちゃんと評価されるのかい?
>評価もされないのに勝手にやっても、それはお節介かボランティアだぜ?
ちょっとまてよ、その考えはもはや「仕事」じゃなくなっているだろう。

32 :デフォルトの名無しさん:2006/05/14(日) 14:44:19
その後の保守の仕事を確保するため、
極力雑なコードを心がけるようにしてる。自分のためにも。


33 :デフォルトの名無しさん:2006/05/14(日) 14:45:07
>>31
じゃあ、納品で終わりの案件中心の会社ならどうなんだぜ?

34 :デフォルトの名無しさん:2006/05/14(日) 14:45:09
得てして保守の仕事は他の仕事が忙しい時に回ってくるもんだ。
マーフィーの法則

35 :デフォルトの名無しさん:2006/05/14(日) 14:45:51
>>33
その会社からは、次の仕事が来ないだろうな

36 :デフォルトの名無しさん:2006/05/14(日) 14:47:10
>>31
激しく同意。

俺達の仕事ってのは、『動くプログラムを作る』事じゃなくて、『会社としての利益を上げる事』だよな。
その利益を ”得る” 為の手段がプログラムを設計・製造する事であって、
利益を ”上げる” 為に、ちゃんとした設計・プログラムを書くことで、
同じようなプログラムは再利用し、機能拡張や修正の仕事が着ても間単に修正できるようにし、
工数短縮して他の仕事したり、スケジュールが遅れて利益を減らす事が無いようにするんだよな。

37 :デフォルトの名無しさん:2006/05/14(日) 14:47:12
おまえ、もう一杯一杯だろ?理屈ばっかりでお話にならないよ

>ならどうなんだぜ?
語尾もおかしくなっているし。

おまえ、SEと話すとき、足震えてるだろ?w

38 :デフォルトの名無しさん:2006/05/14(日) 14:47:45
別にそんなに読みづらいコードを書いてる訳じゃない。
連中が言うように辺に細分化した方が読みづらい、読むのが面倒な事の方が多いと思う。

39 :デフォルトの名無しさん:2006/05/14(日) 14:49:21
>>38
そんな事はない。

あくまでも基本的にだが、これ以上ないくらい細分化したモジュールを作成し、
他のモジュールとの結合度(依存度)を低くするのが普通。

40 :デフォルトの名無しさん:2006/05/14(日) 14:49:30
>>36
>機能拡張や修正の仕事が着ても間単に修正できるようにし、 

簡単に修正できるならば、
そもそも機能拡張や修正の仕事が来ないという
ジレンマはどうしましょう?


41 :デフォルトの名無しさん:2006/05/14(日) 14:50:06
>>37
ちょっとVIPPER風味を入れてみただけだぜ?
つまんない揚げ足取りしかできなくなって一杯一杯にみえるぜ?
>>33>>38にちゃんと答えてみ?

42 :デフォルトの名無しさん:2006/05/14(日) 14:52:10
>>38
中心となっている話には賛同できないが
これは同意
俺は何でもかんでもオブジェクト指向やデザインパターンを使わなければならないという人間ではない

確かに読むのめんどくさいんだよなぁ。いや読むというよりソース追う作業に時間かかる
継承がおいとどんどん親のクラスのメソッドに見に行って元のクラスに戻ってくる・・・
で、自分の脳みそのスタックに溜まっているものがあふれてしまう

機能とか役割でクラスわけしている程度が一番いいのかもな

43 :デフォルトの名無しさん:2006/05/14(日) 14:52:46
>>42
そんなあなたにdoxygen+dot

44 :デフォルトの名無しさん:2006/05/14(日) 14:52:46
>>39
「普通」じゃ利益の説明になってないぜ?
それに、個々の動作は結局の所は具体的な処理で行われるもんだ。
やたらなんでも抽象化したって、具体的な動作を読み取るのに、
読むべきファイルが増えるばっかりだぜ?

45 :デフォルトの名無しさん:2006/05/14(日) 14:53:29
>>>>33>>38にちゃんと答えてみ?
おまえはソースだけではなくレスも読めないのか?
掲示板という時間のずれを考慮すれ

46 :デフォルトの名無しさん:2006/05/14(日) 14:54:18
マ板でやれ

47 :デフォルトの名無しさん:2006/05/14(日) 14:55:04
>>44
仕事といえるのか?答えろ

48 :デフォルトの名無しさん:2006/05/14(日) 14:56:29
>>46
うるせーな。俺、今久々に燃えているんだよ

49 :デフォルトの名無しさん:2006/05/14(日) 14:57:36
>>44
普通に利益の話だと思うが?

家とかで言えば、釘やボルト、ネジなどの部品を作る。
これを用いて、局所的な具体的な物を作る。

さて、これが利益にどう繋がるかは一目瞭然だよな。
細分化しておいた部品が、他の仕事でも使えるんだよ。
これが工数削減(だけど見積もり金額を減らす訳ではない)に繋がり利益が生まれる。

もちろん、局所的な具体的なものも行き成り作るのではなく、何段階かの部品を幾つも作り、
それらを組み合わせて作ることによって、この途中段階での部品も使えるように出来れば、
さらに利益が上がる。

50 :デフォルトの名無しさん:2006/05/14(日) 14:58:44
>>44
スレ読んでるかい?
>>22
>納めた後の工数×単価が、開発時の無駄な工数×単価以上に本当に節約されるのか?
の証明を示してくれたら、
保守まで請負った案件の場合に限っては、
会社に忠誠を尽くす仕事とはいえないと認めてやるよ。

51 :アンカ訂正:2006/05/14(日) 14:59:18
>>47
スレ読んでるかい?
>>22
>納めた後の工数×単価が、開発時の無駄な工数×単価以上に本当に節約されるのか?
の証明を示してくれたら、
保守まで請負った案件の場合に限っては、
会社に忠誠を尽くす仕事とはいえないと認めてやるよ。

52 :デフォルトの名無しさん:2006/05/14(日) 15:03:00
>>49
>>1には賛同できないが
俺の携わった仕事では
過去に作成されたクラスが再利用あるいは継承されることはいまだかつて無い。
俺もえらそうなこと言っているが、結局再利用されなければ>>1に対しても強いこといえないなぁ・・・(泣

ちなみに、広く知れ渡っているオープンソースとかは使うけどね。
ここで言っているのは、あくまでも自分の会社や協力会社の作ったソースのこと


53 :デフォルトの名無しさん:2006/05/14(日) 15:04:00
>>保守まで請負った案件の場合に限っては、
いつからそんな狭い話になったんだ?

54 :デフォルトの名無しさん:2006/05/14(日) 15:04:09
>>49
「一目瞭然」とか、今どき部品化とか、君はアホ文系営業並みに論理的な思考能力がないな。
部品化して、釘やボルト、ネジ並みの汎用に使えて、2重開発が防げる場面なんて、
どれだけあるんだい?それでも、それが量的に費用対効果が+であることを証明しなくちゃ。
どこかの部屋の桟のために切り出した木材は、幾ら屁理屈に則っていじくっても、
他の柱に転用は出来ないんだよ。



55 :デフォルトの名無しさん:2006/05/14(日) 15:05:07
>>52
それは、何故、再利用できないかを考えたのか?

結局は、『設計・製造が悪く再利用に向いていないクラス』ってだけじゃ無いのか?
細分化されてなかったりモジュール結合度が強すぎたり、顧客独自の仕様だったりと。

56 :デフォルトの名無しさん:2006/05/14(日) 15:05:33
>>53
保守の費用が削減できるって理屈なんだから、
そういう条件の場合にしか言えないだろ。何を言ってるの?

57 :デフォルトの名無しさん:2006/05/14(日) 15:08:18
>>54
>どこかの部屋の桟のために切り出した木材は、幾ら屁理屈に則っていじくっても、
>他の柱に転用は出来ないんだよ。

そんな事無いんじゃない?
1センチまたは1ミリ角に切り出しておけば、それを幾つも組み合わせればどの柱にもなるよ。
もちろん、実際の家の柱では無理だが、プログラムでは可能だよな。

58 :デフォルトの名無しさん:2006/05/14(日) 15:08:33
>>44
具体的な動作を読み取る必要がないように抽象化してるんじゃないの?
知らんけど

59 :デフォルトの名無しさん:2006/05/14(日) 15:08:37
結局一番効率が良いのは
他のグループに引き継いだりせずに、
一つのシステムを同じグループ内だけで
作成し、保守し続けることなんだよな。

そういう土壌があって初めて
「共通化」とか「関数化」の
恩恵にあづかれる訳で。

60 :デフォルトの名無しさん:2006/05/14(日) 15:09:15
>>55
うーん、まったく再利用してないわけではないんだけどね
前プロジェクトのソースをコピペしたりとかはする←これは再利用のレベルが違うよね

つーかパッケージ名に
プロジェクト名.*
って命名しているので、コピペ以外つかえねぇ〜w

61 :デフォルトの名無しさん:2006/05/14(日) 15:10:01
>>57
>実際の家の柱では無理だが

それが何故無理なのかを
一度じっくり考えてみるのが良いと思う。


62 :デフォルトの名無しさん:2006/05/14(日) 15:12:40
ソースの見た目が汚いのはまだ許せる。
が、アルゴリズムや構造が汚い・遅い・ヘボいのはチーム全体に迷惑がかかるから頂けない。

63 :デフォルトの名無しさん:2006/05/14(日) 15:13:20
>>57
抽象的な空想はイイから、具体的に頼む。
木材に比べたらコードの方が自由はきくが、
それでも現実にはそんな使い回しできる場面はほとんどない。
だいたい、ちゃんと契約してないと他の案件の作成物を他で使うこと自体NGだしな。

64 :デフォルトの名無しさん:2006/05/14(日) 15:14:09
完璧なドキュメント
完璧に書庫化されたライブラリ
なかなかむずかし〜ね〜

プログラムソースは工業製品とはよく言ったものだが
>>1はこの業界の、設計士ちゃんなのだろうか?

65 :デフォルトの名無しさん:2006/05/14(日) 15:15:41
>>58
それは屁理屈の上では半分は正しいが、
デバッグをやった事があれば、そんなきれい事は言えまい。

66 :デフォルトの名無しさん:2006/05/14(日) 15:15:43
>>63
こういう問題はこう解決する、だとか、こういうデータ構造にすればいい、みたいな
いわゆるノウハウの使い回しは日常的にしてるだろ?
汚いソース、理解できないソースを量産されると、それすらも出来なくなるからダメなんだよ。

67 :デフォルトの名無しさん:2006/05/14(日) 15:19:17
>>66
最後の行と、それより上の行が繋がってません。

68 :デフォルトの名無しさん:2006/05/14(日) 15:22:53
キモオタヒョロヒョロ馬鹿学生

69 :デフォルトの名無しさん:2006/05/14(日) 15:24:00
>>55
その細分化のコストが本当に利益に見合うのかって話なんだが。
それに、顧客独自の仕様をどうしろってんだい?

70 :デフォルトの名無しさん:2006/05/14(日) 15:24:15
>>67
俺はわかるよ どこか矛盾しているところでもあるのか?
おまえが経験不足なだけじゃないの?

71 :デフォルトの名無しさん:2006/05/14(日) 15:25:49
>>1
Martin Fowlerさんが書いた「技術的負債」って話を読めば?
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?TechnicalDebt

72 :デフォルトの名無しさん:2006/05/14(日) 15:26:34
>>67
自分で作った物なら、自分でノウハウを持っているからいいけどね。
以前に別のチームが担当した案件のノウハウを拝借する場合なんかは
理解するのに時間がかかると、それだけ効率が低下する。

…まあそれが普通なのも事実なんだが

73 :デフォルトの名無しさん:2006/05/14(日) 15:28:50
>以前に別のチームが担当した案件のノウハウを拝借する場合なんかは
>理解するのに時間がかかると、それだけ効率が低下する

「こんなの解読しているより自分で作ったほうが早いよなぁ」と思うが、まぁ我慢する

74 :デフォルトの名無しさん:2006/05/14(日) 15:30:10
ソース読んで理解できないから担当者に話を聴いてみたら、
何のことはないソースが無駄なことをやっていただけ、なんてのは良くあるな。
そういう時、綺麗なソースを書いて欲しいと痛切に思う。

75 :デフォルトの名無しさん:2006/05/14(日) 15:30:50
キモイおっさん達がうようよと集っているスレはここですね。

76 :デフォルトの名無しさん:2006/05/14(日) 15:31:42
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?TechnicalDebt

77 :デフォルトの名無しさん:2006/05/14(日) 15:32:48
>>70
矛盾してるとは言ってない。矛盾以前に論理的に繋がってないと言っている。
それに、汚い読めないコードを書いている訳じゃない。
むしろ、教義を盲信して、やたらブツギレでやたら処理が分散してやたら抽象的なソースより
よっぽど読みやすい。

>>71
読んだ。メタファの説明をしてるだけで、
それが事実か、修正時の無駄を省くことが本当に払う負債に及ばないか、は書いてないじゃん。

78 :デフォルトの名無しさん:2006/05/14(日) 15:33:51
>>77
> むしろ、教義を盲信して、やたらブツギレでやたら処理が分散してやたら抽象的なソース

それは>>62が言う「構造が汚い」ソースに当たると思うが

79 :デフォルトの名無しさん:2006/05/14(日) 15:34:01
>>74
> 何のことはないソースが無駄なことをやっていただけ
いっとくが、そんなのは俺は肯定してないからな。

80 :デフォルトの名無しさん:2006/05/14(日) 15:35:32
>>78
細分化・抽象化を進めたらそうなるんだが。
だとしたら、能書き垂れる奴が目指すのが「構造が汚い」ソースと言うことだな。

81 :デフォルトの名無しさん:2006/05/14(日) 15:36:42
キモオタヒョロヒョロ馬鹿学生

82 :デフォルトの名無しさん:2006/05/14(日) 15:36:59
何事もほどほどにってことだろ。
フレームワークを作るときにThree Examplesの原則を無視して
片っ端から抽象化したりする奴とかな。

83 :デフォルトの名無しさん:2006/05/14(日) 15:38:59
ほどほどっていうか、多分何も考えずに単純に抽象化してるからだろ。

抽象化するにはするなりの理由があるわけで、その理由がちゃんと説明できて
意味のあるものならいいんだよ。

84 :デフォルトの名無しさん:2006/05/14(日) 15:39:23
>>65
細分化されてればバグの切り分けも楽になると思うけど

85 :デフォルトの名無しさん:2006/05/14(日) 15:39:55
しかしトレースが面倒になる罠

86 :デフォルトの名無しさん:2006/05/14(日) 15:42:50
まあ、保守やテストがしやすいように設計すればいいってこったな

87 :デフォルトの名無しさん:2006/05/14(日) 15:43:27
なんでトレースが面倒になるんだろう・・・

細分化されていれば、その引数と結果だけ見ればいいんだから、
ある意味、どこが原因なのかも、ちょっとしたプログラム書けば一瞬で判別できるのに・・・

細分化して、デバッグやトレースで苦労した経験なんて殆ど無いんだが。

88 :デフォルトの名無しさん:2006/05/14(日) 15:43:38
つまり綺麗に書け、でFA。

89 :デフォルトの名無しさん:2006/05/14(日) 15:44:19
>>84
なんで?経験的には、
細分化されてると、どっちが悪いとも言えず、
(呼び出し先は結局要件を満たしてなかったが、単体と見たらその責務は負うべきでない場合)
構造に手を付けざるを得なくなるような事が
よくある気がする。

90 :デフォルトの名無しさん:2006/05/14(日) 15:45:39
>>89の場合は、大抵、呼び出し側ではその要件を満たすことが出来ない。細分化されてるので。

91 :デフォルトの名無しさん:2006/05/14(日) 15:45:57
キモオタヒョロヒョロ馬鹿学生

92 :デフォルトの名無しさん:2006/05/14(日) 15:46:20
>>89
それこそ『何で?』って感じだろ。

結局、設計が悪いだけの話だろ。

93 :デフォルトの名無しさん:2006/05/14(日) 15:47:25
>>92
日曜プログラマはそれでイイかもしれんがね。
職業プログラマは、起きえるリスクに対してそんな無責任なことは言えないんだよ。

94 :デフォルトの名無しさん:2006/05/14(日) 15:48:16
>>89
>構造に手を付けざるを得なくなるような事が 
>よくある気がする。 

それは切り分けが上手くいった例ではないの?


95 :デフォルトの名無しさん:2006/05/14(日) 15:49:11
え、俺?

96 :デフォルトの名無しさん:2006/05/14(日) 15:49:55
>>93
意味不明だな。

>職業プログラマは、起きえるリスクに対してそんな無責任なことは言えないんだよ。

職業プログラマだからこそ、設計をちゃんとしておけって言っただけなんだが?
それとも、起きえるリスクに対して無責任に設計をするのが職業プログラマとでも?

97 :95:2006/05/14(日) 15:50:42
スマソ。誤爆した。

98 :デフォルトの名無しさん:2006/05/14(日) 15:51:55
妥協をするのは納期に詰まってからでいいんだよ!

99 :デフォルトの名無しさん:2006/05/14(日) 15:53:12
>設計をちゃんとしておけって言っただけなんだが?
おまえが絶対ミスを犯さない完全無欠の天才ならそう言っていればいいよ。

設計に問題がある、とテスト段階で解った時に、
「設計がちゃんとしてれば」なんて言っても始まらんのだよ。
しかも細分化・抽象化することで、そういうリスクが増えると。


100 :デフォルトの名無しさん:2006/05/14(日) 15:54:57
>>94
>>89の事態のなにが利益なの?

101 :デフォルトの名無しさん:2006/05/14(日) 15:55:24
>>99
何でテスト段階なんだろう・・・
多分、製造段階で分かるのに・・・

102 :デフォルトの名無しさん:2006/05/14(日) 15:55:42
>>99はウォーターフォール型開発しかできないお方ですか?

103 :デフォルトの名無しさん:2006/05/14(日) 15:56:04
細分化を抑えた設計で、後から設計のミスが分かった場合には
それこそ細分化して直さなきゃいけなくなるぞ。
クラスの責務の一部にだけミスがあったりしたら((;゚Д゚)ガクガクブルブル

104 :デフォルトの名無しさん:2006/05/14(日) 15:57:33
>>103
それが日常化してる、なんちゃってPG/SEにはその感覚が分からんのですよ。

105 :デフォルトの名無しさん:2006/05/14(日) 15:59:48
>>101
おまえのとこはテスト段階でNGがでないのか。
それはテスト技術に問題があるのではないか?


106 :デフォルトの名無しさん:2006/05/14(日) 16:07:08
>>103
馬鹿みたいに細分化してない事で、あとでの設計ミス発見による痛手が、
馬鹿みたいに細分化しる場合より大きくなるというのは、どういう場合だい?
責務が細分化されて見事に一カ所に問題が局所化されていたら、それは設計の問題じゃないのではないか。
むしろ、設計の問題は、細分化の仕方がおかしいという類のモノだろう。
それは、細分化すればするほどリスクが高くなる。

107 :デフォルトの名無しさん:2006/05/14(日) 16:08:34
リスクが高くなるから「じゃあやりません」で済む話ではないけどね

108 :デフォルトの名無しさん:2006/05/14(日) 16:56:49
じゃあどんな話?

109 :デフォルトの名無しさん:2006/05/14(日) 17:01:36
分割しないと共同開発できないのでは

110 :109:2006/05/14(日) 17:11:10
どうやらすべったようだ

111 :デフォルトの名無しさん:2006/05/14(日) 17:34:36
元勤めていた会社のコーディングルールに文句ある人。
ttp://web.kyoto-inet.or.jp/people/ysskondo/c/c.html
読みにくいソース実例集、というか「Cプログラミング診断室」(著:藤原博文 出版:技術評論社 絶版)
ttp://www.pro.or.jp/~fuji/mybooks/cdiag/index.html

112 :デフォルトの名無しさん:2006/05/14(日) 18:09:05
動けばいいコードって、使い捨てのサンプルコードのこと?

そんなにたくさんあるのかなぁ。


113 :1:2006/05/14(日) 18:37:39
ウダウダ能書き垂れる奴がいっぱい釣れたwww

114 :デフォルトの名無しさん:2006/05/14(日) 18:41:31
だろ?皆暇人なのよな!

115 :デフォルトの名無しさん:2006/05/14(日) 18:45:41
たまの休みなんだから、何も考えずにバカな書き込みさせてくれ

116 :デフォルトの名無しさん:2006/05/14(日) 23:05:48
コードなんてその時だけ動けばいいんじゃない?
将来のOS・ハードウェア・世情の変遷を考慮にいれた設計ができるだろうか?
仮に完璧に設計できないとしたら、時代・世代・思想・人種を超えた
完璧なコーディングなんてあるだろうか?
もし、EXCELなどのような完成度の高く、機能が多いものを統合しなくてはならないのなら
そこから得られる利益を考慮してある程度の記述法が必要だとは思われるが、
いったいどのような開発を想定しているのだろう?
プロジェクトを管理する側からすると駄目なら作り直すし、
作り直しにコストがかかりそうなものは分割して作成する。
コードの中身にいちいちこだわってられない。
また、こだわらなくてもいいようにコーディングルールおよび環境をととのえる。


117 :デフォルトの名無しさん:2006/05/14(日) 23:20:37
動けばいいじゃん
と言っていいのはスキルが高いやつだけ

動けばいいじゃん言ってる奴のプログラムに限って
ちゃんと動いてないし、保守するのはたいてい他人

118 :デフォルトの名無しさん:2006/05/15(月) 00:08:49
「動いたからいいじゃん」とか言っておいて自分の開発PCでしか
動かないプログラムを書いちゃうズボラも多々いれば、
動作対象外の古いOSやどうなるかわからない未来のOSに対応
させようと無駄なコードをせっせこ書いちゃう自己満足もいるわけよ。

もうテスト通ったor稼働しちゃったプログラムをいじっちゃう奴は
余計なお世話かつ危険だと思うが、実はそのプログラムは遅かったり
もっと適したライブラリやOSの機能があるのに使っていなかったり
実は廃止予定のAPIを使っていたりと改善の余地があったのに、
「動いたから」という実績を強調して、次回も同じ「ちゃんと動く」
プログラムを書いてしまう、という潜在的に危険な奴もいるわな。

負の数を与えるとバグる関数を書いたとして、そいつのプログラム内では
負の数を与えない保証があるので「ちゃんと動く」わけだが、
「ちゃんと動く」ことを理由にコメントで制限事項を書いておかないと、
知らずに誰かがコピペしたとき危険だよな。
これはそもそも「ちゃんと動く」うちに入れるのかどうか、コメントを
書いたらいいのか、負の数への対処コードを最初から書けばいいのか、
どこまで書いたら「ちゃんと動く」ことになるのか。


119 :デフォルトの名無しさん:2006/05/15(月) 00:21:53
>>118
DigitalMarsC++にあるDesign by contract機能に、その関数の作成者の連絡先を含められるといいな。
負の数与えて実行時例外が出たら、「犯人はコイツだ!」って表示してくれるとか(´Д`)

120 :デフォルトの名無しさん:2006/05/15(月) 02:00:22
動けば良いじゃんと同じ発想を客の側から考えると安けりゃ良いじゃんって事になるんだよ
これが解らん奴は早い所マの仕事からは足を洗え
存在自体が迷惑だ


121 :デフォルトの名無しさん:2006/05/15(月) 02:04:50
客がそう思ってるなら、なおさら余計な無駄なコストは省かなきゃやってられないだろ。馬鹿か?

122 :デフォルトの名無しさん:2006/05/15(月) 02:42:20
>>121
で、韓国使え、中国使え、インド使えになったんだぞ


123 :デフォルトの名無しさん:2006/05/15(月) 04:38:34
>>1はともすれば5分考えて始動し、丸一日でコーディングするタイプ
1時間思案してから始動して、3時間で完成させる代わりに

124 :デフォルトの名無しさん:2006/05/15(月) 08:54:54
>>122
で、客のニーズの逆を行くわけか。おめでたいね。

125 :デフォルトの名無しさん:2006/05/15(月) 11:11:17
実際コストは減っているのかと言えば、国内の開発会社の単価が下がっただけで工数ベースだとむしろ増えてるな
メンテナンスコストは更に増えていて、当初の開発コストを上回る修正費用が必要だったりしてメンテナンス案件はお蔵入りとかとか結構ある


126 :デフォルトの名無しさん:2006/05/15(月) 11:11:32
>>121
コストと開発期間と品質はそれぞれトレードオフなのよ。
コストを下げると品質は下がるし、開発期間を縮めるならコストを上げるか品質を下げるかどっちかを選ばなきゃならんし
"安くしろ。でも品質は下げるな、開発期間も延ばすな"。"1年かかるプロジェクトを3ヶ月で達成しろ。でも金はこれだけしか出さんし品質も
完全に保障汁"。・・・・客のニーズの究極はただで今すぐ最高品質の思い通りなシステムが出てくるだからな。
一々付き合ってたらきりが無い。
まあ、実現不可能な客のニーズと余裕を持って取り組みたいプロジェクトマネージャ(ただ、大体の日本会社はこの交渉を無知な営業にやらせる)
の交渉いかんによって妥協点が違って来るんだが、もしプロジェクトマネージャ(営業)がとちるとデスマーチが発生すると言う(((( ;゚Д゚)))ガクガクブルブル

さらに、大概作った後も保守や改良をしなければいけない状況も多々あるからいい加減に作ると後が大変・゚・(´Д⊂ヽ・゚・

127 :デフォルトの名無しさん:2006/05/15(月) 13:02:37
>>118
そりゃコピペするほうが悪い。
いずれにせよ、コピペするような奴には品質期待できないけど。

128 :デフォルトの名無しさん:2006/05/15(月) 16:57:27
1はばかだあ

129 :デフォルトの名無しさん:2006/05/15(月) 17:06:05

中国共産党に嫌がらせをしようじゃないか!

おまいの力が必要だ!

本 日 22 時 開 始 !!!!!

ヒマだから中国共産党にいやがらせでもしようぜ。
http://ex14.2ch.net/test/read.cgi/news4vip/1147672392/

中国共産党は「天安門事件」に触れられることを非常にいやがっています。
「百度」(中国版2ちゃんねる)に天安門事件の動画リンクを貼って、 おちょくるのが目的です。

130 :デフォルトの名無しさん:2006/05/15(月) 17:29:26
そんなことしてる暇があったら仕事しろ

131 :デフォルトの名無しさん:2006/05/15(月) 23:44:30
中国はピンキリだが、ハズレを引かなきゃ日本と変わらん。つか英語が出来るだけ上かも。
インドはヤバイ。日本で言えば旧帝院卒レベルが当たり前の世界。英語は言うに及ばず。
根拠無く中国・インドを馬鹿にしてる奴は馬鹿。


132 :デフォルトの名無しさん:2006/05/16(火) 09:36:02
>>131
たしかに根拠無く馬鹿にしている奴は馬鹿だが、外国に外注出すのはいろいろと問題があるんだよ。
品質管理や工程管理・納期問題、文化の違いによる軋轢(期限守るって考えが無い国・地域が多い_| ̄|○)、意思決定の
遅延(必要な時にコミュニケーションがとれん)etc・・・

上手く付き合えばそれなりの効果はあるんだが、根拠無くマンセーしてる奴も馬鹿といっておく。

133 :デフォルトの名無しさん:2006/05/16(火) 22:36:04
>>132
ハズレを引いたのか空想で語ってるのか知らんが、中国はハズレを引かなきゃ、と書いただろ。
うちの発注先は、やや遅れ気味だったが納期前にテストのために、
女の子も含めて2徹してあげてきた。もちろん品質も問題なかった。

134 :デフォルトの名無しさん:2006/05/17(水) 00:48:47
>もちろん品質も問題なかった

2徹でそれは優秀だな。当たり外れの確立を知りたいところだ。

135 :デフォルトの名無しさん:2006/05/17(水) 01:01:07
>テストのために、女の子も含めて2徹
  ^^^^^^^^^^^^^^^^
ここ重要。
日本でもちんけなところはこんなことせずに「できました」とテスト削って出してくる。
単に日本というだけで他国より優秀と勘違いしてる底辺会社・PGは、現実見た方が良いよ。


136 :デフォルトの名無しさん:2006/05/17(水) 01:21:31
骨抜きにされて遊びほうけて育った日本人より中国人のほうが優秀だよ。
そのうち絶対逆転不可能になった時に連中は豹変するよ。
所詮それまで下手に出ているだけ。それが分からんで中国人と友達になった気で居る
日本人のあまちゃんなことよ。
遊んで捨てられる女同然の浅はかさ。


137 :デフォルトの名無しさん:2006/05/17(水) 10:43:32
>そのうち絶対逆転不可能になった時に連中は豹変するよ
>所詮それまで下手に出ているだけ。
その腹黒さが嫌なんだよ。誰もがそうだとは限らんが、
末永く付き合いたいかというと二の足踏む。

138 :デフォルトの名無しさん:2006/05/17(水) 13:41:58
別に腹黒いのは中国人だけに限った話じゃないさ。
腹黒い連中と付き合うのがいやなら、PGなんて今すぐ辞めた方がいいぞ。

139 :デフォルトの名無しさん:2006/05/17(水) 14:55:46
というか社会人を辞める必要があるな。

140 :デフォルトの名無しさん:2006/05/17(水) 16:53:16
みんな不幸な世界に住んでるんだな。

141 :デフォルトの名無しさん:2006/05/17(水) 18:43:58
なんか、1のいうことはすごくわかる。
客のためにコード書いたりレビューするんじゃなくて、単に自分はこんなこと知ってますよというのをひけらかしたいだけのやつ。
ピストルもったら何でもいいから撃ってみたくなるのとおんなじ。
あるいは人の話にわりこんですぐウンチクたれたがるやつとかとおなじ。
「ここは○○パターンが使えますねー」とか。別にその箇所は拡張予定もないのに。
そのパターン導入して設計上の問題が解決されるならいいけど、別にそこは問題となってないし、わざわざややこしい設計にする必要ないの。
全体のレベルが低いんだから、なるべく分かりやすい設計にするのがいちばんいいんだよ。

でもな、それはレベルが高い人がいうなら説得力あるけど、ないやつがいっても戯言なんだよ。
「学歴なんか関係ない」という台詞を、東大生がいえば説得力あるけど、ただの高卒が言ったところでだれも聞いてくれるわけがない。
1がレベルの高い技術者ならいってることはきっと正しい。
けど三流であればただのひがみ。負け犬の遠吠え。


142 :デフォルトの名無しさん:2006/05/17(水) 21:32:04
>>135
日本が決定的に優れてるのは、客のために奉仕する精神だと思うね。
これは中国に限らず他の国にない利点。
サービス残業までやってるところは日本以外ではめったにないよ。

143 :デフォルトの名無しさん:2006/05/17(水) 23:25:46
綺麗なソース、正しい構造の客観的評価基準が無い限り、
幾ら職業根性を掲げてもオナニーでしか無いわなぁ。

自慰の自覚があればいいけど、他人に自分の思想を押し付ける技術者て...。



144 :デフォルトの名無しさん:2006/05/17(水) 23:30:30
チーム内の8割が読んで理解できるソースだろ

145 :デフォルトの名無しさん:2006/05/17(水) 23:36:40
そういうソースを書ける奴は2割もいないな。

146 :デフォルトの名無しさん:2006/05/17(水) 23:39:47
客には動けばいいと思っているの?
勝手にこっちが思ってるだけなんじゃないか?


147 :デフォルトの名無しさん:2006/05/18(木) 00:06:44
動けばいいじゃんと言っているやつがぐちゃぐちゃなソースを書く
程度ならまだいいが、そういうやつはたいていエラーや例外処理
が抜けまくったたまに以上停止するプログラムを量産し、しかも
ぐちゃぐちゃなのでデバッグに異常に時間が掛かり、売り物に
ならない。


148 :デフォルトの名無しさん:2006/05/18(木) 00:15:43
>>142
それは洗脳に成功した結果に思えてならない。洗脳でなければ幻想を
植えつけることか。「社会人とは〜というものだ」という、実は日本でしか
通用しない幻想というのが山ほどあって、その中には経営者側に都合の
いいものが沢山紛れ込んでいる。そして大多数の雇われている側の人は
騙されてしまうと。それによって社会全体が成り立っている面もあるので
それが100%悪いとは思わないが、嘘が多ければ多いほど、当然現実との
距離は大きくなる。そしてある日、あると信じていたものが、実は最初から
何もなかったことに気づくと。


149 :デフォルトの名無しさん:2006/05/18(木) 00:22:05
>>141
いや、逆に東大生が言ってもかっこつけてるだけだとしか
思えないよ・・・

150 :デフォルトの名無しさん:2006/05/18(木) 00:24:48
東大卒業のフリーターが言えばそれなりに説得力はある。

151 :デフォルトの名無しさん:2006/05/18(木) 11:02:21
>>25
こいつ頭わるいな

152 :デフォルトの名無しさん:2006/05/18(木) 19:46:13
>>151
「頭悪いからって言っていじめちゃいけないよ」ってこの間、
先生教えたでしょ

153 :デフォルトの名無しさん:2006/05/18(木) 21:30:27
>>143
そうそう。

それに、職業根性を熱く語るような奴自体には、職業根性がないことが多いという経験則もあるし。

きちんと動くものを作れれば十分だと思う。


154 :デフォルトの名無しさん:2006/05/22(月) 15:26:59
>>146
逆だろ。客はバグ無く動けばそれでいい。
設計厨やOO厨、デザパタ厨とかが、屁理屈付けて、
バグ無く動くプログラムに文句を付けて無駄なことをする。

155 :デフォルトの名無しさん:2006/05/22(月) 15:55:32
「客は動けばいいと思ってる」ってのはダメPGの願望だろ。
客の品質に対する無知につけこんで、低品質のものを売りつけてるだけ。



156 :デフォルトの名無しさん:2006/05/22(月) 16:05:49
「バグ無く」って書いてんだろうが。
客が「どうでもいいところに無理矢理デザパタ適用されたプログラム」を望んでると思ってるの?

157 :デフォルトの名無しさん:2006/05/22(月) 18:00:52
バグがなくても重かったり操作が使い難いのは多い
直せといっても仕様だからと押し切られる
デザパタ使おうがどうしようが客は構わないけど
仕様のあいまいな部分をプログラマの都合で詰められるのはカンベンしてくれとは思う

158 :デフォルトの名無しさん:2006/05/22(月) 21:53:52
このスレにリファクタリングという概念は無いわけですね

まぁ客が認めなければ無いも同じだけど

159 :デフォルトの名無しさん:2006/05/23(火) 00:02:56
提案時にスパイラルモデルで提案しておくとウマー

160 :デフォルトの名無しさん:2006/05/23(火) 11:57:41
>>159
スパイラルよりもウォータフォールでリリース2回に分割する方が楽

161 :デフォルトの名無しさん:2006/05/23(火) 13:05:53
>>156
品質=バグの有無
としか認識してないのか。やれやれだぜ…

162 :デフォルトの名無しさん:2006/05/23(火) 13:16:01
普通の客ならば、
「TCO が低く、ちゃんと動作していれば、
どんなに汚いソースでもかまいません」
だと思う。
それ以上望むことなど何もない筈。

勿論、それを実現するために
綺麗なコードを書くのは、
構築する側の自由だろう。


163 :デフォルトの名無しさん:2006/05/23(火) 13:56:24
>>162
TCOが低くと自分でも言ってるじゃん
作り捨てでその後のメンテを考えないならOKだよ

164 :デフォルトの名無しさん:2006/05/23(火) 15:33:38
>>162
今時そんな客ばっかじゃねーだろ。
結構うるさい所は多いぞ。


165 :デフォルトの名無しさん:2006/05/23(火) 20:10:20
働けばいいじゃん。グダグダ言い訳垂れてるニートって何なの?

166 :デフォルトの名無しさん:2006/05/23(火) 21:09:49
>>160
それだと2回しか請求出来ないじゃん?

167 :デフォルトの名無しさん:2006/05/23(火) 22:18:30
スレたい見てわろたwwwwwwwww
ストレスためてるなみんなwwwwwwwwwwwwwwwwww

168 :デフォルトの名無しさん:2006/05/23(火) 23:03:31
     / ̄ ̄ ̄ ̄ヽ
   /  / ̄\  ヽ
  /   /     ヽ、、、ヽ
  |  /   ー   ー | |   チャッチャッチャラッチャ〜♪
  |  |    ・   ・ | |
  |  |   ●  ー ●| |   ストレス〜が♪
  ゝ‐イ\       /ノ   チャッチャラッチャ〜♪
      γ< ヽ / >'´
     / ,イ.三串三)     地球を駄目にす〜る♪
    //  )__ノ,ヽ_(     チャッチャラッチャ〜♪
  とcフ   ノ/^^/^^\
       /~/~ノ~~ i..~ ヽ
     ,.ノ ノ〜/〜i〜j ヘ
        /`/ー|
      / / | |
     <_ィ ヽ、 } |
       ヽ,__ノ (  ヽ_
          Llヽ、__)

169 :デフォルトの名無しさん:2006/05/24(水) 01:01:30
動けばいいじゃん。






…それが正しく動いてるかは別として。

170 :デフォルトの名無しさん:2006/05/24(水) 01:02:20
いや、正しく動かなきゃダメだろ。

171 :デフォルトの名無しさん:2006/05/24(水) 01:14:53
>>1の「ちゃんと動くプログラム」は、実はテストと出戻りを何回も
繰り返したあとのやつで、コストにも品質にも個人的職能にもマイナス
なのに、それをふまえて誰かが「次は最初からこういう
書き方を・・・」とか忠告したことに>>1が逆ギレしているところ。



172 :デフォルトの名無しさん:2006/05/24(水) 05:25:29
営業や経理担当の立場からみると

「正しく動く」ことよりも
「とりあえず動いているように見える」ことが優先される

つまりさっさと納品してさっさと開発費回収しろということ

実際には将来に禍根を残しているとは思われていない

しかしそういう糞アプリが氾濫することで技術の進歩とか
全体としては停滞していると思うんだけどなぁ

大半は動いてる部分だけみて「こんなもんか」と思って
問題指摘すらしないというか問題があることすら気づかない

修正提案してもなんでそんなことにお金や時間かけるの?


173 :デフォルトの名無しさん:2006/05/24(水) 05:59:45
ROI

174 :デフォルトの名無しさん:2006/05/24(水) 14:35:48
保守業務を想定しる
汚いコード書くと保守・拡張・修正時に莫大なコストがかかるぞ
納品して終わりってんなら別だけどな

175 :デフォルトの名無しさん:2006/05/24(水) 16:29:20
近いうちにSOX法対策や、不正使用電磁記録作成罪なんかの対策で動けばOKは許されなくなる

176 :デフォルトの名無しさん:2006/05/24(水) 17:51:28
程度の問題だろ。
時間を掛ければそれだけ保守性が向上するってわけでもなし。

177 :デフォルトの名無しさん:2006/05/24(水) 18:04:27
マジレスすると
カレー味のうんこに似てるな。
どんな食材使おうが結局その味さえ再現出来ればいいっていう発想が。

同じ動作をするプログラムがあったとすると
いつバグが起きるかわからないようなグチャグチャなソースより
綺麗に見やすく書かれてるソースのほうが客にとっては安心だろ。
次の発注にも繋がる。

178 :デフォルトの名無しさん:2006/05/24(水) 18:12:05
ちゃんと動くと美しく動くの違い、屁理屈とまっとうな理屈の違いについて。

179 :デフォルトの名無しさん:2006/05/24(水) 18:16:51
綺麗なプログラムはバグも少ないよ

180 :デフォルトの名無しさん:2006/05/24(水) 18:18:02
自分の場合は
「動くプログラム」

「正しいプログラム」
という具合に呼び分けてる


181 :デフォルトの名無しさん:2006/05/24(水) 18:27:25
つーか>>1は完成したのを眺めて「なんだこれ?」って思わないの?
思わないならプログラム向いてない。パンチャーでもやってろ。

182 :デフォルトの名無しさん:2006/05/24(水) 18:56:59
>>143
重要なのは綺麗なソースってよりわかりやすいソースでしょ。

最近うちに入ってきた将来有望な自称PG経験者(独学) の例を書こう。

// 10回ループする場合
int i = 0;
while(1){
  〜いろいろ処理〜
  if(i++ >= 9)
  break;
}

// 条件に合う件数を数える場合
for(int i = j = 0; i < 10; i++)
if(s[i] == OK)
if(b[i] == NG)
j++


コメントも一切なし。誰がメンテするんだよ。
お前は仕事よりプログラムコンテスト目指したほうがいいんじゃないかと。

183 :デフォルトの名無しさん:2006/05/24(水) 19:07:09
>>177
それでちゃんと納期に間に合って黒字になれば文句はない。

184 :デフォルトの名無しさん:2006/05/24(水) 19:09:07
>>183
「その後」は?

185 :デフォルトの名無しさん:2006/05/24(水) 19:10:04
どうせ客はソースなんて見ない。

186 :184:2006/05/24(水) 19:13:06
納得。

187 :デフォルトの名無しさん:2006/05/24(水) 20:57:36
>>183
保守はどうするの?もしも運用してる時にテスト時に見逃した(汚いコード書くと可能性アップ)
致命的バグが顕在したら直さなきゃならないんだが

188 :デフォルトの名無しさん:2006/05/24(水) 21:15:23
>>1を見ていればソフト開発で
できるやつとできないやつで生産性に100倍差があることが良くわかる
1と1の擁護者が試行錯誤でボロボロのソフト書いて動いたと喜んでるよこで
デキルヤツはその100の速さで組んでるんだろう

189 :デフォルトの名無しさん:2006/05/24(水) 21:35:48
日曜PGのオレの職場では、
新しく導入した事務ソフトの、
伝票印字位置を直してくれと、
営業マンが来た時に頼んだのに、
プログラムその場で開いても分からなかったらしく、
「自分では治せないから〜」と、言ったきり、全然直しに来やがらない。

プロの条件はディスマーチに耐える体力だけだという神話は本当らしい。

190 :Enterキー:2006/05/24(水) 22:07:03
>>189
へー、そういうものなんですね。
プログラムを理解するということはとても難しんですね。

191 :デフォルトの名無しさん:2006/05/24(水) 22:15:32
>>182
すげー、その下のやつそれで動くのか
無駄な事覚えちまったよ糞野郎

192 :デフォルトの名無しさん:2006/05/24(水) 22:16:52
とりあえず>>1には絶対俺の開発チームに入ってこないで欲しい。

193 :デフォルトの名無しさん:2006/05/24(水) 22:25:29
>>182
お前、新人なめんなよ
分からなくて当たり前だろ
市ね

194 :デフォルトの名無しさん:2006/05/24(水) 23:12:55
>動けばイイじゃん。ウダウダ能書き垂れる奴って何なの?

とか言う奴に限ってまともに動かんもん上げてくる罠

195 :デフォルトの名無しさん:2006/05/25(木) 10:37:10
>>193
わからないならわからないでいいんだよ。
そんな感じのソースを書いて>>1みたいな態度でいるからだよ。

196 :デフォルトの名無しさん:2006/05/25(木) 10:43:19
>動けばイイじゃん。ウダウダ能書き垂れる奴って何なの?
とか言う奴は,他人(過去の自分を含む)が書いたソースの保守をしたことがないんだろ

197 :デフォルトの名無しさん:2006/05/25(木) 10:55:34
多分まだ保守っていう意味すらわかってないんだと思う

198 :デフォルトの名無しさん:2006/05/25(木) 13:44:54
>>182
カッコなしでネストされると追いかけづらいよな。

199 :デフォルトの名無しさん:2006/05/25(木) 16:36:21
>>1は間違ってない。プログラムなんか動けばいいんだよ。
どんなに汚いソースでもコンパイラのマイナーバージョンが上がると動かなくなっても関係ない。
完全に仕様どおりに動いて後からの仕様変更にも楽々対処できてバグがあっても即座に発見&修正できて保守が楽なら何の問題もないよ。

200 :デフォルトの名無しさん:2006/05/25(木) 17:17:52
小規模なシステムしか書いたことないひとはよくそうおっしゃいます

201 :デフォルトの名無しさん:2006/05/25(木) 19:08:59
>>199 同意。後半部分がちゃんとできてるなら何の問題もないんだよな。

202 :デフォルトの名無しさん:2006/05/25(木) 19:14:55
汚いソースは後半部分がちゃんとできてないことが多い

203 :デフォルトの名無しさん:2006/05/25(木) 19:19:20
安定制や修正しやすさ、能率を考えて、
きっちりプログラムが動けばいいって考えが綺麗なプログラム
だと思うけどな。

204 :デフォルトの名無しさん:2006/05/26(金) 10:33:32
デスマーチの真っ最中だと>>1の台詞が出る
しかし、それは異常な状態だからこそ出る台詞であって通常このような考えはするべきではない

205 :デフォルトの名無しさん:2006/05/26(金) 12:29:58
動かないのはもっと良くない

206 :デフォルトの名無しさん:2006/05/26(金) 12:40:01
>>199
>コンパイラのマイナーバージョンが上がると動かなくなっても
それは
>保守が楽
と言えるかどうか、微妙な線ではないかと。

207 :デフォルトの名無しさん:2006/05/26(金) 13:20:59
>>199
それなら確かに問題はないと思う。
だが>>1は保守のことまで考えているとは思えないという方向で
話が進んでると思う。
どんなにソースが見づらくても
納期の時にさえちゃんと動いてれば問題はないっていう

208 :デフォルトの名無しさん:2006/05/26(金) 15:32:10
うちには主に2人の上司がいる。
俺はあまり定石過ぎる書き方は好きじゃないから
たまにイレギュラーな設計したりするんだけど(もちろんメンテ出来る範囲で)、
1人の上司はその設計のいいところ悪いところを指摘してくれる。
もう1人の上司は「実績がないからダメ」って言う。
当の本人がプログラムを書くと本当に枯れた技術のコードしか書かないけど
やはり他の上層部からも無難な評価を受けるようだ。
結局、誰でも書けるような何のヒネリもないロジックのほうが評判はいいらしい。
それはわかるけどなんかつまんないな。

209 :デフォルトの名無しさん:2006/05/26(金) 15:54:50
要するに仕事で作ってるか趣味で作ってるかの違いでしょう


210 :デフォルトの名無しさん:2006/05/26(金) 16:11:32
>>209
なるほど。
仕事に面白さを求めちゃいけないわけなのか。

211 :デフォルトの名無しさん:2006/05/26(金) 17:24:50
そういう意味じゃないでしょう

212 :デフォルトの名無しさん:2006/05/26(金) 17:45:43
いや、悪意ある受け取り方じゃないぞ。
斬新なことやりたいなら趣味でやれってことで納得した。

213 :デフォルトの名無しさん:2006/05/26(金) 18:12:51
仕事で作るなら他人に迷惑掛けないように作れ

趣味なら自分のやりたいようにやれ

214 :デフォルトの名無しさん:2006/05/26(金) 18:17:24
まとめよう

1)面白いか/面白くないかとか
たぶん両立不可能


2)斬新か/やっつけ仕事か
たぶん両立不可能


3)自分のやりたいようにやるか/迷惑かけないようにする
たぶん両立可能


さらに
1)と2)たぶん相関関係があるので両立不可能
2)と3)斬新なものを他人に迷惑かけないように作ることは可能
1)と3)面白いものを他人に迷惑かけないように作ることは可能


215 :デフォルトの名無しさん:2006/05/26(金) 18:33:55
>>214
>1)と3)面白いものを他人に迷惑かけないように作ることは可能

は出来そうだが、

>2)と3)斬新なものを他人に迷惑かけないように作ることは可能

は堅物がいる限り不可能。
見たことないロジックだと無条件で嫌がられると思う。


216 :デフォルトの名無しさん:2006/05/26(金) 20:30:44
>誰でも書けるような何のヒネリもないロジックのほうが評判はいいらしい。
そんなのは当たり前。
1:枯れた技術のほうがバグも含めた不具合のパターンが分かっている
2:他の人も知っているパターンだと製作者≠保守担当者の場合でも保守しやすい。

結局、大抵の仕事は複数の人間が関わるうえ、仕事の担当者が変わって引継ぎされることもあるので、
誰が見ても分かるというのは必要な条件。

もう一人の上司がダメだというのは当然だと思います >208

217 :デフォルトの名無しさん:2006/05/26(金) 21:51:50
限度があるけどな
10万件を超えるレコードをバブルソートする奴とか
スタックに8Mとる奴とか
ネタじゃなくて時々いるからな

218 :デフォルトの名無しさん:2006/05/27(土) 06:03:57
>>203
テンプレ化出来るのは全部テンプレ化した方が能率上がるよ
確実に

後々多少の弊害があったり無かったり・・・

219 :デフォルトの名無しさん:2006/05/27(土) 14:49:06
まあ、プロジェクトの規約自体が無茶っていうのもあるからなぁ・・・。
どうしてもらちがあかないと見切ったら、俺も「動けばいいじゃん」モードに
入るよ。
それが自分の無知が原因だった場合は恥ずかしいけど、自分の決断の
結果だからね。

どこに行っても嫌われるコーディング

1.定数のハードコーディング
 「ダサい」とはっきり言ってあげよう。
 新人のうちの最初が肝心。

2.コメントがない
 doxygenでドキュメントを提出するようにさせる。
 コード内にコメントを入れさせるより、ヘッダコメントですべて説明させる

3.無責任なコピペが多い
 関数単位以外でのコピペを禁じる。
 つまり、コピペするぐらい汎用的な処理なら関数化させる。

4.変数名が手抜き
 基本的に、手抜きな変数名でもスコープが狭ければ文句はあまり出ない。

5.グローバル変数を多用する
 すまきにしてたたき出す。

6、ループ処理が不可解
 「ダサい」とはっきり言ってあげよう。
 まあ、新人の場合、理解に時間のかかるものでもあるので、
 内部の処理がなるべく小さくなるようメソッド分けを薦める。

220 :デフォルトの名無しさん:2006/05/27(土) 15:47:50
まあ、最初の躾が重要なんだよな
独学で覚えましたって奴は使えないことは無いけど変な癖がついてる奴が多すぎる

221 :デフォルトの名無しさん:2006/05/27(土) 16:06:12
はっきり言える事、組織の中に入って職業PGになるのは辞めておこう
シェアウェア作家にでもなっておいた方がいいよ

222 :デフォルトの名無しさん:2006/05/27(土) 16:27:59
>>1
てーか、保守性うんぬんおいとくとしても、
そんな自分の成長に繋がらないようなことばかっかやってて
つまんなくない?

223 :デフォルトの名無しさん:2006/05/27(土) 16:39:34
仕事は、開発者の自己満ではなく、客の要望を満たすことだ。
自分の成長とは、自己満度が上がることではなく、
客の要望をより確実により早く実現できるようになることだ。

224 :デフォルトの名無しさん:2006/05/27(土) 16:42:22
>>223
うん、だからそんな考えで仕事しててつまんなくね?

あと、動けばいいじゃん、で作ってて
どうやったら
> 客の要望をより確実により早く実現
できるようになるの?


225 :デフォルトの名無しさん:2006/05/27(土) 16:49:28
>>223
自己満に終始してる人多くない?


口を動かす前に頭を動かせよと

226 :デフォルトの名無しさん:2006/05/27(土) 16:51:00
なんで?納品してユーザに評判がいいと聞けば、単純に嬉しいが。
「動けばイイ」という言い回しは釣りで、正確には
「動くことが目的であって、特定のやり方・作法というのは手段に過ぎない」と言うことだ。

本末転倒の無駄なことやってれば、本来の目的が曖昧に遅くなるのは当たり前じゃん。

227 :デフォルトの名無しさん:2006/05/27(土) 16:51:36
>>226>>224へのレス。

228 :デフォルトの名無しさん:2006/05/27(土) 17:00:29
>>226
自分の場合、
「動けばイイ」思想でコーディングした前任者のせいで
今の要求を満たせずに悔しい思いをすることの方が多いな…

> 本末転倒の無駄なこと
かどうかは誰がいつ判断してるの?


229 :デフォルトの名無しさん:2006/05/27(土) 17:06:36
それが判断できないから自己満足だとか無駄だとしか思えないんだろ

230 :デフォルトの名無しさん:2006/05/27(土) 17:13:31
>>229
自己満足といっているのは
「動けばイイ」に対して?
それともその逆に対して?

「7つの習慣」という本を読んでたら、少しこのスレのネタになりそうな話があった。
P/PCバランスというやつ。
http://www.google.co.jp/search?q=p%2Fpc%E3%83%90%E3%83%A9%E3%83%B3%E3%82%B9
このスレ的にはこんな感じだろうか。

P(目標達成):
納期を守って顧客に納品すること

PC(目標達成能力またはそれを可能にする資源):
再利用性や再利用可能なソース


231 :デフォルトの名無しさん:2006/05/27(土) 17:21:46
動けばいいんだが
動かないからな

232 :デフォルトの名無しさん:2006/05/27(土) 17:25:57
再利用なんてのは、なんとなく重要な気がするけど、実際のところは幻想でしかない。
本当に汎用に使える部分なんて、そんなにあるもんじゃない。
本当に再利用可能な部品として作るとの、その案件の要件を満たすのとでは、
掛かる工数が5倍くらい違う。5倍掛けてもどうせそれっきり。

233 :デフォルトの名無しさん:2006/05/27(土) 17:30:18
>>1
多分、
ttp://japanese.joelonsoftware.com/Articles/GettingThingsDoneWhenYour.html
に書いてある戦略4をとられてるんだと思うよ。

ソフトウェア再利用の神話
ttp://blogs.dion.ne.jp/cmap21/archives/3348799.html
にもある通り、本当に再利用性の高い物を作るにはレベルの高い能力が必要だから。


234 :デフォルトの名無しさん:2006/05/27(土) 17:32:59
本当に汎用の部品なら、Jakarta Commonsとか使った方が早いな。
でも、さらに、再利用のためのコーディングの自体すら、ただのこだわりっつーか目的化して、
ひたすら守るけど、結局出来るモノは再利用出来る形にすらなってなかったりする。

235 :デフォルトの名無しさん:2006/05/27(土) 18:16:42
他の案件で部品として使うだけが再利用ではない。
機能追加、仕様変更が素直に出来ることも、
広い意味で既存コードの再利用だ。

236 :デフォルトの名無しさん:2006/05/27(土) 18:57:01
顧客打ち合せで、
一応解ってるSEが「その変更なら、○○するだけだから」と受けてきて、
たしかに○○するだけで済むハズなのに、実際やってみたら動かない件。

237 :デフォルトの名無しさん:2006/05/28(日) 00:54:45
>>219
俺も以前は全部当てはまってた。
現場でずっとしごかれてるうちに無意識にそれらをやらなくなってきたなぁ。
コード内のコメントってウザイの?

238 :デフォルトの名無しさん:2006/05/28(日) 01:51:24
関数内のコメントは、
ブロックが何やってるかの説明なら、適切な名前の関数に切り出すべきだし、
切り出すほどでなければ、変数名を頼りに何やってるかコード読むだけで自明であるべき。
書く必要があるのは、特別に何か注意点があるときだけ。

239 :デフォルトの名無しさん:2006/05/28(日) 12:46:46
プロジェクトによっては
修正履歴を入れたりとか(バージョン管理ツール使ってれば要らないけど)
OSのバグ等の回避策としてハックしている場所に注意書きしておくとか
既知のバグ(あとで修正する必要あり)を書いておくとか
効率優先の処理にしたため可読性が低い部分に書いておくとか

240 :デフォルトの名無しさん:2006/05/28(日) 15:03:18
>修正履歴を入れたりとか(バージョン管理ツール使ってれば要らないけど)
→不要。早く石器時代から脱出してください。

>OSのバグ等の回避策としてハックしている場所に注意書きしておくとか
→特別な注意点だな。

>既知のバグ(あとで修正する必要あり)を書いておくとか
→ソースはチラシの裏じゃねー。ローカルコピーならいいけどチェックインはするなよ。

>効率優先の処理にしたため可読性が低い部分に書いておくとか
→特別な注意点だな

241 :デフォルトの名無しさん:2006/05/28(日) 16:39:36
変数名・関数名って、かなり問題だよ。

ちゃんとした名前を付けても、専卒は英語が分からないから、
ちゃんとした名前も一文字変数と変らない。

英語が分からなきゃ、当然「ちゃんと付けろ」といっても付けられないし、
ちゃんとした名前も本人には無意味なので、ちゃんと付ける動機も生まれない

おまえらどう?

242 :デフォルトの名無しさん:2006/05/28(日) 16:49:15
アメリカからの帰国子女だから英語で普通に会話も出来るよ

243 :デフォルトの名無しさん:2006/05/28(日) 17:00:40
苦労して言われた通りにちゃんとした名前付けても、
何が良くなったのか全然実感がないんじゃ、被害者意識しか生まれないな。

244 :デフォルトの名無しさん:2006/05/28(日) 17:04:51
Oh! eigo OK arune

245 :デフォルトの名無しさん:2006/05/28(日) 17:05:59
>>242
たまーに外資の会社に訪問すると、社員が英語で会話しているよな。
俺は中学英語で単語とボディランゲージで乗り切るけどな。
そういう会社はインド人いっぱい。なかなか楽しい。

話し戻して、普通はプロジェクトごとに命名規約として辞書なんか作らない?
疑問に思ったところや、名前付けに苦しんでいる箇所をストックしておいて
定期ミーティングで10分ぐらい割いて決めているけど。
たいていベテランの鶴の一声で決まるんだけどな。

246 :デフォルトの名無しさん:2006/05/28(日) 17:58:32
>>245
グローバルスコープの名前だったらそれでもOKだろうけど、
ソース中の名前ってその数倍以上の量があるだろ。それは?

247 :デフォルトの名無しさん:2006/05/28(日) 20:58:35
>>246
確かに難しいな。自分の会社だと、基本的にローカルスコープの変数は
英数小文字+アンダーバー+ハイフンなら何でも良い事になっているな。
むしろコメントの方が大事。

逆にメソッドの命名はかなり厳しくて、辞書に無い単語は使えない。
新しい名前が必要な場合は、申請しなければいけない規則になっている。
まあ、基本的にコーディングする時にはメソッド名は全て決まっているので
問題は無いんだけど。


248 :デフォルトの名無しさん:2006/05/29(月) 02:20:39
>>241
15年くらい前のハードウェアのコードとか日本語で変数名付けていたから、いま
中国とかインドで流用して廉価版のハードウェアに移植しているんで、日本語
変数名で苦労しているよ。

7年前くらいに日本語が使える中国人のソフト会社にメンテしてもらった時は、
コメントが日本語で付けられてるんだけど、日本語としても変だったし、困るねえ。

今はもう英語でコメント入れようと努めてる。
というか、自分ではメンテせずにお任せ、って感じだけどね。

249 :デフォルトの名無しさん:2006/05/29(月) 10:50:27
変数にハイフンを使える言語ってなんだろう?

250 :デフォルトの名無しさん:2006/05/29(月) 10:53:17
lispじゃね?

251 :デフォルトの名無しさん:2006/05/29(月) 13:11:42
>>248
逆にその英語コメントが間違ってない確証はあるのか?

>>249
javaも出来る。
int _ = 0;

252 :デフォルトの名無しさん:2006/05/29(月) 13:13:45
それハイフンか?

253 :デフォルトの名無しさん:2006/05/29(月) 13:23:10
_がハイフンだったら、アンダーバーのほうはどの記号だろう?


254 :デフォルトの名無しさん:2006/05/29(月) 13:30:17
>>252
すまん、アンダーバーとハイフン勘違いした。

255 :デフォルトの名無しさん:2006/05/29(月) 14:13:30
ありえない

256 :デフォルトの名無しさん:2006/05/29(月) 14:21:44
英語コメントうざー

257 :デフォルトの名無しさん:2006/05/29(月) 21:50:28
>>249
COBOL もできるんじゃなかったっけ?

258 :デフォルトの名無しさん:2006/05/30(火) 00:11:32
変数に + を使える言語ってなんだろう?

259 :デフォルトの名無しさん:2006/05/30(火) 00:15:00
lispじゃね?

260 :デフォルトの名無しさん:2006/05/30(火) 00:15:25
変数に@とか入れたいんだけど

261 :デフォルトの名無しさん:2006/05/30(火) 00:24:09
ruby
perl

262 :デフォルトの名無しさん:2006/05/30(火) 00:25:11
>>260
lisp

263 :デフォルトの名無しさん:2006/05/30(火) 00:28:01 ?#
>>257
ハイフンは使えるけど、アンダーバーが使えない。

264 :デフォルトの名無しさん:2006/05/30(火) 00:38:24
変数にωやμを使えれば楽しいな

265 :デフォルトの名無しさん:2006/05/30(火) 00:58:05
VB

266 :デフォルトの名無しさん:2006/05/30(火) 02:26:54
普通にシフトJIS通すコンパイラあるじゃん。

267 :デフォルトの名無しさん:2006/05/30(火) 02:34:29
アラビア語を変数には出来まい

268 :デフォルトの名無しさん:2006/05/30(火) 06:08:26
>>266
日本語でコーディングが実現できるな。

269 :デフォルトの名無しさん:2006/05/30(火) 08:33:25
JavaとかC#とか普通に出来るだろ。
日本語でもアラビア語でも。

270 :デフォルトの名無しさん:2006/05/30(火) 09:09:10
よめ

かけ

とまれ

271 :デフォルトの名無しさん:2006/05/30(火) 18:10:23
VC++2005はUnicode通るからかなり奇抜な識別子が使えるな。

272 :デフォルトの名無しさん:2006/05/30(火) 21:08:43
古代ギリシャ文字とか使えたら最高

273 :デフォルトの名無しさん:2006/05/31(水) 01:27:25
日本語で変数名や関数名もいいけど、半角全角、ひらがなカタカナ漢字混じりってタイプミスの落しい穴が増えるだけだと思うけどね。

274 :デフォルトの名無しさん:2006/05/31(水) 13:04:52
名前なんて自動補完に決ってるだろ。

275 :デフォルトの名無しさん:2006/05/31(水) 13:23:41
俺のviだと自動補完してくれないんだけど?

276 :デフォルトの名無しさん:2006/05/31(水) 22:18:06
>>273
渡邉クラスと渡邊クラスを間違えちゃったりするんだよね!

277 :デフォルトの名無しさん:2006/06/01(木) 16:34:42
動けばイイじゃだめなんだ

278 :デフォルトの名無しさん:2006/06/01(木) 23:12:13
>>273
そうだね、「落としい穴」なんて書く奴には難しいんだろうね。

279 :デフォルトの名無しさん:2006/06/02(金) 00:40:48
動かないのより動くのがいい
動かせ動かせ
文句を言わずに動かせ動かせ

280 :デフォルトの名無しさん:2006/06/03(土) 15:41:27
age

281 :デフォルトの名無しさん:2006/06/04(日) 17:56:40
ネットワークプログラミングで、送受信のタイミングを合わせるのに、

Sleep(8000);

とかやっていて、それで >>1 みたいな事を言われたとしたら、非常に困るね。

282 :デフォルトの名無しさん:2006/06/04(日) 19:22:09
busy-loopじゃ無いんだからいいんじゃないの?
タイミングを合わせる必要性というのがいまいちわからないけど。

283 :デフォルトの名無しさん:2006/06/04(日) 21:22:16
普通なにかの同期機構を使うけどな

たまにあるよ
無意味に長くスリープしててパフォーマンスが悪いプログラムが

どうしても使わざるを得ない事もあるんだろうけど

284 :デフォルトの名無しさん:2006/06/04(日) 22:49:21
>>1は勢いだけで行動する典型的な高卒か?

285 :デフォルトの名無しさん:2006/06/04(日) 22:50:02
>>1みたいなのが姉歯ビルを設計するんだよな

286 :デフォルトの名無しさん:2006/06/04(日) 22:50:48
>>1
世昭和生まれの高卒は死ね

287 :281:2006/06/05(月) 09:37:00
>>282-283
要するに、データを送信してから受信するまでのタイムラグを、
Sleep で調節するというダメコードのことです。
普通、非同期通信を使うよね、って話です。
わかりにくくてすみません。

288 :デフォルトの名無しさん:2006/06/05(月) 09:38:25
>>287
他のプロセスに迷惑かけなきゃいいんでないの?

289 :281:2006/06/05(月) 09:53:16
>>288
送受信の時間間隔が一定とは限らないので、

送信 → Sleep(8000); → 受信

とした場合、あるタイミングでは8秒では足りなくて、
受信とその後の処理に失敗してしまうことがあるわけです。
じゃあ10秒にしようって、それは違うだろ、って話です。

290 :デフォルトの名無しさん:2006/06/05(月) 09:54:51
>>289
受信データ無けりゃループでしょ。

291 :281:2006/06/05(月) 10:06:36
>>290
↓こういうやつですか?

送信処理;

while(!dataAvailable) Sleep(0);

受信処理;

う〜ん、もし上記のようなことならば、非同期処理のほうがいいかなと思います。
待ち時間が非常に長い場合、ほかの処理も並行してやりたいですからね。

292 :デフォルトの名無しさん:2006/06/05(月) 10:43:03
>>291
応答までのディレイがどのくらいか分ってるなら、先にその分Sleepしておいて、あとは精度をどれだけ取るかによってループ中のSleepの時間を設ければ良いじゃん。

Sleep(600);
while(!dataAvailable) Sleep(200);

とかさ。
ってか、こんな形よく見かけるし。

293 :デフォルトの名無しさん:2006/06/05(月) 11:02:39
ポーリングしたって良いじゃんw

294 :デフォルトの名無しさん:2006/06/05(月) 11:15:04
>>292
どうもありがとうございます。よくわかりました。

ところで質問ですが、ほかの処理を並行してやる場合は、

送信

Sleep(一般的な遅延時間);
while(!dataAvailable) Sleep(細かい間隔);

受信

という処理を別のスレッドで動かせばいいんでしょうか?


> ってか、こんな形よく見かけるし。

それは知らなかったです。

295 :281:2006/06/05(月) 11:25:45
>>294 は 281 です。

296 :デフォルトの名無しさん:2006/06/05(月) 13:38:05
送信処理;

while(!dataAvailable) Sleep(1);

受信処理;


やってみれば分かると思うけど
これでもそんなにパフォーマンス落ちないよ

297 :281:2006/06/05(月) 13:57:58
>>292 >>293 >>296 さん、ありがとうございます。
とりあえずやってみます。

あと、>>293 さんのおすすめのポーリングもよさそうですね。
http://msdn2.microsoft.com/ja-jp/library/ms228968.aspx
を読んでいると、なんとかできそうです。

298 :デフォルトの名無しさん:2006/06/05(月) 16:21:11
わざわざ別スレッドに分離するなら非同期処理使っても同じことだと思うが…?

299 :281:2006/06/05(月) 16:49:19
>>298
今は別スレッドで分離しない方向でやろうと思っています。
ポーリングか、あるいは ManualResetEvent あたりを使って。

300 :デフォルトの名無しさん:2006/06/05(月) 17:17:32
おいおい、そのwhileで回すのがポーリングじゃねえのか?

301 :281:2006/06/05(月) 18:05:37
>>300
まちがえました。ポーリングってこんなやつですね。

Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.IPv4);
socket.Connect(addresses[0], port);

if (!socket.Connected) throw new Exception("Connect is failed!!");

while (true)
{
if (socket.Poll(0, SelectMode.SelectWrite))
{
string message = "Hello!!";
byte[] bmessage = Encoding.UTF8.GetBytes(message);
socket.Send(bmessage);
}

}

while で回すよりは、非同期のほうがわかりやすいかなと思いました。

ManualResetEvent を使うほうは、ドキュメントのコードがほぼそのまま使えそうですし。

ポーリングは、参考になるのは以下のページぐらいのようですね。
ttp://www.csharpfriends.com/Articles/getArticle.aspx?articleID=80

302 :デフォルトの名無しさん:2006/06/05(月) 22:47:46
>>1
アナル厨

303 :デフォルトの名無しさん:2006/08/19(土) 03:43:15
>>279
動いてしまったばっかりに、俺も顧客も後始末で大損害さ。


304 :デフォルトの名無しさん:2006/09/07(木) 13:25:28
>>1はまさに高卒や中卒や専門卒の考えそのもの。
浅はかでソフトウェア工学も何も知らないし

>>1は『アジャイルソフトウェア開発の奥義』
を読んでから発言して欲しいものだよ

305 :デフォルトの名無しさん:2006/09/07(木) 22:21:23
goto >>1

306 :デフォルトの名無しさん:2006/10/22(日) 01:29:55
>>1
どっちも正しい。

@ありきたりな正論だけど、プログラムは直す為に書く。
 別にお前さんが悪くなくても、お国の決まりは毎年変わる。
 消費税だって変わるし、ある日「こんな税金できます」って発表される。絶対だ。
 直すの前提で書いたほうがいい。主に設計そのもののミスなんだがなw

A逆にコボラーとか揚がっちゃったロートルに多いのが、
 自分じゃ1行も書かない(実は書けない)くせに、
 「管理してくれてやる」って現場に首突っ込んでくるクズは実在する。
 基本的に設計もできないからヒマこいてるし、口出しするのが仕事だと勘違いしてる節がある。
 コーティング規約とか独自なのセッセと作ったりな。
 いや、Gnuのコーティング規約で書いてますから?世界標準ですが何か?とかあしらえばOK。
 あとは「奴は役立たずな上、現場の邪魔しかしません。だから外してください」と素直に上長に報告せよ。

307 :デフォルトの名無しさん:2006/11/05(日) 17:28:38
丸付き文字をつかう奴が何を言おうが負け犬の遠吠えにしか聞こえない

308 :デフォルトの名無しさん:2006/11/05(日) 18:54:17
今さらアジャイルwwwwwwww

309 :デフォルトの名無しさん:2006/11/06(月) 00:30:53
>>307
まぁ修正を前提とした考え方の人なので、そうなんでしょう。

そのうえ"Gnu"って…しかも全角?

310 :デフォルトの名無しさん:2006/11/09(木) 20:17:11
>>1
はアホである。

311 :デフォルトの名無しさん:2006/11/10(金) 04:04:27
名前はまだない。

312 :デフォルトの名無しさん:2006/11/12(日) 20:51:19
どこで生れたかとんと見当がつかぬ。

313 :デフォルトの名無しさん:2006/11/14(火) 12:41:01
おれも最初は、真面目にopen-close-principalとか、よい作りを考えるようにしてたよ。

だが、これは、はっきりいって馬鹿だった。これは、問題を根本的に取り違えてる。

「よい作り」というのは、「自分のソフト」の場合限定の問題に対する解法。

請負で開発して納品という商売では、これは解にならないどころか、
コストの浪費&期待収入機会の損失でしかない。

顧客は、「安く早く」作る事しか頭にない。「安く早く」作るところが良い発注先。
作りやコードがどれだけウンコだろうが、そんな事は全く関係ない。

作りに拘り、コードを磨き抜いても、顧客はそんな事はどうでもイイ。
逆に、無駄な時間と工数を使ってる分、これはマイナス。

さらに、良い作り・良いコードは、システム拡張案件を自ら縮小している。
昔、ちょっとした拡張ならもろもろ含めて1人月でおつりが来るなどの「よい作り」をしていたが、
結局「単価高けぇよw」の一言で、バンバン切られた。

連中は、同じような拡張でも5人月掛かる糞な作り、糞なコードをさっさと納品する所に乗り換えていった。
そして、乗り換え先は、「1人月」の拡張案件を5人月で請けて、さらに儲ける。

作り・コードを良くするなんて無駄な事を止めれば、
より早く納品でき、底辺PG使って単価を抑えられる。
これこそが顧客が求めているモノで、案件を得やすく、さらに拡張案件でまた儲ける事が出来る。

自己満足は、趣味の世界でやるべき。

314 :デフォルトの名無しさん:2006/11/14(火) 12:45:45
土方にエレガンスを期待してもね
高踏遊民を指くわえて見てなさい

315 :デフォルトの名無しさん:2006/11/14(火) 13:44:59
まだやってたのかこのスレ
>>1ももういないんだし放っておけよ

316 :デフォルトの名無しさん:2006/11/14(火) 20:41:51
なんだかんだ言って>>313が現実。
顧客が中身を判らんし判ろうともしない以上、安さがすべて。
これが資本主義。

317 :デフォルトの名無しさん:2006/11/14(火) 21:03:02
間違ったときに手直ししさえ易ければ、あとは好きなように描けばいいんです。
好きなように描き続ければそれが自分の描き方になり
いつも同じ調子で描けるようになります。

偉い画家が言ってました。

318 :デフォルトの名無しさん:2006/11/14(火) 21:03:58
日本語でおk

319 :デフォルトの名無しさん:2006/11/14(火) 21:13:17
>>313 は良いつくりをすると工数がかかるって前提だが、ヘボいところは
倍の人月で、質の悪いシステムを作り上げたりする。


320 :デフォルトの名無しさん:2006/11/14(火) 21:14:41
いらないコメントをやたら入れたがる上司。

321 :デフォルトの名無しさん:2006/11/14(火) 21:22:26
仕事だと馬鹿相手だから馬鹿にならねえと続かんってこったろ。
馬鹿になれねえならオープンソースで趣味ってろって話だね。






ただ>>1は真性。

322 :デフォルトの名無しさん:2006/11/14(火) 21:26:02
仕事でも馬鹿にならない、
それが俺

323 :デフォルトの名無しさん:2006/11/14(火) 21:32:59
>>319
判ってないな。出来上がったものの質が悪くたって関係ないよ。
実際にその人月で作ったんなら、立派な「○人月のシステム」。
顧客は、同じ○人月がいくらで済んだか、しか判らない。=単価が全て。

324 :デフォルトの名無しさん:2006/11/14(火) 21:33:15
>313
そういう馬鹿が氾濫してるおかげでバグは減らない、クソ重い、ヘタレ仕様のソフトが大量に出回るわけだ。
せめてミッションクリティカルな用途のソフトではこういうのは止めてほしいんだが。

ちゃんとやってるところは単価こそ高いがバグも少なく拡張性も高くて軽い、使いやすいソフトを作ってくれる。それも意外に短納期で。
(デキるプロだから品質向上と工期短縮の両立が出来る方法は知っているだろうし、日夜鍛錬だってしてるだろう。)
問題は発注元がソフトウェアの品質というものを理解して金と時間をかける所がどれほどあるか、そしてそういった良い仕事をする会社を
知っている、もしくは見つけられるか、ということだったりする。

325 :デフォルトの名無しさん:2006/11/14(火) 21:34:58
まあ実際開発始まったら○人月なんて工数もらえないわけで

いいとこ○人日

326 :デフォルトの名無しさん:2006/11/14(火) 21:37:46
>>324
あんた学生だろ。
そんな一握りの例外を挙げても解決にならんよ。

327 :デフォルトの名無しさん:2006/11/14(火) 21:42:35
>>324
笑いを提供してくれるイイ人だなぁ

328 :デフォルトの名無しさん:2006/11/14(火) 21:47:16
>>324
就職活動大変だろうけど頑張ってくださいね^^;

ウチの会社1000万の受注してもPG3人で過去のコードのコピペ作業をして出荷してる
バグはあっても運用時にその処理通らない(←根本的な設計間違い)から無問題

329 :デフォルトの名無しさん:2006/11/14(火) 22:03:59
>>325 ... >>328
それが現実だよな。
使う方はホントあほだよ。
ビッグカメラで、価値も判らんくせに特価の商品前にして
「高けー高けー」うるせえババアと栗卒。

テメエで作れカス。

330 :デフォルトの名無しさん:2006/11/14(火) 22:31:30
まともに作るべきなのは自社パッケージとか自社システム。
請負の仕事なんて、
とにかく何でも良いからとりあえず動くの作って、ほい、が正しい。
Linusだって言ってるだろ?Keep it simple, stupid! 「動く」以上の余計なこと考えるな。

331 :デフォルトの名無しさん:2006/11/14(火) 22:37:18
>>330
ワロタ

332 :デフォルトの名無しさん:2006/11/14(火) 22:41:49
>>330
ところで、

"Keep it simple, stupid"

を、どう翻訳すれば、

"「動く」以上の余計なこと考えるな"

となるのかを教えてもらいたいのだが。


333 :デフォルトの名無しさん:2006/11/14(火) 22:43:16
>>332
そんなんじゃ、戸田奈津子にはなれないぜ?

334 :デフォルトの名無しさん:2006/11/14(火) 22:43:22
自社パッケージだってまともに作られてないな。
今の職場。

DBからデータを読み込んで配列に追加していく処理とか、
配列の上限チェックしてるコードのなんてめったに見ないし。


335 :デフォルトの名無しさん:2006/11/14(火) 22:51:27
それは可変長な配列の話?
固定長ならチェックしないなんてあり得ないと思うのだが。

336 :デフォルトの名無しさん:2006/11/14(火) 23:30:20
>>335
固定長。

修整履歴で、配列のサイズを倍にしてるのを見たことあるから、バグッたこともあるんだろうね。
配列のサイズは倍にしてるのに、そこでも上限チェックはいれてなかったし。

fopen()して、成功してるかどうか見てないところもちょくちょくあるよ。

337 :デフォルトの名無しさん:2006/11/14(火) 23:56:58
ソースレビューがなく、新人教育が適当なところはそんなもんなのかな?

338 :デフォルトの名無しさん:2006/11/15(水) 00:00:15
教育再生

339 :デフォルトの名無しさん:2006/11/15(水) 01:16:23
俺の配列は次長課長

340 :デフォルトの名無しさん:2006/11/15(水) 12:37:24
動けばいい、と言うヤツはプログラマの適正がない

341 :デフォルトの名無しさん:2006/11/15(水) 15:28:57
>>330
最近はそれで良いって思える様になって来た
そんなの奉行シリーズでもかえよ馬鹿w
とか客に言ってみたくなる時もある。

342 :デフォルトの名無しさん:2006/11/15(水) 15:44:23
>>341
真理

343 :デフォルトの名無しさん:2006/11/15(水) 17:59:25
>>313=>>330=>>1

おまえら>>1と同レベルの底辺w

344 :デフォルトの名無しさん:2006/11/15(水) 21:16:15
>>337
ソースレビューないね。
二回ほどしたこともあったけど、malloc()は使用禁止とか、fprintf()の次の行にはかならず
fflush()を入れるようにとか、そんな指摘ばっかり。

345 :デフォルトの名無しさん:2006/11/15(水) 21:17:20
>>344
形骸化してるなぁ・・・でもそんなんばっかり><

346 :デフォルトの名無しさん:2006/11/16(木) 22:29:17
私はいかに美しいソースがかけるか、ということに
面白みを見出しているので擦れたいには同意しかねるな。
醍醐味の8割を捨てるようなもの。だ。


347 :デフォルトの名無しさん:2006/11/16(木) 22:43:50
C++やP2P技術に卓越したプログラマの方々
宜しければ一度で良いので拝見して頂きたいです
当企画の成立には貴方の力が必要です

次世代コミュニティ製作 C++,mod_perl,P2Pが使えるコーダ、グラフィッカ募集中
http://pc8.2ch.net/test/read.cgi/tech/1163349367/

348 :デフォルトの名無しさん:2006/11/16(木) 22:57:44
>>346
徹夜になるとそんな余裕もなくなるが
徹夜が続くとそんな気分になるね

349 :デフォルトの名無しさん:2006/11/16(木) 23:19:39
>>348
お前は俺か

350 :デフォルトの名無しさん:2006/11/17(金) 01:31:27
>>346
つまり、「趣味」ってこった。
仕事のパフォーマンスを、個人の趣味で落す奴はプロとは言えねぇな。

351 :デフォルトの名無しさん:2006/11/17(金) 04:09:37
結局動くものをより短時間で作れるやつが一番偉い
特に誰にもまね出来ない物を作れるやつが最強

352 :デフォルトの名無しさん:2006/11/17(金) 06:40:53
>>351
ずっとプロジェクトに残っているならそれでもいいが

353 :デフォルトの名無しさん:2006/11/17(金) 08:56:37
>>350
バレなければダイジョブ
バグと一緒で

354 :デフォルトの名無しさん:2006/11/17(金) 09:17:36
たとえば
char* buf = malloc( HOGE_SIZE );
memset( buf, 0, sizeof(buf) );
とか書かれると、やだな、って思う訳です。
sizeof(buf)って!

いや、先頭の要素さえ0になってれば、まあ、
文字列バッファの初期化としては問題ないんだけど、
でも...ねえ。
だったら
buf[0] = '\0';
って書きゃいいじゃん?って。

355 :デフォルトの名無しさん:2006/11/17(金) 10:07:09
HOGE_SIZE が sizeof(buf) 未満だとアクセス違反じゃん

356 :デフォルトの名無しさん:2006/11/17(金) 12:35:42
なかなか1未満の整数ってないよな

357 :デフォルトの名無しさん:2006/11/17(金) 12:42:43
自分なら
char buf[ HOGE_SIZE ];
buf[0] = 0;
ですが

358 :デフォルトの名無しさん:2006/11/17(金) 12:52:02
>>354
同意

359 :デフォルトの名無しさん:2006/11/17(金) 13:00:30
>356
sizeof(buf[0])だと1かもしれんけどsizeof(buf)はもうちょっと大きいと思う

360 :デフォルトの名無しさん:2006/11/17(金) 13:27:22
俺の予感では4くらいはありそうだ

361 :デフォルトの名無しさん:2006/11/17(金) 13:40:38
おまえらレベル低すぎ。>>1が言ってるのは、
もっと処理をエレガントにするとか、抽象度を上げて再利用性を上げるとか、
そういうのは無駄って事だろ。バグはそれ以前の問題。

362 :デフォルトの名無しさん:2006/11/17(金) 15:29:23
自分がめんどくさくないのがベスト。

長期的に見て今苦労した方がいいと思えばするし、
今だけ動けばいいやって状況もあるから、その時々
でやることが変わる場合もあるけどね。

363 :デフォルトの名無しさん:2006/11/17(金) 18:40:54
再利用性って再利用したこともないくせにwwwwwwwwwwwwwwwwwww

364 :デフォルトの名無しさん:2006/11/17(金) 18:49:51
むしろしまくりでんがな

365 :デフォルトの名無しさん:2006/11/17(金) 18:52:26
コードを一から作ったりしないで
さっさと再利用して、エロサイト見て理性を保ってますが何か?

366 :デフォルトの名無しさん:2006/11/17(金) 19:13:31
俺なら
char buf[HOGE_SIZE]="";

367 :デフォルトの名無しさん:2006/11/17(金) 19:23:53
>>361

> もっと処理をエレガントにする

綺麗なコードを書ける人のほうが信頼できる。
理由も無いのに汚いコードを書いて開き直る人に複雑なものをやらせると、大抵まともに動かない。

>抽象度を上げて再利用性を上げる

これが自己満足に終わることが多いのには同意。
具体的な再利用の当てがないと、いざ再利用する段階で使えないことが多い。
よっぽど経験と実力がある人だと違うけど。


368 :デフォルトの名無しさん:2006/11/17(金) 19:34:31
>具体的な再利用の当てがないと、いざ再利用する段階で使えないことが多い。
これは真理だな。
完全な工数の無駄遣いに終わる。

369 :デフォルトの名無しさん:2006/11/17(金) 22:12:49
自分の書いた全てのコードが全てのプロジェクトで
全て再利用されているぞマジで。

370 :デフォルトの名無しさん:2006/11/17(金) 22:33:37
有史以来世界中の全てのプログラムで再利用されたら認めてやろう。

371 :デフォルトの名無しさん:2006/11/18(土) 02:06:54
キレイに書くと、書くのが遅くなるって言うヤツは、そもそもキレイなコードがかけてないんじゃないか?



372 :デフォルトの名無しさん:2006/11/18(土) 02:21:14
>>350
違うだろ。
きれいなコード=その後の工数が減る

自分の中ではそんな感じ。
逆に動けばいい、的なコードってどんなのかわからない。
>>351
みたいなやつと一緒に仕事すると大変そうだから絶対嫌。
俺たちはプロ。
自分だけが一生そのソースを面倒みれるわけじゃない。
メンテする人間が複数になる場合もあるのだから、可読性のよいソースを書くことが楽しみの一つ。

>抽象度を上げて再利用性を上げる
利用度の度合もあるよな。
あと継承の多様は可読性が悪くなるから×。
2,3階層まではいいが、それ以上のだと見通しが悪すぎてまずい。



373 :デフォルトの名無しさん:2006/11/18(土) 03:09:30
>メンテする人間が複数になる場合もあるのだから、
「場合もある」?
請負ならデフォだが。そして、そもそも請負前提の話なんだが。

>可読性のよいソースを書くことが楽しみの一つ。
結局趣味じゃねーかw

374 :デフォルトの名無しさん:2006/11/18(土) 05:37:33
可読性を上げているつもりで余計複雑にしてるのならいっぱい見る
例えばクラス階層が2重3重になってたり
関数を細かくわけすぎてこれまた2重3重のネストされてたり
やたらとファイルを分割しててファイル数だけは異様に多いのに中身は数行とかね
意味わかんねwwwwwwwwwww

375 :デフォルトの名無しさん:2006/11/18(土) 05:44:02
オブジェクト指向ってわざわざメンテナンスを困難にする思想のようにしか思えないなwwwww

376 :デフォルトの名無しさん:2006/11/18(土) 07:42:40
>>374
カプセル化ってそういうもんじゃねえ?
大体、そんな奥まで覗かないと流れ読めないの?
読めないなら設計が悪いかもね。

377 :デフォルトの名無しさん:2006/11/18(土) 08:40:55
タイトルだけ見てカキコ
ほんとーにそー思ってるならこんなとこでウダウダ能書き垂れる必要ないんじゃね?

378 :デフォルトの名無しさん:2006/11/18(土) 08:45:27
>>374
動けばいいじゃん

379 :デフォルトの名無しさん:2006/11/18(土) 10:02:54
>>376
あと、変数名や関数名に制約があって可読性が無いのかも知れないぞ。
まるで逆コンパイルしたソースみたいに。

"f_3260()"と書かれても何したいのかさっぱりわからん。
こんなのが羅列されるソースを読むと、何かが違うといつも思う。

380 :デフォルトの名無しさん:2006/11/18(土) 11:47:21
ユーティリティーっぽいのは慎重に作って
ツールっぽいのは好きなように作る

エロ動画DLするスクリプトはソースにすらせずコンソール直打ち
for i in `seq 1 1 9` ; do wget http~/$i.mpg ; done
とか。

381 :デフォルトの名無しさん:2006/11/18(土) 12:11:56
>>379
名前に愛着がないソースってすぐグレるよね

382 :塩水 ◆1FrMT.vzQQ :2006/11/18(土) 12:17:13
現場の話は良く分からないけど、科学技術計算では汎用性の高いスクリプト作っておくと後ですごい楽。
例えば波動関数求める計算でパラメーターを色々変えて計算する作業の自動化スクリプトを書くとする。
一次元の場合と二次元の場合で個別にスクリプトを作っても良いけど、その工程で共通するような部分を
汎用的にサブルーチンぽく作っておけば、一次元と二次元で同じような作業の部分を重複しているような部分は
再利用できる。引数を1で与えれば一次元、2で与えれば2次元、みたいな感じ。

ただ、その汎用化の作業は自動化しようとしている工程を完璧に把握している必要があるよね。
見た感じ同じような工程で自動化できそうな部分でも、与えるパラメータの数が変わってたりとか微妙に違うことがある。
あと上の例で、もし一次元と二次元の計算工程が「まるっきり」同じなら、作業を自動化するまでも無く、
パラメータの「1」をエディタで直に「2」って書いて実行した方が速い。
ただ、俺は一次元と二次元のログデータが同じディレクトリに混在するのを避けたいから一次元と二次元で
スクリプトを分けてるって意味合いが強い。

闇雲に抽象化したって使わなければあんまり意味無いし、だからって動くものだけ作ってればいいやってのも
効率が悪いことがある。やりたいこと、目的がはっきりしていない段階ではどんなプログラムが良いかなんて
判断できないと思う。

現場を知らないって断ったのは、マ板を見てると目的がはっきりわかってプログラムしている人の方がまれなように見えるから。
プログラマどころか注文した顧客ですら目的がわからないってパターンがほとんどのように見える。
だから、結局はその職場のスタンダードに素直に従ってプログラミングしておくのが
結果として一番効率的なプログラミングになるんじゃないかなって2ch見てて思った。

383 :デフォルトの名無しさん:2006/11/18(土) 12:50:12
>>382
ええ話やなぁ

384 :デフォルトの名無しさん:2006/11/18(土) 14:18:40
> 塩水
まで読んだ。

385 :デフォルトの名無しさん:2006/11/18(土) 14:36:42
>>382
おまえは旧帝レベル以上だろう。現場は分数の足し算すら怪しい奴が半分近い。

386 :デフォルトの名無しさん:2006/11/18(土) 14:43:00
個々のプログラマは所詮メソッド
メソッドが勝手にインスタンス化を判断するなんて、それは欠陥のある言語でしかないのだよ

387 :デフォルトの名無しさん:2006/11/18(土) 14:47:39
>>385
お前、職場変えたほうがいいよ。

388 :デフォルトの名無しさん:2006/11/18(土) 15:04:51
>>380
つ curl

389 :デフォルトの名無しさん:2006/11/18(土) 15:14:19
動けばいいじゃんというやつにかぎって本番では動かないのは仕様ですか。

390 :デフォルトの名無しさん:2006/11/18(土) 17:02:23
>>385
1/2 + 1/3 = 1/5
というのでも見たのか?!

391 :デフォルトの名無しさん:2006/11/18(土) 18:31:31
その通り顧客が仕様をわかってないというのが大前提だね
だからxstreamなんてものが流行ったりする
どんだけ丁寧に書いていっても結局細部にまで後々変更が入る
それなら最初から動けばいいじゃんってのを作っとくのが最強


392 :デフォルトの名無しさん:2006/11/18(土) 21:29:18
>>390
残念ながら、
1/2 + 1/3 = 2/5
なら見たことある…

393 :デフォルトの名無しさん:2006/11/18(土) 22:16:03
ありえね

394 :デフォルトの名無しさん:2006/11/19(日) 00:15:56
うそ! 違うの?

395 :デフォルトの名無しさん:2006/11/19(日) 10:44:26
ベクトルならおk

396 :デフォルトの名無しさん:2006/11/19(日) 20:09:02
>>373
>>374
なんかお話にならない、という感じだな。
やってる仕事の内容もレベルも低いということがすぐにわかった。

多分君のやってる仕事のレベルじゃない大きさになると
君みたいなやり方の人間がいたら一瞬でつまはじき。

井の中蛙というか、レベルが低いというか。

397 :デフォルトの名無しさん:2006/11/19(日) 20:16:27
>>382
妹が失禁しながら気を失った・・・

まで読んだ。

398 :デフォルトの名無しさん:2006/11/19(日) 20:27:05
>>382
ワッフル、ワッフル!

399 :デフォルトの名無しさん:2006/11/20(月) 01:31:55
>>396
井の中の蛙はお前だろw
100人月程度のシステムなら、それなりのPGで固めて恵まれた開発もできるかもな。
だが、1000人月越えたシステムでは、そんな温室の論理は通用しないんだよ。

っていうかお前は、請負とは別の形態か、あるいは学生の妄想だろ。

400 :デフォルトの名無しさん:2006/11/20(月) 02:46:04
「チクショウ出しやがれクソッタレが!!」

朝起きたら見知らぬ部屋にMハゲのオッサンと一緒に閉じ込められていた。
Mハゲのオッサンはさっきから壁をガンガン蹴りながら暴言を吐きまくっている。
と言うか誰だよ。このハゲは。

「おい、貴様!!」
ハゲに話しかけられた。
1時間ほど壁を蹴り続けて流石に無駄と気づいたのか。

「ここはどこだ?」
そんな事オレが知るわけ無いだろう。
「チッ、役立たずが」
腹立つオッサンだ。

「舐めやがって……オレに本気を出させたいようだな。良いだろう」
ズアッ!!

独り言を言いながらオッサンが急に光り輝いた。
流石のオレも驚いた。デコが光るとかそういうレベルじゃない。
髪の色まで変わってマンガみたいな金色のオーラ出してる。何だコイツは。

「これが超(スーパー)ベジータだ!!!」
この人は超(スーパー)ベジータと言う名前らしい。
オレがちょっと噴出したら超(スーパー)ベジータは物凄い睨んできた。
怒るなよ超(スーパー)ベジータ。

ちなみに光ったのは良いけど別に部屋からは出れなかった。

401 :デフォルトの名無しさん:2006/11/20(月) 06:27:58
ん、俺ってもしかして天才?
とか
おお、これぞプロ中のプロ!!
とか

何でもいいからささやかな自己満足を日に何度か味わわないとさ、
続けるのは苦しいじゃない

402 :デフォルトの名無しさん:2006/11/20(月) 06:40:22
意図したとおりに動作する、これに尽きるものはない。
これが当たり前で、他のことに悩めるようになればプロだと自認できるのかも。
所詮は人間の決めた明示的なルールと数学的論理に従っているだけだ。

実際にプログラミングしない奴はそもそもプログラミングで悩む必要がないので論外だが。

403 :デフォルトの名無しさん:2006/11/20(月) 20:13:44
客は第一に(予算内で)動くモノを求める。
それに応えればあとは作る側で好き勝手に読みやすさとかメンテしやすさを追求すればよい。

いいか? 客が求めることは(予算内で)ちゃんと動く物だぞ。

出なければ金はださん!

404 :デフォルトの名無しさん:2006/11/20(月) 20:39:27
>>403
ケチ

405 :デフォルトの名無しさん:2006/11/20(月) 21:01:40
>ちゃんと動く物
そのためにどれほどコストをかけるべきなのかを分かってないところは
安く請け負ってくれるところへ行く。
分かってるところはすでに決まった依頼先があるか社内にそういうチームがある。

406 :デフォルトの名無しさん:2006/11/20(月) 22:03:33
>>404
10万儲かるなら3万出してやる。
1000万儲かるなら300万出してやる。
10億儲かるなら3億出してやると言っているんだよ。

客に儲けさせてなんぼの“道具(=システム)”だろ?
客の予算に見合った開発せずに自慰行為したってそれはプロとは言えないよ。

407 :デフォルトの名無しさん:2006/11/20(月) 22:26:39
むしろプロとしては個人的にこうした方が儲かるという仕様に変えるよりも
変だと思っても客の注文通り忠実に仕上げるのが正解だと思うな

408 :デフォルトの名無しさん:2006/11/20(月) 23:43:18
>>407
客側の理論に対してそういった考えが正しいと思うんだ。
「忠実に仕上げる」作業に自慰行為は二の次なんだよな。
限られた時間と予算で最初に求めるべきは何かを考えないと。
これが最初の儲けだよ(客の脳内だけど)。

10億の計画のためのシステムが3億で出来た。計画通り
10億の儲けを出せば、3億引いても7億の儲け。

それを実行し、具現化するのは 顧客の自己責任 だ。
作る側はそれを心配したり保証する必要はない。
そういったことはコンサルに任せればいい。

「プログラム」ってのはあくまで道具なんだし。

409 :デフォルトの名無しさん:2006/11/21(火) 01:21:43
>>399
はぁ・・・
お話にならないな。尼はもう来ないでください。

410 :デフォルトの名無しさん:2006/11/21(火) 03:01:07
↑テーブルの項目名を日本語にするやつw

411 :デフォルトの名無しさん:2006/11/21(火) 06:15:26
>>410
あれは教科書が悪いんだ!

と擁護してみる。
もちろん自分は最初から知っていたけど教えてあげない。
無駄な努力を重ねていくことで人間は成長していくと思うから。
何事も経験だ。

412 :デフォルトの名無しさん:2006/11/21(火) 08:21:58
>>407
改変が歓迎されてるならかわいがられるな。

言ったものしか出さないと、取替えのきく凡々とした
奴だと思われる。

413 :デフォルトの名無しさん:2006/11/21(火) 09:15:46
>>設計をちゃんとしておけって言っただけなんだが?
>おまえが絶対ミスを犯さない完全無欠の天才ならそう言っていればいいよ。

>設計に問題がある、とテスト段階で解った時に、
>「設計がちゃんとしてれば」なんて言っても始まらんのだよ。
>しかも細分化・抽象化することで、そういうリスクが増えると。
設計が間違っていたと理解したなら直せよ。
その為のテストだろうが.。

414 :デフォルトの名無しさん:2006/11/21(火) 13:14:47
>>413
納期まで半年あれば直してやるよ

415 :デフォルトの名無しさん:2006/11/21(火) 13:47:42
もうちゃんと動いてるのに、
もとから依存してるオブジェクトで、そこを切り替えるなんてありえねぇってのに、
「コンストラクタ使っちゃダメだろ」「依存が強まっちゃうよ」とか。
切り出してもそこ以外で使う事なんてあり得ないのに、
「この辺は別クラスに切り出せるよね」とか。
そこ以外やることはあり得ない処理だし、それが出来ちゃう公開メソッド用意してるくせに、
「この処理はこっちのクラスでやるべきだな」とか。

おれらがやってるのは宗教じゃねぇんだよ、仕事なんだよ、仕事。と。

416 :デフォルトの名無しさん:2006/11/21(火) 15:44:57
そんなこと言ってるのはどこだよ?

417 :デフォルトの名無しさん:2006/11/21(火) 15:50:15
漏れなんか、最初のスケジュール(工程表)どおりにいったことないよ
スケジュールどおりにいかない=>動作しなかった...orz
上も下者も、最初のスケジュールどおりに行かないのはわかってるから、まっ、そういうもんだで済ましてる。
自社製品開発だからこんな調子でもなんとかなるんだろうな

418 :デフォルトの名無しさん:2006/11/21(火) 16:08:38
再利用したことないとか言うが、いつ使うかわからんわけで、備えあれば憂いなしというのもあるわけで。

でも、そのプログラムは本当に動いているのか?
どこか重大なバグとかがあるかもしれないだろ。
設計やコーディングの段階でそういうのをなるべく減らしたり、あるいは発見しやすくして、なるだけその可能性をなくすためにここまで言われてるんだろうよ。
まあそんなのも分からずにただ猿のように叫んでる奴もあれだが。

419 :デフォルトの名無しさん:2006/11/21(火) 16:27:15
綺麗にオブジェクト指向で書かれたコメントだらけのやたら長いだけのコードより
旧来の関数型で完結に少ないファイル数でまとめられたコードのほうがはるかに再利用性は高い
なぜなら、馬鹿でも理解できるから

420 :デフォルトの名無しさん:2006/11/21(火) 16:32:04
ここまで綺麗に暗号化してるんだからその美しさを理解しろ、出来ないやつが馬鹿なんだ
とかいくら言ったところで世の中馬鹿しかいないのだ
お前も含めてな
余計なことはするな
仕様書がいくら綺麗にまとめられていても結局コードが理解できなければ意味がない
コードが理解できるものであることが何よりも重要なのだ
仮に仕様書がなくても、コードが仕様書になるものこそが最高のコードなのだ

421 :デフォルトの名無しさん:2006/11/21(火) 16:48:46
自分は保守のことを考えて可読性の高いソース書くように心がけていた。
もちろん納期も守っていた。

しかし会社にとって、そんなことは評価の対象にはならなかった。
コードの保守性の高さも評価してくれるように、面接等で上司に話してきたが
ぱっとしない返事が続いた。

だがその反応はある程度予測はしていた。
評価するたって、上司が全部コード読むのか?それは無理な話だ。

ではどうすればよいのか?それは良質のコードを書き続け、
「〜はよいコードを書く人だ」ということを、上司を含め周りの人間から
認知してもらい、それが会社にとってプラスであることを証明することだ。

私はそれを10年続けた。しかし、成果物で評価されても、
保守性が高いことは評価されなかった。
良質のコードを書くことは、周りも上司も知っていた。
しかしそれが考課には反映されるか、というと、それはまた別の話である。

コードの精査はやめて「動けばいいじゃん」で俺も行こうか。
そう思ったこともあったが、自分にはできなかった。許せなかった。
仕事におけるプログラミングとは何なのか。自分はどうすればよいのか。
答えがでなかった。今年8月、私は会社を退職した。

結局は私のわがままだったのかもしれない。
であれば、残された道は起業することだ。それしか道は無いと思った。

そして今、私は立派なニートになったのであった。完。

422 :デフォルトの名無しさん:2006/11/21(火) 16:50:18
オブジェクト指向って結構癖がある考え方だよな。そして構造化から来るとせっかくのクラスもただの特殊収納棚になってしまうことが多いし。
結局構造化のほうに慣れてる人が多い職場だとそっちのほうが効率いいし、逆も言えるということか。

423 :デフォルトの名無しさん:2006/11/21(火) 19:12:27
道具ってのは上手く使ってこそだよ。
使い方を勉強汁。

424 :デフォルトの名無しさん:2006/11/22(水) 00:26:17
綺麗に書くことにこだわって、
何でもかんでもJava
何でもかんでもC++
何でもかんでもVB.net
何でもかんでもhogehoge
とかバカなことをいわず、

適材適所で枯れたソースを使い回して、
本当に新しい部分にのみ適した言語を適用するくらいの
割り切りがないと、綺麗なソースでも腐ったシステムしかできないよ。

425 :デフォルトの名無しさん:2006/11/22(水) 00:37:00
>>419
>旧来の関数型
>旧来の関数型
>旧来の関数型
>旧来の関数型
>旧来の関数型
>旧来の関数型

426 :デフォルトの名無しさん:2006/11/22(水) 00:44:19
>>421
なんだよ、起業しろよ。

427 :デフォルトの名無しさん:2006/11/22(水) 01:04:59
起業してPG作業から離れて経営側に立つと、
気が付くと>>403になり、しまいには>>313の顧客と同じ事やってる、という罠。

428 :デフォルトの名無しさん:2006/11/22(水) 16:50:29
長期間安定して動作する頑丈なコードより、
たまにバグが出るコード書いて
「連絡一本で現場に駆けつけて即対応!」
の方が商売になる罠。

429 :デフォルトの名無しさん:2006/11/22(水) 17:37:57
limit of out sourcing...orz

430 :デフォルトの名無しさん:2006/11/22(水) 19:57:12
こんなもん商売にしても無駄
小学生でもましなもん作れる

431 :デフォルトの名無しさん:2006/11/22(水) 20:01:34
マって所詮詐欺師だと思う
ム技術なんて必要無い
必要なのは口だけ

432 :デフォルトの名無しさん:2006/11/23(木) 01:43:10
>>424
んだな。
だがそのためには、事前にいろんな言語や技術について知っておかなきゃならない。
俺の経験でいうと汚いコード書くような奴は、普段勉強してないやつかまたはセンスが
ない奴のどっちかだ。
なのでどちらかというと、キレイなコードにこだわって仕事が遅いやつの方が
先々見込みがあるように思う。

433 :デフォルトの名無しさん:2006/11/23(木) 01:44:17
>>432
でも、そいつがお前のコードに文句つけてきたりするんだぜ

434 :デフォルトの名無しさん:2006/11/23(木) 02:11:21
>>433
そういうのはむしろ、対人スキルの範疇なんじゃね?

435 :デフォルトの名無しさん:2006/11/23(木) 12:53:34
毎年予想外の法令改正に対応する現場じゃ、汚くても法令に間に合うプログラムと
そのプログラムを作るプログラマーだけが生き残る。これマジ。

昔綺麗に作ってあった医療報酬プログラムを見た。ある意味感動した。
10年法令改正に対応できていたみたいだが、有る年を境にどうにもならなくなった。

「最初の想定範囲外の法令改正」が発生したからだ。綺麗度を保つためには
最初から作るしかないくらいの大きさだが、施行は来月。さぁどうする?

そのとき駆り出されたのが俺なんだが、俺のモットーは「動けばいいじゃん」だった。
クラスを書き換えるどころか、別のスタティック関数で置き換えをやっていった。

客も、その先のエンドユーザーも施行を無事乗り越え、その後も稼働が続いている。
さすがに10年持たせる自信はないので、「この間にあらたなモノを作るよう」に
製造元にアドバイスした。引き留められたがおれは参加しないよw


オナニーは自宅でやるもんだw

436 :デフォルトの名無しさん:2006/11/23(木) 13:12:20
>>435
どアホ、お前が楽できたのはそいつのコードのおかげだろ
先のやつがスパゲッティだったらそもそも来月までに解読できない。
そしてお前の後のやつにはお前のしわよせがくる。
曰く「前の人はすぐ書き換えて治してくれたんですけどね・・・」
それが、今の俺だから困る

437 :デフォルトの名無しさん:2006/11/23(木) 13:14:10
最初っから「動けばいいじゃん」でつくってあったら、
アドホックな対応すら出来なかったんじゃないのかね。

438 :デフォルトの名無しさん:2006/11/23(木) 14:13:07
可読性は保険みたいなものだ。
>>435の事例のようなときのためにある。

家族でもないあかの他人のかけ金を払うのはアホらしい。
故に人の手を渡っていくごとにコードはスパゲッティ化していくのが宿命だ。
コードがそれ自体の価値も見定められないままに企業の知的財産だと信じている馬鹿がいる限り、
いずれ誰かが生贄にならなければならないのさ。

>>435は生贄にはなりたくないと言っている。
それは人間の普通な感情ではないかな?

439 :デフォルトの名無しさん:2006/11/23(木) 14:44:42
>>438
考えが浅すぎるよ。もっとかんがえろ。

440 :デフォルトの名無しさん:2006/11/23(木) 17:43:13
可読性にコストを掛けても、顧客満足度は上がらない。
 → 可読性にコストを掛ける作業は自己満足のリソース浪費。つまり無駄。

441 :デフォルトの名無しさん:2006/11/23(木) 17:51:28
いや単なる自己満足だったら可読性なんか放置するんだが。
極端な話、使い捨てるならソースを消してしまうとか。
保守工数も考えたトータルコストを考えると、可読性は最優先事項になってしまうんだ。
顧客が「毎回作りなおしてくれても良いよ」
という太っ腹なら話は別ですけどね

442 :デフォルトの名無しさん:2006/11/23(木) 17:53:31
時と場合による!

443 :デフォルトの名無しさん:2006/11/23(木) 18:08:43
プロジェクトメンバが多くなるほど可読性とコーディングルールが重要だと思うのだが、
うちの会社はそれに逆行するから嫌だ。
メンバ数の数だけコーディングルールが増えてしまい、無理矢理統一しようとすると最底辺に
合わせることになって、配列禁止とかループ禁止とか構造化禁止とか信じられないルールが
罷り通る。
猫の手も借りたい状況だとしても、本当に猫の手を投入するのは心の底から遠慮したい。

444 :デフォルトの名無しさん:2006/11/23(木) 18:24:35
>>441
納品後も保守運用まで必ずセットで請ける会社なのか?
そうでなければ、保守コストを払うのは他の会社だ。

もっと言えば同じ会社であっても、おまえが保守するのか?
そうでなければ、保守コストを払うのは他の奴だ。

それが勝手というなら、
可読性を向上させることに対して、会社はお前を評価するのか?
可読性を向上させることに対して、会社はお前に正当な追加ペイをしているか?
そうでなければ、保守コストを払うべきなのは会社であって、
お前が可読性を向上させるのは会社に対するボランティア・無償奉仕だ。



>>SSL
>猫の手も借りたい状況だとしても、本当に猫の手を投入するのは心の底から遠慮したい。

プロマネや上の人間にとっては、兵隊は兵隊、
お前も猫の手も同じ雑兵に過ぎないって事だ。

445 :デフォルトの名無しさん:2006/11/23(木) 18:39:35
> 配列禁止とかループ禁止とか構造化禁止

おいおい、コーディングルールとかのレベルじゃないぞ、それ。

>>444
可読性を向上させても大して評価しないけど、可読性が低いコー
ドを書く奴の評価は下げるよ。

446 :デフォルトの名無しさん:2006/11/23(木) 19:20:02
可読性は普段は評価されないな

仕様変更やバグ発見して、直す時に「なんでそんなに工数かかるの?」
と調べられて、初めて発覚する



447 :デフォルトの名無しさん:2006/11/23(木) 19:40:22
読めるレベルのコードを書くのにそんなに時間かかるのが
まずおかしいだろ。
むしろある程度読めるコードを保たないと、よけいしんどいし
時間もかかる。

448 :デフォルトの名無しさん:2006/11/23(木) 19:42:05
評価されるとかされないとか、恥ずかしいヤツだな

449 :デフォルトの名無しさん:2006/11/23(木) 19:56:03
つ 貴方の生産技術者としての良心

450 :デフォルトの名無しさん:2006/11/23(木) 20:02:30
>>449
今切らしてる

451 :デフォルトの名無しさん:2006/11/23(木) 20:52:27
いわゆる経済設計が横行しているのは日本にとってはまぁよくないけど
なかなかむずかしいね。規制できるもんでもないし

452 :デフォルトの名無しさん:2006/11/23(木) 21:52:19
http://d.hatena.ne.jp/fromdusktildawn/20060118/1137558108

453 :デフォルトの名無しさん:2006/11/23(木) 22:27:49
>>452
ありがと・・・

454 :デフォルトの名無しさん:2006/11/23(木) 23:08:46
>>436
それを書いた製造元がさじ投げたんで、引き継いだだけ。
楽が出来るコーディングなら製造元が離すわけ無いだろw

終わった後の二次対応は製造元が引き受けたよ。
長期の予算と期間を貰ってな。
が、単価は半分以下にされたってよw

455 :デフォルトの名無しさん:2006/11/23(木) 23:12:33
あと言っておくとソースなんて1割も見てねぇよ。
デバッガで追いかけながらパッチ的な関数を埋め込んでいっただけ。

投入したエントリデータと出来る帳票と格納されたデータの辻褄を合わせただけだ。
腐ったソースだろうが、綺麗なソースだろうが、楽じゃないがどっちも同じだよ。

対応できていないシステムならソースが綺麗でも読む意味がないだろ?
出力結果が全てだし。

456 :デフォルトの名無しさん:2006/11/23(木) 23:48:55
>>454-455
なんか、必死さが滲み出てるんだけど...、気のせいかな? (w

457 :デフォルトの名無しさん:2006/11/23(木) 23:50:34
>>455
下のほうでいい気になってりゃいいじゃん。
ちゃんと研鑽してる奴なら、お前レベルの考えることはみんな
とっくに通過してる地点だっつーの。

ちょっと器用だからって、何の努力もしない
そのくせえらそうにしてる痛々しいお前の姿が目に浮かぶわ。

458 :デフォルトの名無しさん:2006/11/24(金) 03:59:57
なんつーか、ソースコードってのはプログラマの成果物であると同時に作業場でもあるわけで。
机が散らかっているのが嫌なのと同じレベルで汚いソースも嫌だ。
限度を超えれば作業効率にも支障をきたすし。

459 :デフォルトの名無しさん:2006/11/24(金) 07:08:43
自己満足の世界だな

460 :デフォルトの名無しさん:2006/11/24(金) 07:45:34
ある程度は自己満ないとやってけないだろ。
動けばいいや主義もある意味自己満だ。

461 :デフォルトの名無しさん:2006/11/24(金) 08:44:58
他人に強要しだしたらあぼーん

462 :デフォルトの名無しさん:2006/11/24(金) 11:42:43
全てはオブジェクトである

463 :デフォルトの名無しさん:2006/11/24(金) 14:56:53
動けばいいじゃんって言ってる奴は、簡潔なソース書けない奴の言い訳。
無理に綺麗にしようとしたら、余計にスパゲッティになるからそのままでいいよ。

464 :デフォルトの名無しさん:2006/11/24(金) 17:00:03
プロである以上「ちゃんと動く」のが「最低ライン」だろ。
動けばいいじゃんと最低ラインで満足してるやつらのコードは
油断するとすぐ動かなくなって周りが迷惑するから、
もっと上のラインにしてくれ。

465 :デフォルトの名無しさん:2006/11/24(金) 21:26:33
>>464
> プロである以上「ちゃんと動く」のが「最低ライン」だろ。

マイク●ソフトの開発担当者に言ってくれ。(w

466 :デフォルトの名無しさん:2006/11/24(金) 21:45:39
>465
そりゃ無理な相談じゃない?大量の過去の遺産(=互換性維持)と無茶な要求が常に飛び交ってるような状況じゃ。

467 :デフォルトの名無しさん:2006/11/24(金) 22:36:32
つ「動かないコンピュータ」

468 :デフォルトの名無しさん:2006/11/24(金) 23:27:32
斜め45度の角度でチョップしてテレビの映りを回復する
そんな修理屋さんの話

469 :デフォルトの名無しさん:2006/11/27(月) 02:18:39
ディフェンシブな開発 〜 SIビジネスの致命的欠陥
http://d.hatena.ne.jp/kuranuki/20060116/p1

請負開発は、安かろう悪かろうになる運命なのさ。

470 :デフォルトの名無しさん:2006/11/27(月) 17:02:10
スレタイを含め>>1の発言が、
公判中の堀江容疑者の発言にそっくりなのは気のせいだろうか。

「面倒くさいことは嫌い」だとか知らないことを聞かれると「説明が長いのは嫌い」
だとか言い訳ばかりしているところ、ほんとに堀江容疑者にそっくりだ。



471 :デフォルトの名無しさん:2006/11/27(月) 20:05:11
堀江さんがいると聞いて駆けつけました。

472 :デフォルトの名無しさん:2006/11/27(月) 20:32:46
いいじゃんいいじゃんプップクプー

473 :デフォルトの名無しさん:2006/11/27(月) 22:41:32
>>470
ちゃんと作ると面倒なのか?
ちゃんと作ると説明が長くなるのか?

 なんか変じゃね?

474 :デフォルトの名無しさん:2006/11/28(火) 00:08:30
要するに耐震偽装も真っ青の手抜き構築ということで…

475 :デフォルトの名無しさん:2006/11/28(火) 01:34:56
直接人死にに関わるわけじゃないんだからノープロブレム

476 :デフォルトの名無しさん:2006/11/28(火) 01:38:15
組み込みは人死ぬだろ。車とか。
金融とか勘定系だと自殺とかもあり得る。

477 :デフォルトの名無しさん:2006/11/28(火) 01:39:03
>>475
010 システムトラブル発生
020 責任者更迭
030 場合によって
040  自殺者発生
050  労災裁判
060  責任者更迭
070  goto 030

478 :デフォルトの名無しさん:2006/11/28(火) 01:39:34
医療系、軍事系、宇宙開発・・・

479 :デフォルトの名無しさん:2006/11/28(火) 01:44:13
gamer「うわっ、バグかよ、マジ死ぬ・・・」

480 :デフォルトの名無しさん:2006/11/28(火) 02:01:46
だからといってマが社会的に吊るし上げ喰らったという話は聞かないな
自分以外誰が死のうと知ったことか

481 :デフォルトの名無しさん:2006/11/28(火) 02:06:40
>>480
要するに耐震偽装も真っ青の手抜き構築ということで…

482 :デフォルトの名無しさん:2006/11/28(火) 03:43:28
>>477
この業界だと、020行でぬるぽが出そうな気がする。(w

483 :デフォルトの名無しさん:2006/11/28(火) 04:24:07
>>482
だれがうまいこ(ry

484 :デフォルトの名無しさん:2006/11/28(火) 13:53:22
一級建築士とプログラマでは
社会的な地位が違うだろが

485 :デフォルトの名無しさん:2006/11/28(火) 20:25:26
バグのないプログラムはない
トラブルのないシステムもない
耐震偽造のない建物はある

486 :デフォルトの名無しさん:2006/11/28(火) 21:22:54
>耐震偽造のない建物はある
かといって将来どんな地震でも倒壊しないという保証は無い。

487 :デフォルトの名無しさん:2006/11/28(火) 23:23:32
Windowsの場合に限るが、

 何 が 起 こ っ て も (貰 っ た 代 金 以 上 は) 保 証 し ま せ ん

つってんだから、作ったアプリが動けばそれだけでもっけモンだろ。
アホなOSの上でこった作りのアプリ動かしても、誰にほめられるモノでもない。

488 :デフォルトの名無しさん:2006/12/02(土) 23:12:05
>>1はきっと問題が起こったとき他人に責任押し付けるのが上手なんだろう。

489 :デフォルトの名無しさん:2006/12/03(日) 02:47:37
>>487
じゃあ、Windowsの悪いところあげて。あと、君の言うアホじゃないOS

490 :デフォルトの名無しさん:2006/12/03(日) 03:42:18
>>489
Windowsの悪いところ:重い
アホじゃないOS: BIOS
でFA?(ぇ

491 :デフォルトの名無しさん:2006/12/03(日) 06:42:07
それ本気で言ってるの?

492 :デフォルトの名無しさん:2006/12/03(日) 08:16:09
>>491
よく読めカス

493 :デフォルトの名無しさん:2006/12/03(日) 08:29:55
>>490
ちょっとウケタ (w

494 :デフォルトの名無しさん:2006/12/03(日) 08:33:44
>>490
warota 最高!!!

495 :デフォルトの名無しさん:2006/12/03(日) 14:35:34
>>490
センスあるな(w

496 :デフォルトの名無しさん:2006/12/03(日) 14:56:52
>>490
ようわからんが嫉妬

497 :デフォルトの名無しさん:2006/12/04(月) 23:27:15
情報処理産業経営実態調査研究会委員長を務める東京大学大学院教授の元橋一之氏は、
今回の報告書で「下請け構造が生産性の低さにつながっていることがはっきりした」と語る。
「現状多いのはコスト積み上げ型の何人日という形での見積もり。ソフトウェア工学は
進歩しているが、生産性を上げても金額が低くなってしまう。
このジレンマが生産性の上がらない要因。それがまさしく浮き彫りになった調査」だという。
http://www.atmarkit.co.jp/news/200611/29/ipa.html

498 :デフォルトの名無しさん:2006/12/30(土) 01:56:04
つまり、派遣を使うのはよくない、

127 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)