動けばｲｲじゃん。ｳﾀﾞｳﾀﾞ能書き垂れる奴って何なの?

ちゃんと動くプログラム書いてるのに、あれこれ屁理屈言ってくる奴。

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

でも、そんなこと使ってる奴らにとってはどうでもいい話。

いいじゃん別に。
２ｃｈなんかひまつぶしなんだからよう！

ここはお前の日記帳ではありません

>>1
詳しい話は違うかもしれんが、
チーム開発だと、「ちゃんと動くプログラム」だけじゃだめなんすよ
プログラミングのスキルや知識はあるんだけど、
すごく雑なプログラム書く人がいる
そういう人は所詮、日曜プログラマなんだよ

>>5
>プログラミングのスキルや知識はあるんだけど、 
>すごく雑なプログラム書く人がいる 

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

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

>>5
全然理由になってないよ。
仕事だからこそ、無駄なことに時間を使っちゃダメなんだよ。
半日で終ってるモノを屁理屈で何度もやり直して丸１日とか２日とか掛けるのは、
仕事を舐めてる自己中自己満のやることだよ。

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

保守する人の気持ちになろう

雑ってのもあれだよな。
変更がありそうなところにちょっと変更があっただけでもバグになる雑さは問題だが、
屁理屈だけの能書きにあってない、って雑さは実際は問題にならないかも。

>>10
>屁理屈だけの能書き

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

＞屁理屈
いやまぁ、だからさ　その１の言う屁理屈が何かがはっきりわからんと・・・
俺は最初に断わりとして「詳しい話は違うかもしれんが」ってかいてあるので
話がずれている可能性はある

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

>>12
>普通のプログラム書かせるとソースとしては複数開発には向かないものになる 
>「雑」というのは「煩雑」ということ 

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

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

Ｑ．ウダウダ能書き垂れる奴って何なの？
Ａ．女の腐ったような奴なの。

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

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

いや。ある意味宗教に近い。
大司教（クライアント）の言うことは絶対だしな。

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

こんなこと言うクライアントなんかいねぇよｗ
つうか、クライアントの要求を納期通りに仕上げることの邪魔でしかない。

キモオタﾋｮﾛﾋｮﾛ大卒厨

それだけじゃ良く分からんな。
全体的にレベルが低い職場なのかもしれないし、>>1 の説明能力が低いだけかもしれないし、
両方かもしれないし。

世の中、何が雑だと言えば、
「雑」と「煩雑」の区別をつけず、
一緒くたに「雑」の一言で
片付けることほど雑なことはないと思う。

>>17
俺は変数名はちゃんと付けてるが、
保守の専門卒の奴らは英語が分からないので意味なし。
あと、納めた後の工数×単価が、開発時の無駄な工数×単価以上に本当に節約されるのか？
それに、会社として納品までの商売だったら？

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

>>17
>「動けばいい」というのは目先の判断であって将来的にかかる費用が考慮されていない 

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

>>23
>突っ込まれる人がソース全体を把握せずに修正しているって言うことだな 

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

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

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

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

>>23
しつこいけど、全然理由になってないよ。
教義はイイから、利益を説明してくれ。
宗教じゃなくて仕事でやっているんなら。

>>26
「俺達」を会社まで範囲を広げちゃいけない訳じゃないぜ。
それに、自主的に会社まで範囲を広げて、ちゃんと評価されるのかい？
評価もされないのに勝手にやっても、それはお節介かボランティアだぜ？

一回他人が書いた雑なプログラムを保守してみれば分かるだろ。
まして自分が書いたモノを1年後に自分で保守した時に
あまりに汚すぎて他のスケジュール押してまで修正する羽目になった身としては、
極力綺麗なコードを心がけるようにしてる。自分のためにも。

>>28
そこまでいうのなら、君がどこかの会社に入るとき面接でなんていうのかね？

＞「俺達」を会社まで範囲を広げちゃいけない訳じゃないぜ。
＞それに、自主的に会社まで範囲を広げて、ちゃんと評価されるのかい？
＞評価もされないのに勝手にやっても、それはお節介かボランティアだぜ？
ちょっとまてよ、その考えはもはや「仕事」じゃなくなっているだろう。

その後の保守の仕事を確保するため、
極力雑なコードを心がけるようにしてる。自分のためにも。

>>31
じゃあ、納品で終わりの案件中心の会社ならどうなんだぜ？

得てして保守の仕事は他の仕事が忙しい時に回ってくるもんだ。
マーフィーの法則

>>33
その会社からは、次の仕事が来ないだろうな

>>31
激しく同意。

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

おまえ、もう一杯一杯だろ？理屈ばっかりでお話にならないよ

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

おまえ、ＳＥと話すとき、足震えてるだろ？ｗ

別にそんなに読みづらいコードを書いてる訳じゃない。
連中が言うように辺に細分化した方が読みづらい、読むのが面倒な事の方が多いと思う。

>>38
そんな事はない。

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

>>36
>機能拡張や修正の仕事が着ても間単に修正できるようにし、 

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

>>37
ちょっとVIPPER風味を入れてみただけだぜ？
つまんない揚げ足取りしかできなくなって一杯一杯にみえるぜ？
>>33や>>38にちゃんと答えてみ？

>>38
中心となっている話には賛同できないが
これは同意
俺は何でもかんでもオブジェクト指向やデザインパターンを使わなければならないという人間ではない

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

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

>>42
そんなあなたにdoxygen+dot

>>39
「普通」じゃ利益の説明になってないぜ？
それに、個々の動作は結局の所は具体的な処理で行われるもんだ。
やたらなんでも抽象化したって、具体的な動作を読み取るのに、
読むべきファイルが増えるばっかりだぜ？

＞＞>>33や>>38にちゃんと答えてみ？
おまえはソースだけではなくレスも読めないのか？
掲示板という時間のずれを考慮すれ

マ板でやれ

＞＞４４
仕事といえるのか？答えろ

>>46
うるせーな。俺、今久々に燃えているんだよ

>>44
普通に利益の話だと思うが？

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

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

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

>>44
スレ読んでるかい？
>>22の
＞納めた後の工数×単価が、開発時の無駄な工数×単価以上に本当に節約されるのか？
の証明を示してくれたら、
保守まで請負った案件の場合に限っては、
会社に忠誠を尽くす仕事とはいえないと認めてやるよ。

>>47
スレ読んでるかい？
>>22の
＞納めた後の工数×単価が、開発時の無駄な工数×単価以上に本当に節約されるのか？
の証明を示してくれたら、
保守まで請負った案件の場合に限っては、
会社に忠誠を尽くす仕事とはいえないと認めてやるよ。

>>49
>>1には賛同できないが
俺の携わった仕事では
過去に作成されたクラスが再利用あるいは継承されることはいまだかつて無い。
俺もえらそうなこと言っているが、結局再利用されなければ>>1に対しても強いこといえないなぁ・・・（泣

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

＞＞保守まで請負った案件の場合に限っては、
いつからそんな狭い話になったんだ？

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

>>52
それは、何故、再利用できないかを考えたのか？

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

>>53
保守の費用が削減できるって理屈なんだから、
そういう条件の場合にしか言えないだろ。何を言ってるの？

>>54
＞どこかの部屋の桟のために切り出した木材は、幾ら屁理屈に則っていじくっても、
＞他の柱に転用は出来ないんだよ。

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

>>44
具体的な動作を読み取る必要がないように抽象化してるんじゃないの？
知らんけど

結局一番効率が良いのは
他のグループに引き継いだりせずに、
一つのシステムを同じグループ内だけで
作成し、保守し続けることなんだよな。

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

>>55
うーん、まったく再利用してないわけではないんだけどね
前プロジェクトのソースをコピペしたりとかはする←これは再利用のレベルが違うよね

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

>>57
>実際の家の柱では無理だが

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

ソースの見た目が汚いのはまだ許せる。
が、アルゴリズムや構造が汚い・遅い・ヘボいのはチーム全体に迷惑がかかるから頂けない。

>>57
抽象的な空想はイイから、具体的に頼む。
木材に比べたらコードの方が自由はきくが、
それでも現実にはそんな使い回しできる場面はほとんどない。
だいたい、ちゃんと契約してないと他の案件の作成物を他で使うこと自体NGだしな。

完璧なドキュメント
完璧に書庫化されたライブラリ
なかなかむずかし〜ね〜

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

>>58
それは屁理屈の上では半分は正しいが、
デバッグをやった事があれば、そんなきれい事は言えまい。

>>63
こういう問題はこう解決する、だとか、こういうデータ構造にすればいい、みたいな
いわゆるノウハウの使い回しは日常的にしてるだろ？
汚いソース、理解できないソースを量産されると、それすらも出来なくなるからダメなんだよ。

>>66
最後の行と、それより上の行が繋がってません。

キモオタﾋｮﾛﾋｮﾛ馬鹿学生

>>55
その細分化のコストが本当に利益に見合うのかって話なんだが。
それに、顧客独自の仕様をどうしろってんだい？

>>67
俺はわかるよ　どこか矛盾しているところでもあるのか？
おまえが経験不足なだけじゃないの？

>>1
Martin Fowlerさんが書いた「技術的負債」って話を読めば？
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?TechnicalDebt

>>67
自分で作った物なら、自分でノウハウを持っているからいいけどね。
以前に別のチームが担当した案件のノウハウを拝借する場合なんかは
理解するのに時間がかかると、それだけ効率が低下する。

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

＞以前に別のチームが担当した案件のノウハウを拝借する場合なんかは
＞理解するのに時間がかかると、それだけ効率が低下する

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

ソース読んで理解できないから担当者に話を聴いてみたら、
何のことはないソースが無駄なことをやっていただけ、なんてのは良くあるな。
そういう時、綺麗なソースを書いて欲しいと痛切に思う。

キモイおっさん達がうようよと集っているスレはここですね。

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?TechnicalDebt

>>70
矛盾してるとは言ってない。矛盾以前に論理的に繋がってないと言っている。
それに、汚い読めないコードを書いている訳じゃない。
むしろ、教義を盲信して、やたらブツギレでやたら処理が分散してやたら抽象的なソースより
よっぽど読みやすい。

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

>>77
> むしろ、教義を盲信して、やたらブツギレでやたら処理が分散してやたら抽象的なソース

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

>>74
> 何のことはないソースが無駄なことをやっていただけ
いっとくが、そんなのは俺は肯定してないからな。

>>78
細分化・抽象化を進めたらそうなるんだが。
だとしたら、能書き垂れる奴が目指すのが「構造が汚い」ソースと言うことだな。

キモオタﾋｮﾛﾋｮﾛ馬鹿学生

何事もほどほどにってことだろ。
フレームワークを作るときにThree Examplesの原則を無視して
片っ端から抽象化したりする奴とかな。

ほどほどっていうか、多分何も考えずに単純に抽象化してるからだろ。

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

>>65
細分化されてればバグの切り分けも楽になると思うけど

しかしトレースが面倒になる罠

まあ、保守やテストがしやすいように設計すればいいってこったな

なんでトレースが面倒になるんだろう・・・

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

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

つまり綺麗に書け、でFA。

>>84
なんで？経験的には、
細分化されてると、どっちが悪いとも言えず、
（呼び出し先は結局要件を満たしてなかったが、単体と見たらその責務は負うべきでない場合）
構造に手を付けざるを得なくなるような事が
よくある気がする。

>>89の場合は、大抵、呼び出し側ではその要件を満たすことが出来ない。細分化されてるので。

キモオタﾋｮﾛﾋｮﾛ馬鹿学生

>>89
それこそ『何で？』って感じだろ。

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

>>92
日曜プログラマはそれでイイかもしれんがね。
職業プログラマは、起きえるリスクに対してそんな無責任なことは言えないんだよ。

>>89
>構造に手を付けざるを得なくなるような事が 
>よくある気がする。 

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

え、俺?

>>93
意味不明だな。

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

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

ｽﾏｿ。誤爆した。

妥協をするのは納期に詰まってからでいいんだよ！

＞設計をちゃんとしておけって言っただけなんだが？
おまえが絶対ミスを犯さない完全無欠の天才ならそう言っていればいいよ。

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

>>94
>>89の事態のなにが利益なの？

＞＞99
何でテスト段階なんだろう・・・
多分、製造段階で分かるのに・・・

>>99はウォーターフォール型開発しかできないお方ですか？

細分化を抑えた設計で、後から設計のミスが分かった場合には
それこそ細分化して直さなきゃいけなくなるぞ。
クラスの責務の一部にだけミスがあったりしたら((；ﾟДﾟ)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>103
それが日常化してる、なんちゃってPG/SEにはその感覚が分からんのですよ。

>>101
おまえのとこはテスト段階でNGがでないのか。
それはテスト技術に問題があるのではないか？

>>103
馬鹿みたいに細分化してない事で、あとでの設計ミス発見による痛手が、
馬鹿みたいに細分化しる場合より大きくなるというのは、どういう場合だい？
責務が細分化されて見事に一カ所に問題が局所化されていたら、それは設計の問題じゃないのではないか。
むしろ、設計の問題は、細分化の仕方がおかしいという類のモノだろう。
それは、細分化すればするほどリスクが高くなる。

リスクが高くなるから「じゃあやりません」で済む話ではないけどね

じゃあどんな話？

分割しないと共同開発できないのでは

どうやらすべったようだ

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

動けばいいコードって、使い捨てのサンプルコードのこと？

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

ｳﾀﾞｳﾀﾞ能書き垂れる奴がいっぱい釣れたwww

だろ？皆暇人なのよな！

たまの休みなんだから、何も考えずにバカな書き込みさせてくれ

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

動けばいいじゃん
と言っていいのはスキルが高いやつだけ

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

「動いたからいいじゃん」とか言っておいて自分の開発ＰＣでしか
動かないプログラムを書いちゃうズボラも多々いれば、
動作対象外の古いＯＳやどうなるかわからない未来のＯＳに対応
させようと無駄なコードをせっせこ書いちゃう自己満足もいるわけよ。

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

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

>>118
DigitalMarsC++にあるDesign by contract機能に、その関数の作成者の連絡先を含められるといいな。
負の数与えて実行時例外が出たら、「犯人はコイツだ！」って表示してくれるとか(´Д｀)

動けば良いじゃんと同じ発想を客の側から考えると安けりゃ良いじゃんって事になるんだよ
これが解らん奴は早い所マの仕事からは足を洗え
存在自体が迷惑だ

客がそう思ってるなら、なおさら余計な無駄なコストは省かなきゃやってられないだろ。馬鹿か？

>>121
で、韓国使え、中国使え、インド使えになったんだぞ

>>1はともすれば5分考えて始動し、丸一日でコーディングするタイプ
1時間思案してから始動して、3時間で完成させる代わりに

>>122
で、客のニーズの逆を行くわけか。おめでたいね。

実際コストは減っているのかと言えば、国内の開発会社の単価が下がっただけで工数ベースだとむしろ増えてるな
メンテナンスコストは更に増えていて、当初の開発コストを上回る修正費用が必要だったりしてメンテナンス案件はお蔵入りとかとか結構ある

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

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

>>118
そりゃコピペするほうが悪い。
いずれにせよ、コピペするような奴には品質期待できないけど。

１はばかだあ

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

おまいの力が必要だ！

本　日　22　時　開　始　！！！！！

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

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

そんなことしてる暇があったら仕事しろ

中国はピンキリだが、ハズレを引かなきゃ日本と変わらん。つか英語が出来るだけ上かも。
インドはヤバイ。日本で言えば旧帝院卒レベルが当たり前の世界。英語は言うに及ばず。
根拠無く中国・インドを馬鹿にしてる奴は馬鹿。

>>131
たしかに根拠無く馬鹿にしている奴は馬鹿だが、外国に外注出すのはいろいろと問題があるんだよ。
品質管理や工程管理･納期問題、文化の違いによる軋轢（期限守るって考えが無い国･地域が多い＿|￣|○）、意思決定の
遅延（必要な時にコミュニケーションがとれん）etc･･･

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

>>132
ハズレを引いたのか空想で語ってるのか知らんが、中国はハズレを引かなきゃ、と書いただろ。
うちの発注先は、やや遅れ気味だったが納期前にテストのために、
女の子も含めて２徹してあげてきた。もちろん品質も問題なかった。

＞もちろん品質も問題なかった

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

＞テストのために、女の子も含めて２徹
　　^^^^^^^^^^^^^^^^
ここ重要。
日本でもちんけなところはこんなことせずに「できました」とテスト削って出してくる。
単に日本というだけで他国より優秀と勘違いしてる底辺会社・PGは、現実見た方が良いよ。

骨抜きにされて遊びほうけて育った日本人より中国人のほうが優秀だよ。
そのうち絶対逆転不可能になった時に連中は豹変するよ。
所詮それまで下手に出ているだけ。それが分からんで中国人と友達になった気で居る
日本人のあまちゃんなことよ。
遊んで捨てられる女同然の浅はかさ。

＞そのうち絶対逆転不可能になった時に連中は豹変するよ
＞所詮それまで下手に出ているだけ。
その腹黒さが嫌なんだよ。誰もがそうだとは限らんが、
末永く付き合いたいかというと二の足踏む。

別に腹黒いのは中国人だけに限った話じゃないさ。
腹黒い連中と付き合うのがいやなら、PGなんて今すぐ辞めた方がいいぞ。

というか社会人を辞める必要があるな。

みんな不幸な世界に住んでるんだな。

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

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

>>135
日本が決定的に優れてるのは、客のために奉仕する精神だと思うね。
これは中国に限らず他の国にない利点。
サービス残業までやってるところは日本以外ではめったにないよ。

綺麗なソース、正しい構造の客観的評価基準が無い限り、
幾ら職業根性を掲げてもオナニーでしか無いわなぁ。

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

チーム内の8割が読んで理解できるソースだろ

そういうソースを書ける奴は2割もいないな。

客には動けばいいと思っているの？
勝手にこっちが思ってるだけなんじゃないか？

動けばいいじゃんと言っているやつがぐちゃぐちゃなソースを書く
程度ならまだいいが、そういうやつはたいていエラーや例外処理
が抜けまくったたまに以上停止するプログラムを量産し、しかも
ぐちゃぐちゃなのでデバッグに異常に時間が掛かり、売り物に
ならない。

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

>>141
いや、逆に東大生が言ってもかっこつけてるだけだとしか
思えないよ・・・

東大卒業のフリーターが言えばそれなりに説得力はある。

>>25
こいつ頭わるいな

>>151
「頭悪いからって言っていじめちゃいけないよ」ってこの間、
先生教えたでしょ

>>143
そうそう。

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

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

>>146
逆だろ。客はバグ無く動けばそれでいい。
設計厨やOO厨、デザパタ厨とかが、屁理屈付けて、
バグ無く動くプログラムに文句を付けて無駄なことをする。

「客は動けばいいと思ってる」ってのはダメPGの願望だろ。
客の品質に対する無知につけこんで、低品質のものを売りつけてるだけ。

「バグ無く」って書いてんだろうが。
客が「どうでもいいところに無理矢理デザパタ適用されたプログラム」を望んでると思ってるの？

バグがなくても重かったり操作が使い難いのは多い
直せといっても仕様だからと押し切られる
デザパタ使おうがどうしようが客は構わないけど
仕様のあいまいな部分をプログラマの都合で詰められるのはカンベンしてくれとは思う

このスレにリファクタリングという概念は無いわけですね

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

提案時にスパイラルモデルで提案しておくとウマー

>>159
スパイラルよりもウォータフォールでリリース２回に分割する方が楽

>>156
品質＝バグの有無
としか認識してないのか。やれやれだぜ…

普通の客ならば、
「TCO が低く、ちゃんと動作していれば、
どんなに汚いソースでもかまいません」
だと思う。
それ以上望むことなど何もない筈。

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

>>162
TCOが低くと自分でも言ってるじゃん
作り捨てでその後のメンテを考えないならOKだよ

>>162
今時そんな客ばっかじゃねーだろ。
結構うるさい所は多いぞ。

働けばいいじゃん。ｸﾞﾀﾞｸﾞﾀﾞ言い訳垂れてるニートって何なの？

>>160
それだと2回しか請求出来ないじゃん？

スレたい見てわろたｗｗｗｗｗｗｗｗｗ
ストレスためてるなみんなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

　　　　 ／￣￣￣￣ヽ
　　　／　　／￣＼　　ヽ
　　/　　 /　　　　　ヽ､､､ヽ
　　|　　/　　　ー 　　ー | |　　　チャッチャッチャラッチャ〜♪
　　|　　|　　　　・　　　・ | |
　　|　　|　　 ●　 ー　●| | 　　ストレス〜が♪
　　ゝ‐ｲ＼　　　　　　 ／ノ　　　チャッチャラッチャ〜♪
　 　 　　γ＜　ヽ / ＞'´
　　　　　/　,ｲ.三串三)　　　　　地球を駄目にす〜る♪
　　　 ／／ 　)__ノ,ヽ_(　　　　　チャッチャラッチャ〜♪
　　とcﾌ　　 ﾉ/＾＾/＾^＼
　　　　　 　/~/~ﾉ~~ i..~ ヽ
　　　　　,.ノ ノ〜/〜i〜j ヘ
　　　　　　　 ／`／ｰ|
　　　　　　／ ／　|　|
　　　　　<_ｨ　ヽ、 }　|
　　　　　 　ヽ,__ﾉ ( 　ヽ_
　　　　　　　　　　Llヽ､__)

動けばいいじゃん。






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

いや、正しく動かなきゃダメだろ。

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

営業や経理担当の立場からみると

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

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

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

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

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

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

ROI

保守業務を想定しる
汚いコード書くと保守･拡張･修正時に莫大なコストがかかるぞ
納品して終わりってんなら別だけどな

近いうちにSOX法対策や、不正使用電磁記録作成罪なんかの対策で動けばOKは許されなくなる

程度の問題だろ。
時間を掛ければそれだけ保守性が向上するってわけでもなし。

ﾏｼﾞﾚｽすると
カレー味のうんこに似てるな。
どんな食材使おうが結局その味さえ再現出来ればいいっていう発想が。

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

ちゃんと動くと美しく動くの違い、屁理屈とまっとうな理屈の違いについて。

綺麗なプログラムはバグも少ないよ

自分の場合は
「動くプログラム」
と
「正しいプログラム」
という具合に呼び分けてる

つーか>>1は完成したのを眺めて「なんだこれ？」って思わないの？
思わないならプログラム向いてない。パンチャーでもやってろ。

>>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++


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

>>177
それでちゃんと納期に間に合って黒字になれば文句はない。

>>183
「その後」は？

どうせ客はソースなんて見ない。

納得。

>>183
保守はどうするの？もしも運用してる時にテスト時に見逃した(汚いコード書くと可能性アップ)
致命的バグが顕在したら直さなきゃならないんだが

>>1を見ていればソフト開発で
できるやつとできないやつで生産性に１００倍差があることが良くわかる
１と１の擁護者が試行錯誤でボロボロのソフト書いて動いたと喜んでるよこで
デキルヤツはその１００の速さで組んでるんだろう

日曜ＰＧのオレの職場では、
新しく導入した事務ソフトの、
伝票印字位置を直してくれと、
営業マンが来た時に頼んだのに、
プログラムその場で開いても分からなかったらしく、
「自分では治せないから〜」と、言ったきり、全然直しに来やがらない。

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

>>189
へー、そういうものなんですね。
プログラムを理解するということはとても難しんですね。

>>182
すげー、その下のやつそれで動くのか
無駄な事覚えちまったよ糞野郎

とりあえず>>1には絶対俺の開発チームに入ってこないで欲しい。

>>182
お前、新人なめんなよ
分からなくて当たり前だろ
市ね

>動けばｲｲじゃん。ｳﾀﾞｳﾀﾞ能書き垂れる奴って何なの?

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

>>193
わからないならわからないでいいんだよ。
そんな感じのソースを書いて>>1みたいな態度でいるからだよ。

>動けばｲｲじゃん。ｳﾀﾞｳﾀﾞ能書き垂れる奴って何なの?
とか言う奴は，他人（過去の自分を含む）が書いたソースの保守をしたことがないんだろ

多分まだ保守っていう意味すらわかってないんだと思う

>>182
ｶｯｺなしでネストされると追いかけづらいよな。

>>1は間違ってない。プログラムなんか動けばいいんだよ。
どんなに汚いソースでもコンパイラのマイナーバージョンが上がると動かなくなっても関係ない。
完全に仕様どおりに動いて後からの仕様変更にも楽々対処できてバグがあっても即座に発見＆修正できて保守が楽なら何の問題もないよ。

小規模なシステムしか書いたことないひとはよくそうおっしゃいます

>>199 同意。後半部分がちゃんとできてるなら何の問題もないんだよな。

汚いソースは後半部分がちゃんとできてないことが多い

安定制や修正しやすさ、能率を考えて、
きっちりプログラムが動けばいいって考えが綺麗なプログラム
だと思うけどな。

デスマーチの真っ最中だと>>1の台詞が出る
しかし、それは異常な状態だからこそ出る台詞であって通常このような考えはするべきではない

動かないのはもっと良くない

>>199
>コンパイラのマイナーバージョンが上がると動かなくなっても
それは
>保守が楽
と言えるかどうか、微妙な線ではないかと。

>>199
それなら確かに問題はないと思う。
だが>>1は保守のことまで考えているとは思えないという方向で
話が進んでると思う。
どんなにソースが見づらくても
納期の時にさえちゃんと動いてれば問題はないっていう

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

要するに仕事で作ってるか趣味で作ってるかの違いでしょう

>>209
なるほど。
仕事に面白さを求めちゃいけないわけなのか。

そういう意味じゃないでしょう

いや、悪意ある受け取り方じゃないぞ。
斬新なことやりたいなら趣味でやれってことで納得した。

仕事で作るなら他人に迷惑掛けないように作れ

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

まとめよう

１）面白いか／面白くないかとか
たぶん両立不可能


２）斬新か／やっつけ仕事か
たぶん両立不可能


３）自分のやりたいようにやるか／迷惑かけないようにする
たぶん両立可能


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

>>214
＞１）と３）面白いものを他人に迷惑かけないように作ることは可能

は出来そうだが、

＞２）と３）斬新なものを他人に迷惑かけないように作ることは可能

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

＞誰でも書けるような何のヒネリもないロジックのほうが評判はいいらしい。
そんなのは当たり前。
１：枯れた技術のほうがバグも含めた不具合のパターンが分かっている
２：他の人も知っているパターンだと製作者≠保守担当者の場合でも保守しやすい。

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

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

限度があるけどな
10万件を超えるレコードをバブルソートする奴とか
スタックに8Mとる奴とか
ネタじゃなくて時々いるからな

>>203
テンプレ化出来るのは全部テンプレ化した方が能率上がるよ
確実に

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

まあ、プロジェクトの規約自体が無茶っていうのもあるからなぁ・・・。
どうしてもらちがあかないと見切ったら、俺も「動けばいいじゃん」モードに
入るよ。
それが自分の無知が原因だった場合は恥ずかしいけど、自分の決断の
結果だからね。

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

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

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

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

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

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

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

まあ、最初の躾が重要なんだよな
独学で覚えましたって奴は使えないことは無いけど変な癖がついてる奴が多すぎる

はっきり言える事、組織の中に入って職業PGになるのは辞めておこう
シェアウェア作家にでもなっておいた方がいいよ

>>1
てーか、保守性うんぬんおいとくとしても、
そんな自分の成長に繋がらないようなことばかっかやってて
つまんなくない？

仕事は、開発者の自己満ではなく、客の要望を満たすことだ。
自分の成長とは、自己満度が上がることではなく、
客の要望をより確実により早く実現できるようになることだ。

>>223
うん、だからそんな考えで仕事しててつまんなくね？

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

>>223
自己満に終始してる人多くない？


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

なんで？納品してユーザに評判がいいと聞けば、単純に嬉しいが。
「動けばｲｲ」という言い回しは釣りで、正確には
「動くことが目的であって、特定のやり方・作法というのは手段に過ぎない」と言うことだ。

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

>>226は>>224へのレス。

>>226
自分の場合、
「動けばｲｲ」思想でコーディングした前任者のせいで
今の要求を満たせずに悔しい思いをすることの方が多いな…

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

それが判断できないから自己満足だとか無駄だとしか思えないんだろ

>>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(目標達成能力またはそれを可能にする資源)：
再利用性や再利用可能なソース

動けばいいんだが
動かないからな

再利用なんてのは、なんとなく重要な気がするけど、実際のところは幻想でしかない。
本当に汎用に使える部分なんて、そんなにあるもんじゃない。
本当に再利用可能な部品として作るとの、その案件の要件を満たすのとでは、
掛かる工数が５倍くらい違う。５倍掛けてもどうせそれっきり。

>>1
多分、
ttp://japanese.joelonsoftware.com/Articles/GettingThingsDoneWhenYour.html
に書いてある戦略4をとられてるんだと思うよ。

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

本当に汎用の部品なら、Jakarta Commonsとか使った方が早いな。
でも、さらに、再利用のためのコーディングの自体すら、ただのこだわりっつーか目的化して、
ひたすら守るけど、結局出来るモノは再利用出来る形にすらなってなかったりする。

他の案件で部品として使うだけが再利用ではない。
機能追加、仕様変更が素直に出来ることも、
広い意味で既存コードの再利用だ。

顧客打ち合せで、
一応解ってるSEが「その変更なら、○○するだけだから」と受けてきて、
たしかに○○するだけで済むハズなのに、実際やってみたら動かない件。

>>219
俺も以前は全部当てはまってた。
現場でずっとしごかれてるうちに無意識にそれらをやらなくなってきたなぁ。
コード内のコメントってウザイの？

関数内のコメントは、
ブロックが何やってるかの説明なら、適切な名前の関数に切り出すべきだし、
切り出すほどでなければ、変数名を頼りに何やってるかコード読むだけで自明であるべき。
書く必要があるのは、特別に何か注意点があるときだけ。

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

＞修正履歴を入れたりとか（バージョン管理ツール使ってれば要らないけど）
→不要。早く石器時代から脱出してください。

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

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

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

変数名・関数名って、かなり問題だよ。

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

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

おまえらどう？

アメリカからの帰国子女だから英語で普通に会話も出来るよ

苦労して言われた通りにちゃんとした名前付けても、
何が良くなったのか全然実感がないんじゃ、被害者意識しか生まれないな。

Oh! eigo OK arune

>>242
たまーに外資の会社に訪問すると、社員が英語で会話しているよな。
俺は中学英語で単語とボディランゲージで乗り切るけどな。
そういう会社はインド人いっぱい。なかなか楽しい。

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

>>245
グローバルスコープの名前だったらそれでもOKだろうけど、
ソース中の名前ってその数倍以上の量があるだろ。それは？

>>246
確かに難しいな。自分の会社だと、基本的にローカルスコープの変数は
英数小文字+アンダーバー+ハイフンなら何でも良い事になっているな。
むしろコメントの方が大事。

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

>>241
15年くらい前のハードウェアのコードとか日本語で変数名付けていたから、いま
中国とかインドで流用して廉価版のハードウェアに移植しているんで、日本語
変数名で苦労しているよ。

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

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

変数にハイフンを使える言語ってなんだろう?

lispじゃね？

>>248
逆にその英語コメントが間違ってない確証はあるのか？

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

それハイフンか？

_がハイフンだったら、アンダーバーのほうはどの記号だろう?

>>252
すまん、アンダーバーとハイフン勘違いした。

ありえない

英語コメントうざー

>>249
COBOL もできるんじゃなかったっけ？

変数に + を使える言語ってなんだろう?

lispじゃね？

変数に@とか入れたいんだけど

ruby
perl

>>260
lisp

>>257
ハイフンは使えるけど、アンダーバーが使えない。

変数にωやμを使えれば楽しいな

VB

普通にシフトJIS通すコンパイラあるじゃん。

アラビア語を変数には出来まい

>>266
日本語でコーディングが実現できるな。

JavaとかC#とか普通に出来るだろ。
日本語でもアラビア語でも。

よめ

かけ

とまれ

VC++2005はUnicode通るからかなり奇抜な識別子が使えるな。

古代ギリシャ文字とか使えたら最高

日本語で変数名や関数名もいいけど、半角全角、ひらがなカタカナ漢字混じりってタイプミスの落しい穴が増えるだけだと思うけどね。

名前なんて自動補完に決ってるだろ。

俺のviだと自動補完してくれないんだけど？

>>273
渡邉クラスと渡邊クラスを間違えちゃったりするんだよね！

動けばイイじゃだめなんだ

>>273
そうだね、「落としい穴」なんて書く奴には難しいんだろうね。

動かないのより動くのがいい
動かせ動かせ
文句を言わずに動かせ動かせ

age

ネットワークプログラミングで、送受信のタイミングを合わせるのに、

Sleep(8000);

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

busy-loopじゃ無いんだからいいんじゃないの？
タイミングを合わせる必要性というのがいまいちわからないけど。

普通なにかの同期機構を使うけどな

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

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

>>1は勢いだけで行動する典型的な高卒か？

>>1みたいなのが姉歯ビルを設計するんだよな

>>1
世昭和生まれの高卒は死ね

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

>>287
他のプロセスに迷惑かけなきゃいいんでないの？

>>288
送受信の時間間隔が一定とは限らないので、

送信 → Sleep(8000); → 受信

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

>>289
受信データ無けりゃループでしょ。

>>290
↓こういうやつですか？

送信処理;

while(!dataAvailable) Sleep(0);

受信処理;

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

>>291
応答までのディレイがどのくらいか分ってるなら、先にその分Sleepしておいて、あとは精度をどれだけ取るかによってループ中のSleepの時間を設ければ良いじゃん。

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

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

ポーリングしたって良いじゃんｗ

>>292
どうもありがとうございます。よくわかりました。

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

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

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


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

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

>>294 は 281 です。

送信処理;

while(!dataAvailable) Sleep(1);

受信処理;


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

>>292 >>293 >>296 さん、ありがとうございます。
とりあえずやってみます。

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

わざわざ別スレッドに分離するなら非同期処理使っても同じことだと思うが…？

>>298
今は別スレッドで分離しない方向でやろうと思っています。
ポーリングか、あるいは ManualResetEvent あたりを使って。

おいおい、そのwhileで回すのがポーリングじゃねえのか？

>>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

>>1
アナル厨

>>279
動いてしまったばっかりに、俺も顧客も後始末で大損害さ。

>>1はまさに高卒や中卒や専門卒の考えそのもの。
浅はかでソフトウェア工学も何も知らないし

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

goto >>1

>>１
どっちも正しい。

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

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

丸付き文字をつかう奴が何を言おうが負け犬の遠吠えにしか聞こえない

今さらアジャイルｗｗｗｗｗｗｗｗ

>>307
まぁ修正を前提とした考え方の人なので、そうなんでしょう。

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

>>1
はアホである。

名前はまだない。

どこで生れたかとんと見当がつかぬ。

おれも最初は、真面目にopen-close-principalとか、よい作りを考えるようにしてたよ。

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

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

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

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

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

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

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

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

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

土方にエレガンスを期待してもね
高踏遊民を指くわえて見てなさい

まだやってたのかこのスレ
>>1ももういないんだし放っておけよ

なんだかんだ言って>>313が現実。
顧客が中身を判らんし判ろうともしない以上、安さがすべて。
これが資本主義。

間違ったときに手直ししさえ易ければ、あとは好きなように描けばいいんです。
好きなように描き続ければそれが自分の描き方になり
いつも同じ調子で描けるようになります。

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

日本語でおｋ

>>313　は良いつくりをすると工数がかかるって前提だが、ヘボいところは
倍の人月で、質の悪いシステムを作り上げたりする。

いらないコメントをやたら入れたがる上司。

仕事だと馬鹿相手だから馬鹿にならねえと続かんってこったろ。
馬鹿になれねえならオープンソースで趣味ってろって話だね。






ただ>>1は真性。

仕事でも馬鹿にならない、
それが俺

>>319
判ってないな。出来上がったものの質が悪くたって関係ないよ。
実際にその人月で作ったんなら、立派な「○人月のシステム」。
顧客は、同じ○人月がいくらで済んだか、しか判らない。＝単価が全て。

>313
そういう馬鹿が氾濫してるおかげでバグは減らない、クソ重い、ヘタレ仕様のソフトが大量に出回るわけだ。
せめてミッションクリティカルな用途のソフトではこういうのは止めてほしいんだが。

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

まあ実際開発始まったら○人月なんて工数もらえないわけで

いいとこ○人日

>>324
あんた学生だろ。
そんな一握りの例外を挙げても解決にならんよ。

>>324
笑いを提供してくれるｲｲ人だなぁ

>>324
就職活動大変だろうけど頑張ってくださいね＾＾；

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

>>325 ... >>328
それが現実だよな。
使う方はホントあほだよ。
ビッグカメラで、価値も判らんくせに特価の商品前にして
「高けー高けー」うるせえババアと栗卒。

テメエで作れカス。

まともに作るべきなのは自社パッケージとか自社システム。
請負の仕事なんて、
とにかく何でも良いからとりあえず動くの作って、ほい、が正しい。
Linusだって言ってるだろ？Keep it simple, stupid!　「動く」以上の余計なこと考えるな。

>>330
ﾜﾛﾀ

>>330
ところで、

"Keep it simple, stupid"

を、どう翻訳すれば、

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

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

>>332
そんなんじゃ、戸田奈津子にはなれないぜ？

自社パッケージだってまともに作られてないな。
今の職場。

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

それは可変長な配列の話？
固定長ならチェックしないなんてあり得ないと思うのだが。

>>335
固定長。

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

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

ソースレビューがなく、新人教育が適当なところはそんなもんなのかな？

教育再生

俺の配列は次長課長

動けばいい、と言うヤツはプログラマの適正がない

>>330
最近はそれで良いって思える様になって来た
そんなの奉行シリーズでもかえよ馬鹿ｗ
とか客に言ってみたくなる時もある。

>>341
真理

>>313=>>330=>>1

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

>>337
ソースレビューないね。
二回ほどしたこともあったけど、malloc()は使用禁止とか、fprintf()の次の行にはかならず
fflush()を入れるようにとか、そんな指摘ばっかり。

>>344
形骸化してるなぁ・・・でもそんなんばっかり＞＜

私はいかに美しいソースがかけるか、ということに
面白みを見出しているので擦れたいには同意しかねるな。
醍醐味の８割を捨てるようなもの。だ。

C++やP2P技術に卓越したプログラマの方々
宜しければ一度で良いので拝見して頂きたいです
当企画の成立には貴方の力が必要です

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

>>346
徹夜になるとそんな余裕もなくなるが
徹夜が続くとそんな気分になるね

>>348
お前は俺か

>>346
つまり、「趣味」ってこった。
仕事のパフォーマンスを、個人の趣味で落す奴はプロとは言えねぇな。

結局動くものをより短時間で作れるやつが一番偉い
特に誰にもまね出来ない物を作れるやつが最強

>>351
ずっとプロジェクトに残っているならそれでもいいが

>>350
バレなければダイジョブ
バグと一緒で

たとえば
char* buf = malloc( HOGE_SIZE );
memset( buf, 0, sizeof(buf) );
とか書かれると、やだな、って思う訳です。
sizeof(buf)って！

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

HOGE_SIZE が sizeof(buf) 未満だとアクセス違反じゃん

なかなか1未満の整数ってないよな

自分なら
char buf[ HOGE_SIZE ];
buf[0] = 0;
ですが

>>354
同意

>356
sizeof(buf[0])だと1かもしれんけどsizeof(buf)はもうちょっと大きいと思う

俺の予感では4くらいはありそうだ

おまえらレベル低すぎ。>>1が言ってるのは、
もっと処理をエレガントにするとか、抽象度を上げて再利用性を上げるとか、
そういうのは無駄って事だろ。バグはそれ以前の問題。

自分がめんどくさくないのがベスト。

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

再利用性って再利用したこともないくせにｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

むしろしまくりでんがな

コードを一から作ったりしないで
さっさと再利用して、エロサイト見て理性を保ってますが何か？

俺なら
char buf[HOGE_SIZE]="";

>>361

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

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

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

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

>具体的な再利用の当てがないと、いざ再利用する段階で使えないことが多い。
これは真理だな。
完全な工数の無駄遣いに終わる。

自分の書いた全てのコードが全てのプロジェクトで
全て再利用されているぞマジで。

有史以来世界中の全てのプログラムで再利用されたら認めてやろう。

キレイに書くと、書くのが遅くなるって言うヤツは、そもそもキレイなコードがかけてないんじゃないか?

>>350
違うだろ。
きれいなコード＝その後の工数が減る

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

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

＞メンテする人間が複数になる場合もあるのだから、
「場合もある」？
請負ならデフォだが。そして、そもそも請負前提の話なんだが。

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

可読性を上げているつもりで余計複雑にしてるのならいっぱい見る
例えばクラス階層が２重３重になってたり
関数を細かくわけすぎてこれまた２重３重のネストされてたり
やたらとファイルを分割しててファイル数だけは異様に多いのに中身は数行とかね
意味わかんねｗｗｗｗｗｗｗｗｗｗｗ

オブジェクト指向ってわざわざメンテナンスを困難にする思想のようにしか思えないなｗｗｗｗｗ

>>374
カプセル化ってそういうもんじゃねえ？
大体、そんな奥まで覗かないと流れ読めないの？
読めないなら設計が悪いかもね。

タイトルだけ見てカキコ
ほんとーにそー思ってるならこんなとこでｳﾀﾞｳﾀﾞ能書き垂れる必要ないんじゃね？

>>374
動けばいいじゃん

>>376
あと、変数名や関数名に制約があって可読性が無いのかも知れないぞ。
まるで逆コンパイルしたソースみたいに。

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

ユーティリティーっぽいのは慎重に作って
ツールっぽいのは好きなように作る

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

>>379
名前に愛着がないソースってすぐグレるよね

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

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

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

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

>>382
ええ話やなぁ

> 塩水
まで読んだ。

>>382
おまえは旧帝レベル以上だろう。現場は分数の足し算すら怪しい奴が半分近い。

個々のプログラマは所詮メソッド
メソッドが勝手にインスタンス化を判断するなんて、それは欠陥のある言語でしかないのだよ

>>385
お前、職場変えたほうがいいよ。

>>380
つ curl

動けばいいじゃんというやつにかぎって本番では動かないのは仕様ですか。

>>385
1/2 + 1/3 = 1/5
というのでも見たのか？！

その通り顧客が仕様をわかってないというのが大前提だね
だからxstreamなんてものが流行ったりする
どんだけ丁寧に書いていっても結局細部にまで後々変更が入る
それなら最初から動けばいいじゃんってのを作っとくのが最強

>>390
残念ながら、
1/2 + 1/3 = 2/5
なら見たことある…

ありえね

うそ！　違うの？

ベクトルならおｋ

>>373
>>374
なんかお話にならない、という感じだな。
やってる仕事の内容もレベルも低いということがすぐにわかった。

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

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

>>382
妹が失禁しながら気を失った・・・

まで読んだ。

>>382
ワッフル、ワッフル！

>>396
井の中の蛙はお前だろｗ
１００人月程度のシステムなら、それなりのPGで固めて恵まれた開発もできるかもな。
だが、１０００人月越えたシステムでは、そんな温室の論理は通用しないんだよ。

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

「チクショウ出しやがれクソッタレが！！」

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

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

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

「舐めやがって……オレに本気を出させたいようだな。良いだろう」
ｽﾞｱｯ！！

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

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

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

ん、俺ってもしかして天才?
とか
おお、これぞプロ中のプロ!!
とか

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

意図したとおりに動作する、これに尽きるものはない。
これが当たり前で、他のことに悩めるようになればプロだと自認できるのかも。
所詮は人間の決めた明示的なルールと数学的論理に従っているだけだ。

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

客は第一に(予算内で)動くモノを求める。
それに応えればあとは作る側で好き勝手に読みやすさとかメンテしやすさを追求すればよい。

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

出なければ金はださん！

>>403
ケチ

＞ちゃんと動く物
そのためにどれほどコストをかけるべきなのかを分かってないところは
安く請け負ってくれるところへ行く。
分かってるところはすでに決まった依頼先があるか社内にそういうチームがある。

>>404
１０万儲かるなら３万出してやる。
１０００万儲かるなら３００万出してやる。
１０億儲かるなら３億出してやると言っているんだよ。

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

むしろプロとしては個人的にこうした方が儲かるという仕様に変えるよりも
変だと思っても客の注文通り忠実に仕上げるのが正解だと思うな

>>407
客側の理論に対してそういった考えが正しいと思うんだ。
「忠実に仕上げる」作業に自慰行為は二の次なんだよな。
限られた時間と予算で最初に求めるべきは何かを考えないと。
これが最初の儲けだよ(客の脳内だけど)。

１０億の計画のためのシステムが３億で出来た。計画通り
１０億の儲けを出せば、３億引いても７億の儲け。

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

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

>>399
はぁ・・・
お話にならないな。尼はもう来ないでください。

↑テーブルの項目名を日本語にするやつｗ

>>410
あれは教科書が悪いんだ！

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

>>407
改変が歓迎されてるならかわいがられるな。

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

>＞設計をちゃんとしておけって言っただけなんだが？
>おまえが絶対ミスを犯さない完全無欠の天才ならそう言っていればいいよ。

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

>>413
納期まで半年あれば直してやるよ

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

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

そんなこと言ってるのはどこだよ？

漏れなんか、最初のスケジュール（工程表）どおりにいったことないよ
スケジュールどおりにいかない=>動作しなかった...orz
上も下者も、最初のスケジュールどおりに行かないのはわかってるから、まっ、そういうもんだで済ましてる。
自社製品開発だからこんな調子でもなんとかなるんだろうな

再利用したことないとか言うが、いつ使うかわからんわけで、備えあれば憂いなしというのもあるわけで。

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

綺麗にオブジェクト指向で書かれたコメントだらけのやたら長いだけのコードより
旧来の関数型で完結に少ないファイル数でまとめられたコードのほうがはるかに再利用性は高い
なぜなら、馬鹿でも理解できるから

ここまで綺麗に暗号化してるんだからその美しさを理解しろ、出来ないやつが馬鹿なんだ
とかいくら言ったところで世の中馬鹿しかいないのだ
お前も含めてな
余計なことはするな
仕様書がいくら綺麗にまとめられていても結局コードが理解できなければ意味がない
コードが理解できるものであることが何よりも重要なのだ
仮に仕様書がなくても、コードが仕様書になるものこそが最高のコードなのだ

自分は保守のことを考えて可読性の高いソース書くように心がけていた。
もちろん納期も守っていた。

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

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

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

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

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

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

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

オブジェクト指向って結構癖がある考え方だよな。そして構造化から来るとせっかくのクラスもただの特殊収納棚になってしまうことが多いし。
結局構造化のほうに慣れてる人が多い職場だとそっちのほうが効率いいし、逆も言えるということか。

道具ってのは上手く使ってこそだよ。
使い方を勉強汁。

綺麗に書くことにこだわって、
何でもかんでもJava
何でもかんでもC++
何でもかんでもVB.net
何でもかんでもhogehoge
とかバカなことをいわず、

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

>>419
＞旧来の関数型
＞旧来の関数型
＞旧来の関数型
＞旧来の関数型
＞旧来の関数型
＞旧来の関数型

>>421
なんだよ、起業しろよ。

起業してPG作業から離れて経営側に立つと、
気が付くと>>403になり、しまいには>>313の顧客と同じ事やってる、という罠。

長期間安定して動作する頑丈なコードより、
たまにバグが出るコード書いて
「連絡一本で現場に駆けつけて即対応！」
の方が商売になる罠。

limit of out sourcing...orz

こんなもん商売にしても無駄
小学生でもましなもん作れる

マって所詮詐欺師だと思う
ム技術なんて必要無い
必要なのは口だけ

>>424
んだな。
だがそのためには、事前にいろんな言語や技術について知っておかなきゃならない。
俺の経験でいうと汚いコード書くような奴は、普段勉強してないやつかまたはセンスが
ない奴のどっちかだ。
なのでどちらかというと、キレイなコードにこだわって仕事が遅いやつの方が
先々見込みがあるように思う。

>>432
でも、そいつがお前のコードに文句つけてきたりするんだぜ

>>433
そういうのはむしろ、対人スキルの範疇なんじゃね？

毎年予想外の法令改正に対応する現場じゃ、汚くても法令に間に合うプログラムと
そのプログラムを作るプログラマーだけが生き残る。これマジ。

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

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

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

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


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

>>435
どアホ、お前が楽できたのはそいつのコードのおかげだろ
先のやつがスパゲッティだったらそもそも来月までに解読できない。
そしてお前の後のやつにはお前のしわよせがくる。
曰く「前の人はすぐ書き換えて治してくれたんですけどね・・・」
それが、今の俺だから困る

最初っから「動けばいいじゃん」でつくってあったら、
アドホックな対応すら出来なかったんじゃないのかね。

可読性は保険みたいなものだ。
>>435の事例のようなときのためにある。

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

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

>>438
考えが浅すぎるよ。もっとかんがえろ。

可読性にコストを掛けても、顧客満足度は上がらない。
　→　可読性にコストを掛ける作業は自己満足のリソース浪費。つまり無駄。

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

時と場合による！

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

>>441
納品後も保守運用まで必ずセットで請ける会社なのか？
そうでなければ、保守コストを払うのは他の会社だ。

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

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



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

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

> 配列禁止とかループ禁止とか構造化禁止

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

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

可読性は普段は評価されないな

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

読めるレベルのコードを書くのにそんなに時間かかるのが
まずおかしいだろ。
むしろある程度読めるコードを保たないと、よけいしんどいし
時間もかかる。

評価されるとかされないとか、恥ずかしいヤツだな

つ　貴方の生産技術者としての良心

>>449
今切らしてる

いわゆる経済設計が横行しているのは日本にとってはまぁよくないけど
なかなかむずかしいね。規制できるもんでもないし

http://d.hatena.ne.jp/fromdusktildawn/20060118/1137558108

>>452
ありがと・・・

>>436
それを書いた製造元がさじ投げたんで、引き継いだだけ。
楽が出来るコーディングなら製造元が離すわけ無いだろｗ

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

あと言っておくとソースなんて１割も見てねぇよ。
デバッガで追いかけながらパッチ的な関数を埋め込んでいっただけ。

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

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

>>454-455
なんか、必死さが滲み出てるんだけど...、気のせいかな？ (w

>>455
下のほうでいい気になってりゃいいじゃん。
ちゃんと研鑽してる奴なら、お前レベルの考えることはみんな
とっくに通過してる地点だっつーの。

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

なんつーか、ソースコードってのはプログラマの成果物であると同時に作業場でもあるわけで。
机が散らかっているのが嫌なのと同じレベルで汚いソースも嫌だ。
限度を超えれば作業効率にも支障をきたすし。

自己満足の世界だな

ある程度は自己満ないとやってけないだろ。
動けばいいや主義もある意味自己満だ。

他人に強要しだしたらあぼーん

全てはオブジェクトである

動けばいいじゃんって言ってる奴は、簡潔なソース書けない奴の言い訳。
無理に綺麗にしようとしたら、余計にスパゲッティになるからそのままでいいよ。

プロである以上「ちゃんと動く」のが「最低ライン」だろ。
動けばいいじゃんと最低ラインで満足してるやつらのコードは
油断するとすぐ動かなくなって周りが迷惑するから、
もっと上のラインにしてくれ。

>>464
> プロである以上「ちゃんと動く」のが「最低ライン」だろ。

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

>465
そりゃ無理な相談じゃない?大量の過去の遺産(=互換性維持)と無茶な要求が常に飛び交ってるような状況じゃ。

つ「動かないコンピュータ」

斜め４５度の角度でチョップしてテレビの映りを回復する
そんな修理屋さんの話

ディフェンシブな開発 〜 SIビジネスの致命的欠陥
http://d.hatena.ne.jp/kuranuki/20060116/p1

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

スレタイを含め>>1の発言が、
公判中の堀江容疑者の発言にそっくりなのは気のせいだろうか。

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

堀江さんがいると聞いて駆けつけました。

いいじゃんいいじゃんプップクプー

>>470
ちゃんと作ると面倒なのか？
ちゃんと作ると説明が長くなるのか？

　なんか変じゃね？

要するに耐震偽装も真っ青の手抜き構築ということで…

直接人死にに関わるわけじゃないんだからノープロブレム

組み込みは人死ぬだろ。車とか。
金融とか勘定系だと自殺とかもあり得る。

>>475
010 システムトラブル発生
020 責任者更迭
030 場合によって
040 　自殺者発生
050 　労災裁判
060 　責任者更迭
070 　goto 030

医療系、軍事系、宇宙開発・・・

gamer「うわっ、バグかよ、マジ死ぬ・・・」

だからといってマが社会的に吊るし上げ喰らったという話は聞かないな
自分以外誰が死のうと知ったことか

>>480
要するに耐震偽装も真っ青の手抜き構築ということで…

>>477
この業界だと、020行でぬるぽが出そうな気がする。(w

>>482
だれがうまいこ（ｒｙ

一級建築士とプログラマでは
社会的な地位が違うだろが

バグのないプログラムはない
トラブルのないシステムもない
耐震偽造のない建物はある

＞耐震偽造のない建物はある
かといって将来どんな地震でも倒壊しないという保証は無い。

Windowsの場合に限るが、

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

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

>>1はきっと問題が起こったとき他人に責任押し付けるのが上手なんだろう。

>>487
じゃあ、Windowsの悪いところあげて。あと、君の言うアホじゃないOS

>>489
Windowsの悪いところ：重い
アホじゃないOS: BIOS
でFA？（ぇ

それ本気で言ってるの？

>>491
よく読めカス

>>490
ちょっとウケタ (w

>>490
warota 最高！！！

>>490
センスあるな（ｗ

>>490
ようわからんが嫉妬

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

つまり、派遣を使うのはよくない、

動けばいいじゃんと言う奴ほど、動けばいいじゃんというプログラムに出会ったとき文句を言うものだ

500

>>497
何十年も前から言われていることを
いまさら新しく発見したかのように宣伝するのはどうかと

て言うか、解決策がない奴の報告書なんて単なる批評家の戯言と同じだよ。

こんな奴にも、税金払ってるかと思うと情けなくなるよ。

大学の教授は一回なると不祥事でもない限りクビにならないからなぁ

>>502
いかにも報告書を読んだような口ぶりだけど実際に読んだの？
＃ 俺は読んでない。有料だし

一応読んだよ。

会社でその手の仕事してるから、この手の論文は大体目を通す。

まあ、このおやじの論文が特にひどいわけじゃないけど、
「いまさらそんなこと言うだけかよ」感はぬぐえない。

>>505
発言の内容がウーロン茶並みのコーヒーだな。

>>487
なんつーか　あれだな
お前みたいなスタンスのうんこが組み込まれてるって思うと
空しくなるほんと

知らないことは幸せなことなんだと今改めて知った。

>>497
>また活用済みの企業の方が、予定なしの企業よりも労働生産性が高くなっているという。

LOC で勘定して、だろ(w

>>509
だろうね。
生産性を定量化する確たる尺度も持たないのに。笑えるな。