【コラム】続々・「コードの見た目は後でいい」問題再び [13/01/02]

今回はメカAGさんのブログからご寄稿いただきました。

■続々・「コードの見た目は後でいい」問題再び

むかしの料理マンガ「庖丁人味平」にこんなエピソードがあったと思う。味平が修行を
積んでいるキッチンブルドック。そこのマスターはなかなか腕のいい料理人。

ところが親族に不幸があって急遽休みを取らなければならなくなった。で、その間暫定的に
キッチンブルドックを任された流れの料理人が曲者。

いきなり値段を下げたサービスメニューを出すという。安いから客はその料理を注文し、
売上はおおいに伸びた。しかも原価を抑えているから利益率も抜群。料理のことがよく
わからないオーナーは大喜び。ぜひこの調子でやってほしい、と。

「わかりました、でも同じメニューではなく違うメニューにしましょう」と。このメニュー
も大当たり。オーナーはもうこの暫定的な料理人に惚れ込んでしまい、もともマスターが
帰ってきた後も、この料理人の方に店を任せたいと言い出す。

　　　*　　　*　　　*

大ヒットにはカラクリがあって、サービスメニューは味がひどいのだ。2日目にメニューを
変えたのも、初日のメニューの味のひどさに懲りた客は二度と同じメニューを頼まないと
わかっていたから。

結局この暫定料理人は、もとのマスターが築いた客との信頼関係(この店は多少高くても
味で勝負する店だ)を食いつぶして、一時的に高い利益率を出していただけ。もとのマスター
への信頼が残っているうちは来店するが、そのうち呆れて客は離れていく。

逆に言えばカラクリがバレる前に店の実権を握るために、圧倒的なパフォーマンスを連発
したのだ。

ソース：ガジェット通信
http://getnews.jp/archives/281458

（つづく）

>>1のつづき

　　　*　　　*　　　*

マンガの読者なら、自分の店の首を自分で締めるようなこの店のオーナーを馬鹿だと思う
だろうけど、意外と現実では気づきにくいことってあるよね…。このマンガを読んだ子供の
頃は「ハハハ、こんなバカなオーナーいるわけないじゃん」と思ったが。

過去に蓄積された技術力や丁寧にコーディングされたプログラムは資産。資産を取り崩して
よいプログラムを生み出す一方で、資産を貯金していく。持続できるように出入のバランス
をとっているわけだ。

貯金を一気に下ろして使いきってしまえば、一時的にはそれまでよりも高いパフォーマンス
で製品を生み出すことは出来る。でもそのあとは一気にパフォーマンスが落ちてしまう。

こう書けば誰でも、そんな自分たちの首を自分で締めるような馬鹿なことはすまい、と思う
のだけど、やる人は時々いる。ソフト開発がよくわかっていない人間が、どこかから見つけ
てきた「優秀な人材」の中には、こういうタイプが紛れ込んでいることがある。

蓄積した資産を一気に使い切ることも、会社の戦略上必要なこともあるだろう。それ自体は
否定しない。しかしさほど必要もない状況で、自分の優秀さをアピールするだけのために、
そういうことをする人物は許しがたい。

交通事故だと思って耐えていれば、そのうち去っていくけどね。でも会社が被るダメージは
相当なもので、使いきった資産はまた蓄積すればいいのだけど、そういう混乱した状況に
反発して、もとからいた人材が辞めてしまうのは、なんとも。

ソフト開発がわかってない社長が「すぐに結果を出す優秀な人材」に目がくらむと、こう
いうこともあるという話。

　　　*　　　*　　　*

書いてて思ったのだが、なんか行政改革と同じかも。よく「現状にこんなに無駄がある」と
いう。でもその無駄を使いきってしまったら、そのあと持続できない。改革するのはいい
けど、持続できる形で改革しないと、一過性の改革では単に混乱を招いただけで終わってしまう。

参考サイト:「包丁人味平 1 (ジャンプコミックスデラックス) [単行本]」 牛 次郎(著),
ビッグ錠(イラスト) 『amazon』
http://www.amazon.co.jp/dp/4088581016/

執筆： この記事はメカAGさんのブログからご寄稿いただきました。

-以上-

できるだけシンプルに短いコードにすることに全身全霊を注いでるわ

我がコードは我流。我流は無形。故に誰にも読めぬ。

ちょっと何言ってんのかわかんない

そもそも料理人は修業だろ。
修行って、滝修行でもするのかよｗ

日本の企業なんて、ソフトウェアをスクラップアンドビルドで作っていて、
フレームワークやライブラリを蓄積していく文化が無い。アップルやGoogleに
ソフト開発が勝てないのはそれが原因やし。というか、プログラマ−なんて
派遣で、若くて単価の一番安いのから引っ張ってくる。

・経費を使わずに、利益アップ。
・連日の残業で、納期死守。
こんなことは継続できないってのは分かる。

コードの話は理解不能。

今話題のマクドナルドそっくりじゃんｗ

「誰にでも作れるおいしいプリンの作り方」レシピを書く→プリンアラモードも作れる→会社の資産になる

天才料理人を連れてくる→誰も真似できない→天才がやめたらプリンはもう作れない

顧客との伝令が一番エラソーにしてたりすると
優秀なプログラマが下っ端扱い。

マクドナルドの話かと思った

ソフトウェア開発は、チーム作業なんだから、「すぐに結果を出す優秀な人材」なんて生まれない。
カリスマ・アーキテクトなんてのは幻想。異端児はチームの流れを乱して成果につながらない。
個人作業だけの天才プログラマならいるかもしれないけど、チームでは使えない。

>>1
意味不明。日本語なの？

バカなくせにエラソーにしたがるやつほど上流工程に居るんだよな。

まず、コードの前に>>1の文章をどうにかしてくれ

＞結局この暫定料理人は、もとのマスターが築いた客との信頼関係(この店は多少高くても
＞味で勝負する店だ)を食いつぶして、一時的に高い利益率を出していただけ。もとのマスター
＞への信頼が残っているうちは来店するが、そのうち呆れて客は離れていく。

日銀引き受けもこれだな

一時的に量的緩和してもしばらくはもつが、
円の信頼が失せるまでそう時間がかからずインフレが暴走する

要するに技術を小出しにして長期的に利益を出してその間に更に技術を作っておく
ということだよね。ライバルとマラソンする訳だからでしょ。コードの世界なら
オリジナル最新テクも直ぐにリバースエンジニアリングされるんですよね。

「ソースコードが美しくなければならない」というのはどういう分野なんだろ。
どこまで行っても付加価値でしかないように思えるのだけど。

逆に言うと「美しいコード」が効力を発揮する場面があまり想像できない。
せいぜい普通で十分と言うか。

スクエアエニックスの事ですね、知ってますｗ

おいしいものは後で食べる主義大勝利みたいな

>>3
それ間違ってるから。
読みやすく再利用しやすいコードが良いコード。
シンプルに短くするのはコンパイラーのオプティマイザーがやるから。
制御系はまた別だが。

2ちゃんのソースコードなんてひろゆきでも書けるくらいなんだろ？

アベノミクスを揶揄してるんだろ？

誤解を生まない文章力が大切なことは分かった。

マシン・フレンドリーより読者フレンドリーな表現が大事ってことだね。

派遣を大量に使ってる会社はほとんどこのパターン、大手の社員は、納期と自分の手柄にすることだけを考え、そいつの上司も同程度のバカが多い、だから、派遣から、逃れられない、社員その物の劣化がひどすぎる。
こんなこと、何処の大手でも簡単に立ち上げることができる、今は中韓がそのパターンで日本を追い落としてる。

コードは誰にでもわかりやすくて冗長なぐらいのほうが
後から他人が手直ししやすい

丁寧に書いた方がいいとは限らない。
瞬間的に稼ぎまくって撤退したっていい。
同じ会社に一生勤めるとは限らないし、
仕事の性質だって、いろいろあるじゃん。
保守されないものに力を尽くすのは馬鹿げてる。

>>23
2chはひろゆきの乗っ取りだからコードは関係ない

直感で理解できるコンパクトなコードに
これでもかってぐらいのコメントが俺流。

>大ヒットにはカラクリがあって、サービスメニューは味がひどいのだ。
>2日目にメニューを変えたのも、初日のメニューの味のひどさに懲りた客は
>二度と同じメニューを頼まないとわかっていたから。

いや、味のひどさに懲りるくらいまずいなら
二日目は来店しないだろｗ

>>1
何これ？
ひょっとして文章なの？

しかもB+でさ

どうせアドビの天才職人に笑われるのが落だよね。
ソースコードの美しさによる利点とは要するに人間の理解の範囲で便利に
利用できることが条件なんじゃないですか、それをバイナリデータにすると
機械的にオプティマイザーが最適化するということかもしれない。
後々に人間のコード加工能力を最大限活かせる為の機能美。

組織としてソフトウェア開発に携わった経験がないと、>1の話は理解し難いわな。

いるよね。時々。
短く、行数を減らすことが目的になって血道あげる3みたいなのが。
で中身はすげぇわかりづらいコード。

言いたいことはわからんでもないけど
>>1はちょっと例えが悪くないか？

仕様書でももっとマシな文章が書かれている

>>1で重要なのは客だけだし、なぜか雇われ料理人が
レストランの将来やオーナーのアホさに配慮するのが当然、
みたいな話になってて不思議。

昔はメモリ1ビットは血の1ビットとか言われてたもんな

>>36
短いのは正義
まあ昔ベーマガにあったx行でゲームできますとかいうような
わけわからんやつだと論外だけど
短くわかりやすいだな

全体的に見てスピードの重要性が高い割合を
しめる作業なら当然やるしかないです、できればそういう適正のある人間にさせる。

>>10
「誰にでも作れるおいしいプリンの作り方」のレシピを売る→原価かからないからｳﾏｰ→瞬間最大利益を上げて会社ｳﾏｰ→会社解散して経営者と株主ｳﾏｰ→従業員解雇して炊き出しｳﾏｰ

ほこりがたまって火災の原因になるから綺麗にしとかないとね。

最近の例では「コンクリートから人へ」ですか？

>>39
中国人はそういう考え方をする　短期でどんどん転職していくし上昇志向が強いから
その場その場で結果を出すことに全力を尽くす　将来、その会社がどうなろうが知っ
たこっちゃない　使えるものがあればなんでも使う　妙な制限かけられて成果を出す
のを邪魔される方が理解できない

要するにひろゆきは重たいプログラマーに対して脳のワーキングメモリーを
増やして下さいよと言っているがそれは海馬の原理上とても難しい。
このへんが快楽主義者とは違う不器用な生き様。

分からないなら書き込むなよｗ

我が国の国政の事？

>>47
そこで活躍するのが、チャンク化のテクニック。
特定の分野ならば、大量に覚え処理できるようになる。

>>19
多人数で長期間使うコードなら大体どの分野でも重要だろ。
逆に言うと、一人で書く一回だけ動けばいいコードならどんなに汚いことしても構わん。

ルルーシュから一言お願いします。

一番大切なのは「誰が保守するか」を考えてコーディングすること。
専門卒の安価な新人達が保守するシステムなら、そいつらでも分かる作文のようなコードが正解。
でもプライドが邪魔してそんなコード書けるか、このバカヤロウ！！
葛藤

>>27
いいたいことはわからんでもないが、
文章の見た目は後でいい
とでも思っているのかよ。
「何が」逃れられない、のか
「何を」立ち上げることができる、のか
自分では分かっていることをちゃんと書かないから、
ひどい文章になっているぞ。

なに言いたいんだ？

「人に伝わる分かりやすい文章は後でいい」問題？

綺麗なコードは処理が遅い。

ひろゆきが言いたかったのは実行命令どうりには理解し処理してくれない日本人の
特性に対してイライラすることが多々あるからじゃない？単純にプログラム命令的
な内容で指示を与えても人によってそれぞれ勝手に解釈するのが面倒くさいとかで。
余計な解釈や説明をお前がしなくてもこっちはもっと全体を判断して言っているん
だという感覚。

ひどい文章だな。繋がりが意味不明

なんというか、古典的なバーク、ハイエク式の保守主義（漸進主義）の話だわな

わざわざこんな糞みたいな喩え話持ち出す必要ないだろ

たかが１回しか使わない、中身４行の関数はやめてくれ

なんだこの糞記事　

ふーん、「味平企業VSブラック企業」だってえ・・・？

比喩は、言いたい事と離れている方が面白いんだよ。日本語は、主語や目的語も省略してる方が美しい文章になる。教養や国語力がない奴は、ついていけないようだが。





要するに、料理人もプログラマーも同じ人間、やれば出来ると言いたいんだよ

短い、少ないは正義。コードは少なければ少ないほどバグが入り込む余地も少ない。
一つの関数にだらだらと手続き書かれてるとぞっとする。

>>4
ふむ…

>>13
すまん、欧米のチームと仕事すると、天才的プログラマ数人で、確実に成果物を上げてくる。
ただ、報酬も日本とは段違いだけど。

料理漫画界のお客はものすごく貪欲だからな
リアルのお客は評判を聞いてから動くのが殆どだから

美しいコードを書くほど
再利用がしやすく
作者の首が切りやすい。

これがすべて

ソニーの出井のはなしですねww

これがマンガ脳ってやつか？　なんでもマンガで例えるのやめてくんないかな。現実とマンガは違うんだよ。あほらし

>>44
束ねてもだめだよね。伸ばして使わないと火事になる。

わかりにくいっていうのが多いね
そんなにわかりにくいか？

＞逆に言えばカラクリがバレる前に店の実権を握るために、圧倒的なパフォーマンスを連発
＞したのだ。

ちょっと前の民主党だろ
出来ねー事ばかり並べる　

ソフト開発会社の社長の認識は、「見積り＝人数×日数」、「最初の10年は泥のように働け」だろ。

資産を切り崩すってそいつは一体具体的になにをしでかすんだよ。そこを説明しろよ。
料理の例とか全くいらねーだろ。

料理（と言うかマンガ）の例で切り崩してるのは「信用」だな。
ソフト会社の場合、切り崩す「資産」ってなんだろう？

コメントなんて飾りです
偉い人にはそれがわからんのですよ

性能も成果も、
小出しで長続きするように

いずれにしても、長期でも無けりゃ大した金額貰えない昨今じゃ
適当にやってさっさとバイバイするのが一番賢いかと
　

エコポイントや低金利政策と一緒だな。
将来の需要を根こそぎ奪い取って今だけ良く見せるアホ政策。

理解し易い
保守し易い
速い
単純
変更し易い
と色々有るが、同じコードでも局面と見方によりけりで絶対は無い。
真実は相対的と言うこと。

そもそも料理のことわかってない奴が店やったり、ソフト開発がわかってない奴が社長やったりしてる時点で
そんな奴の店や会社が潰れたり乗っ取られようとどうでもいい。身の程を知れと。

別に持ってる金を捨てろとは言わないから、バカはバカなりにそれを増やそうと思うな。
自覚して細々と暮らせば問題ない。ところが金持ってる奴ってのはその辺勘違いするみたいだね。

4 ：名刺は切らしておりまして：2013/01/06(日) 01:37:52.92 ID:7F+KEGfj
我がコードは我流。我流は無形。故に誰にも読めぬ。

5 ：名刺は切らしておりまして：2013/01/06(日) 01:37:58.77 ID:3GXH4mGa
ちょっと何言ってんのかわかんない


噴いた

>>3
わずか565バイトテトリスのプログラミング解説
ttp://zapanet.info/blog/item/1125

テトリスの動作サンプルはこちら
ttp://zapanet.info/blog/game/tetorisu.html

言いたい事は分かるが例えが下手

電源タップに繋がっているコードかと思った

短期的な利益に目がくらんで営業の言い分を上層部がごり押し、
無計画な仕様の追加変更の結果つぎはぎだらけのコードで作られたソフトの内部は破綻寸前、
という状況はままある

>>74
働いてる泥を見たことがない

綺麗なコードで書いてあれば
ドキュメントなんていらないと思うの

プログラマーっていうのは悲しい職業ってことかな。
目的のプログラムが出来上がってしまえば基本、用なし。
余命宣告されている患者みたいなもの。
プログラマーってどうすれば生き残れるのかな。

>>88
> 綺麗なコードで書いてあれば
> ドキュメントなんていらないと思うの

考え方をまとめる為にドキュメントを書く。特にコードを描かない人対策
きれいなコードがあればドキュメントなんて要らない、ってのはわかるが

ソースコードなんて素人にも書けるわけで
プロに必要なのはコードを読む技術

>>89
汚いプログラムを書いて自分しか保守できないようにすることだよ
インフラ系だとマジで多いわ

つまり、これ読んで反論したのか
http://careerhack.en-japan.com/report/detail/66

味平は包丁貴族と最後には麻薬を使っちゃうカレー将軍の印象が強かったな

>>92
そういう不毛な結論はやめようよ。
自分、プログラム専門じゃないけど、仕事が暇で暇でしょうがないので
プログラム書き始めて、余計に自分が暇になっちゃったよ。
プログラム書いて誰かにほめられるわけでも昇進するわけでもなく、
失敗したなあ、と思う。

自分にしか分からないようなコード書くと逃げられなくなるじゃないかｗ
だから俺は綺麗に書く

民主党政権の初期の話かと思った。

これ民主党を皮肉ったもんじゃないの？なんでみんなキレてんの？

最後の締めが行政改革というのが無理があるな・・
行為が多用過ぎて、この例を行政改革に当て嵌めるのが無理矢理すぎる
だから全体として胡散臭くなってしまう

埋蔵金とか逝って切り崩していたら何も残らなくなってしまったでｺﾞｻﾞﾙ
でもカネはいるからもっと切り崩せと言う・・・あれ？

>>5
民主党批判だと思う

>>7
余計な手間かけても、評価されないからしかたないな。

余計な手間かけるのだって、結局人件費だから。

まあ、下っ端レベルでは、できるだけ再利用しやすくシンプルなコードを心がけるしかないわな。
いくら給料もらえても、あとで自分の首を絞めかねないから。

15年前の自分のプログラムメンテする事になって当時の俺に感謝したな

>過去に蓄積された技術力や丁寧にコーディングされたプログラムは資産。資産を取り崩して
>よいプログラムを生み出す一方で、資産を貯金していく。持続できるように出入のバランス
>をとっているわけだ。
大規模になればなるほどプロジェクトは人の寄せ集めで、フレームワークを作りこんだり
業務のノウハウを蓄積していくって事ができないから、何時までたっても炎上デスマーチ
なんだよね。

コードを書くよりも、コメントをどう残していくかのほうが難しい

Google Map Androidがバージョンアップして
殆ど書き換えだわ
こういう時
元のソースの書き方がモノを言う

上司がピタゴラ装置みたいなコードをよしとするので2,3年従っていたけど、
頭悪くて話が通じないので無視して保守しやすいように書き換えたら残業時間が60hから0hになった

ほら、PHP。お前の事だよ。

中国製の電気製品のコードがしょぼいことを言ってる記事かと思って開いた

>>106
修正
Google Map Android → ×
Google Maps Android API → ○

コードって何？

何でもいいから動くように見える物を作れ
ってのが至上命題でしょ。

コードの見栄えとか、能力余ってる暇な連中のやる事。
プログラミング技法とか色々出て来ても
使えるライブラリを残す連中なんて殆んど居ない。

実際は、時間かけて、
最終仕様書であるプログラムの整備する事はとても大事だ。

読めないからと言って、蔑ろにする連中には平文の仕様書さえ何の価値が無い。

ん？いまのマックのはなし？












ハンバーガーのほうの

？？？
全然意味がわからない記事。
蓄積されたソースコードは使えるうちに使わないと数年で使えなくなるけどな。

もしかしてソースコードごと発注元に納品する仕事しかしてない人が書いたのか？

>>1
683 名前：名刺は切らしておりまして []： 2013/01/06(日) 02:21:29.98 ID:/f6LSnbB
12月はユーロ円転がせばよかったなあ。
まあユロドルでも230万勝てたけど。


684 名前：名刺は切らしておりまして []： 2013/01/06(日) 02:56:53.22 ID:lGqr/dis
１１月に７８円で＄を買ったが、９０円になれば売ります。
たった２ヶ月程で２５０万も儲かるなどここ数年無かったな。
１１０円台の時は、５万とか１０万とかは良くあったが、
今回は自民党に大感謝や、ありがとう安倍ちゃん。
本当に自民党に投票して良かったと思う。

他人の作ったソフトを大幅に仕様変更する仕事を受託したのだが、納期がむちゃくちゃ短い。
元々綺麗に作ってあったので読みやすく、とりあえず動くものなら既存ソースに手を加えるだけできる。
本当は設計からきちんとやりなおしたいのだが、それだと納期に間に合わない。
でも、そんな見積もりを出したら、その仕事を回してもらえないというジレンマ。

変なプライドさえなきゃ他のやつみたいに動けばいいコードかけるのにな
プライドって邪魔だよね

素人により素人の作ったWebアプリを改造しろと言われたぜ
もちろんあらゆる設計図はないぜ
テストデータもないぜ
すべてグローバル記述だぜ
暗号みたいな変数が数百個並んでるぜ
正体不明のファイルがいっぱいあるぜ
でも動いてるものがあるんだから改造なんかすぐだろうと上から言われるんだぜ

味平の漫画が古すぎる

今のスクエニ批判に近い
ＦＦのキャラが勢揃いしたキャラゲーだしてるけど
ＦＦ人気は凄い下がりはじめてるよねみたいな
ＦＦ13はやったら凄いクソだよねみたいな
ＦＦ14もかなり酷かったんだっけ？

コピペ蔓延でなんとかなってるんだからいいんじゃねーの

>>118
おれはタイ人が作ったプログラムの改造をたのまれたことがあるぜ。それはそれはひどいもんだったぜ。
まず関数という概念がないぜ。１つの関数が1000行とかあるぜ。if-elseの処理を全ての分岐ごとに
コピーしてるんだぜ。いじればいじるだけ壊れていくんだぜ。
少し進めたところで、これはどうにもならんという結論に達しこれは作り直すしかないぜ、と言ってやったぜ。
そしてタイ人の作ったコードを捨てて俺が全部書いてやったぜ。信頼性が全然違うぜ。

コードがメンテしやすい、読みやすい、シンプル、短い、美しい、
言い方はいろいろあるが、確かなのは、短いほど、分かりやすいほどバグは少ない。
理解できる奴が多いほど、レビューしやすいし、なおしやすい。
コードがないところにバグはない。読めないコードはバグの温床。
バグはゴキブリと同じで、1つ見つかったコードにはたくさんひそんでいる。

まず、似たような規模のオープンソースの公開されているソースをみて理解できるか
できなかったらソース語る資格ない
理解できるならのオープンソースと比べてコード記述がどのレベルか
何が問題か分かる。

>>121
テスト期間中、あまりにバグが連発するので、ざっとコードみたら、1関数が1万行超えてた。
1ブロックが3000行を超えてた。ブロックのネストが6段くらいだったかな？
唐突にbreakが出て来ても、どこに行くのか不明。
変数は使い回しがひどく、ブロックごとに役割が違うが、変わったかどうかよく分からない。
上司に報告したら、毎日2万行くらい地獄のコードレビュー週間になりました(;_;)

教訓：難しいところにまともな奴をつぎ込んで、まともにコード書けない奴同士でチームを組んじゃダメ。

保守・改修の入るコードはバカがメンテすると思って書かないといけない

末端の開発者でも保守性考えてプログラム書いてる奴なんてほとんどいない
新規開発はやりたがるけど改修案件は嫌がる奴が多い

要は動けばいい、動くもの作った俺すげえってタイプばっかり

>>58
そうなんだろうね、経験則から予防線を張っておくという。
しかし現実には「後で」はやらない事の方が多いから現場は混乱する。

ああ。コードね。

ケーブルの見た目の話だと思って、みんななんでプログラムの話してるのかわからなかったぜwww

最低限のコンピュータ・サイエンスの知識は持っていて欲しいよな。
そびえ立つクソが量産されたところで絶対に負債になるわ。

スマホ開発とかだとOSのAPI使用が変わって修正が必要になることなんていくらでもあるし。

だれのつらいい話だよ
さんぺーですか

そもそも会社の上級幹部に
プログラムに詳しい奴いるのかねー？

純然たり経営かせいぜい営業生まればっかじゃね？

>>4
不覚にもｗ

最近はコード汚いやっつけ仕事が多くなった
もちろん表面的には変わらないからクライアントは気づかないが、メンテにもリニューアルにもコスト倍くらいかかると思う
本当はブラッシュアップしたいが、なんせうちの会社10年前の半分以下しかいないから
もう、みんなやっつけが当たり前で売り上げさえあげれば社内での発言権高くなるみたいな
そんなことになってから仕事全然面白くない
息苦しくて本当やめたい

制御系のプログラムしか作ったことないから
普通のプログラムがどう作ってるのかしらないけど
構造的に分かりやすくて冗長性があるのが
後から一番手を入れたり修正しやすいね

>>126
自分で作ったものに責任もつ体制になっていないんだろうね。
残った奴がババを引くだけ。

言って良い？オープンソースありがとう。

オープンソースのおかげで、毎日どれだけ助かっている事か。

まさにいまの重電メーカだな

コンシューマーレベルのＯＳを４０年間
も維持させてきたアップル社は さいこう

コードがきれいにまとまってるとリビングがすっきり見えますよって多分完全に間違ってるよ俺何か致命的な勘違いしてるよ

一行毎にコメント書くなら、綺麗なコードを書いて欲しいね。

どうせ蓄積されている（と称する）コードに能書きやお品書きは付いてても評価は付いてないんしょ？
どうせWeb検索で行われてる参照とその評価によるランク付け（相対価値のランキング）
が出来るモノ書けるほどじゃない、つまり本格的に蓄積とその運用をしても大したモノじゃない、とか
どうせ書いても企業として効果があるほどの蓄積が無い、とかっしょ？
企業は良いモノに良い金を出すことに精出せばいいんじゃね
コード書くことが能って言うよりコード書いたり集めたりして　売　る　ことが能っしょ？

エクセルで書く詳細設計書
あれはダメだ
自然言語で書くことに専念するから思考が手続き型になる
しかも想定読者が設計者でも実装者でもない
記載内容は構文解析機の様な厳密さもない

テストファーストがきちんと守られていればこんな問題は出ない。
コードが汚くて問題だというのは、大抵コードに問題があるんじゃなくて開発の運用に問題がある。

>>83
sとかgでブロックがジャンプするのはバグ？

>>128
適当につないだタコ足上等のスパゲティ状態のまんまで上から壁張られると
後からじゃどうしようもなくなるもんな

ウチのアンテナ線がそうだった

>>143
テストコード書いている奴やテストコードそのものに問題がある場合、
ペアプログラミングで、ペアと対象コードをシャッフルするしかない。
まともな奴はほぼ全部のコードをなおす作業になり、苦痛でしかない。

>>143
テストファーストなんて動けばいいの代名詞みたいな開発手法では？

コメントってさぁ．．．コードの処理の説明、「データＡを変数Ｂに入れる」とか
書くやつ居るけど、コードの一つ一つの説明ではなくて、このコードの塊で何を
どうするのか事例レベルで書けっていう感じ。
「トルクテーブル参照のためアクセル開度と速度データをセット」みたいな。
前の職場に居たヘタレがそうしていた。自分の部下じゃないから放置していたけど
30過ぎであんなことしていたらすぐ仕事なくなる。
俺がやめるころにはもう新規処理は担当させてもらえてなかったら今は開発じゃ
ないだろうなぁ。テスト要員かな。南無。

>>141
言いたいことがよくわからんが、売るにしても継続的に原価が安い方がいいわけで。
それに、スピードが求められる昨今、コードがあれだと新しい機能を付け足すのに
時間がかかりすぎるんだわ。

>>147
テストファーストといえば、リファタリングも含むから。

>>142
あれより詳細な設計書かけるよ
英語だけどね

よめる？

>>7
単一民族国家と多国籍国家の違いだと聞いたことがある。
「言わなくても分かるだろ」が海外では通用しないと。

>>152
違う

日本はTBSの馬鹿筆頭に高校生でとまってるから
仕事のレベルも低いのでそうなる

おまえの読解力ゼロの間抜けな書き込みの数々こそが、>>1の主旨である

保守（漸進主義）の必要性を、皮肉にも如実に説明しているｗ

おまえらの読解力ゼロの間抜けな書き込みの数々こそが、>>1の主旨である

保守（漸進主義）の必要性を、皮肉にも如実に説明しているｗ

これだけ長々と行数かけて書く話か？

>>154
め

ソフトの品質はテストで決まるだよ
銅像や建物は見かけが立派であることが重要でした
ソフトの見かけなんて意味がないから
どういうテストを実施したかで決まる
コードが汚いのは使方込まれている証拠
１は素人だね

>>148
コードで書けることは、「読めるコード」で書け。
コードで書けないこと(設計選択の理由とか)はコメントで書け。

>コードの塊
その塊に意味があるなら、関数なり、メソッドなりにまとめろ。冗長なコメントは要らない。

ハードウェア信仰の強い昭和生まれのメーカーの年寄りが支配してる限り
iphoneのようなソフトウェアが主役の革新的な製品が生まれることはない
そのうち日本の製造業の最後の拠り所である自動車産業でも敗北を喫するだろう
現にgoogleはアメリカ大陸の東海岸から西海岸まで完全自動操縦する自動車を開発したという
ソフトウェアの重要性が増すにつれ日本のメーカーは窮地に追いやられるだろう
エコポイントやエコカー減税で古い体質の日本メーカーを救済するのではなく
情報科学出身の若者主導のベンチャー企業に税金を投資するべきだ

iphoneはまだ信用できないけどなあ
クックさんの販売力が’すごいんだって

人件費抑制のため偽装請負や特定派遣で若者を使い捨てにするのはいいかげんやめろ
東電の原発作業員の偽装請負は問題にされるのに大手メーカーに常駐して搾取されてる
ＩＴ技術者の偽装請負は何故問題にされないんだこの国将来のためソフトウェア技術者
を使い捨てにし続けるのはもういいかげんやめろ

コメントの基本は ５Ｗ１Ｈです
人間が理解するには５Ｗ１Ｈが必要です

なにげに深い

test

なに言ってるのか全然判らないw

>過去に蓄積された技術力や丁寧にコーディングされたプログラムは資産。資産を取り崩して
>よいプログラムを生み出す一方で、資産を貯金していく。持続できるように出入のバランス
>をとっているわけだ。

>貯金を一気に下ろして使いきってしまえば、一時的にはそれまでよりも高いパフォーマンス
>で製品を生み出すことは出来る。でもそのあとは一気にパフォーマンスが落ちてしまう。

コードを消費するってこと?
コードは食いもんじゃないよ?w

ソースが上手いと旨いな

>>165
> test

$ make test
ってかかなきゃw

>>158
コードってのは、システムを構築するための作業場なんだよ。
整理整頓されて、どこにどの工具があるのかすぐにわかる作業場と、
ぐちゃぐちゃでちょっと動くと足元に転がってるコードを引っ掛けてしまう
作業場のどちらが品質のいいモノが出来上がるかということ。

>>168
コの場を借りるけど，俺のやった仕事はTKの脳みそを借りてただけよ，それも女のほうな
たぶん

>>147
テストファーストは仕様を予めテストと言う形で定義する事を言うんだよ

綺麗なコードはしばしば管理者の手柄になって
プログラマの手柄にはあまりならないので、それを推進する努力はどこからも出てこない

これをどうにかするにはプログラマを管理者にすればいいのであるが
予算編成をたかがプログラマに握られて平然とできる経営者はどこにもいない

そもそも何で日本にgoogleやmicrosoftのような情報技術で急成長した企業が生まれてこないんだ
ハード系出身のロートルのおっさんにiphoneみたいな製品が思いつくわけ無いだろ
日本の大企業は全部倒産するべき偽装請負や特定派遣で人件費抑制してその上国から税金まで貰わないと
利益が出せないような企業に存在価値ないだろ若者主導のベンチャー企業に税金を投資するべき
年功序列でやってきただけの無能なハード系の年寄りはさっさと退場しろよマジ迷惑です

自分は若い頃仕事を終えて封鎖された会社に残されたことが多い
機密がどうたらだと

きまって年上のいまの俺の年齢の人が裏口を案内してくれて外に出られた

おはちがまわってきたのさ

東電の原発作業員の偽装請負は問題にされるのに
日本の大企業メーカーの偽装請負はなぜ問題にされないのか
人道に反する犯罪を長年にわたって続けてきた日本の大企業の年寄りは
全員地獄へ落ちるべき日本の将来や情報科出身の若者の将来を潰してまで
私利私欲に走ったメーカーの年寄りには必ず天罰が下るだろう

microsoftのような情報技術で急成長した企業
→BASICインタプリタで小金を稼いで、86-DOSを横流ししてIBMにとりいったIT老舗

>>176
よくわかる無駄のない説明だ

>>149
過去に新しい機能を付け足す仕様要求出してたのか、と
仕事受けた方にそういうコードに仕上げる時間を与えたのか、と
カネの出し渋りはまだ分かるが時間の出し渋りは仕事を出す側の先見性と仕事っぷりの問題
仕事受ける側の言い分も聞かないと、仕事出す側の時間の出し渋り、で無いかどうか分からないな

>結局この暫定料理人は、もとのマスターが築いた客との信頼関係(この店は多少高くても
>味で勝負する店だ)を食いつぶして、一時的に高い利益率を出していただけ。もとのマスター
>への信頼が残っているうちは来店するが、そのうち呆れて客は離れていく。

コードがどうのじゃなくて、ソニーが外資に乗っ取られて、このパターンやったな

気がつくと長大なループになっていた
これが数時間の格闘の結果なのだろうか
おれはゲームはやらないが 長い冒険物語みたいじゃないか
昔読んだハックベリを見習って、GOTOを使って脱出することにした
いい夢見せてもらったな,ア,バ,ヨ,

まあ日本企業で新興企業から伸びたのは、
ソフトバンク、楽天、ユニクロぐらいしか無いからな。

基本的に綺麗なコードは意味ないって言ってる人の中には
病的な超超超自中基地外が紛れ込んでるから注意したほうが良いよｗ

試しにじっくりと話を聞いてみな、
最初から最後まで
「僕の仕事はお前ら下膳の物が作った成果物を横取りして
　偉い人に期日通りに渡す仕事であるので
　下膳のの物である作り手は俺に迷惑がかからないように早くもってこい」
って話してるだけだよｗ

簡単に例えれば吉野家で牛丼頼んだら出てくるまで10分かかった事に対して
「早くしろよカス」って言ってるような感覚だな。
牛丼の作り方とか作業効率とか手法とかは知ったことではない
「俺は腹が減ってるんだ」っていう空腹感にたいして昆虫みたいな脊髄反射で文句言ってるだけｗ

こんなのに「牛丼はこうして作るべき」とか話し合おうとしても
感覚が違い過ぎて適当な生返事でこき下ろすしことしかしないみたいなｗ

日本の大企業のソフトウェア開発なんて人・月ベースで外部丸投げ前提だから
逆立ちしてもアメリカには勝てないだろ
コードの良し悪し以前だぜ

小説が好きな人は
長いコードを書いても綺麗だよね

ソフトバンク
→PCソフト卸を宣伝するために「Oh!PC」を発行してた若ハゲ社長の会社

研究部門にいるんで普段は「動けばいいや」とすげえ適当なコード書いてる
おかげで事業部と一緒に仕事するときは頭の切り替えが必要になる。

アメリカのハゲタカ金融機関のこと？

>>178
ソフトには実体がないから予算と納期を決める権限を持つ者は
要求がどのくらい大変なのか全くイメージできないんだよな

なので根拠もなく高い遅いと口癖のように繰り返す

あなただけ今晩は Irma la Douce 1963

　あのビリー・ワイルダー監督が「アパートの鍵 貸します」に引き続いて、再び同じコンビの
シャリー・マクレーンとジャック・レモンとで放ったロマンチック・コメディーです。
パリの娼婦街「カサノバ通り」が舞台です。　ここに配属になった新米警官ジャック・レモンが
ガサ入れを突如行ったものですから、客に上役警官が居て大騒ぎの末、警官をクビになりました。
しょげ返っているとき、ガサ入れの時知り合ったシャリー・マクレーンに出会います。
気のいい彼女にすっかり参ったジャック・レモンは今度は警官から娼婦のヒモとなるのです。

アパートの鍵 貸します The Apartment 1960

　ビリー・ワイルダー監督のコメディーです。　1960年第33回アカデミー賞の最優秀作品賞、
監督賞などを受賞しました。　ニュー・ヨークの保険会社に勤める独身のしがないサラリーマン
のジャック・レモンが上役に頼まれ自分のアパートの部屋を浮気の場として提供します。
そのために昇進するのですが、上役の相手というのがジャック・レモンの恋人、会社の
エレベータ・ガールのシャリー・マクレーンでした。　ロマンチック・コメディーですが、
一抹の寂しさが漂う傑作でした。

栄光への脱出 Exodus 1960

　シオニズムの流れの中で、第一次世界大戦後英国の統治下にあったパレスチナに、
ユダヤ人の移住が始まりました。　ユダヤ人は二千年前に国を失って世界中に散らばって
いたのです。　しかしこの地にはすでにセルジュク・トルコ、オスマン・トルコ以来の
アラブ人が住んでいました。　そのために両者の争いが絶えず生じていました。
第二次世界大戦後その衝突を避けるため英国は移住しようとするユダヤ人を捕らえては
キプロス島に収容していました。　そこからの脱出劇の映画です。

　パレスチナはやがて英国の手を離れ、国連の委任統治となり、分割案が出て、イスラエルが
誕生したのです。　これが今でも紛争の種になっているのです。　エルサレムは確かに大昔は
ユダヤ人の聖地でしたが、イスラム教徒の聖地でもあるのです。
ポール・ニューマンが主演でした。　バックに流れる音楽も良かったですね。

自民党批判？

ああ

ブラックカレーを作れば問題ない

「牛丼」は良かったwww
「牛丼」を産み出す側が「牛丼」がコピー生産される前の開発過程をも規格化したがってるのかwwwwww

コーディング規約ちゃんと作って、それに合致しないコードは受け付けない
仕組みを設ければいいだけの話だな。

糞な人間には糞な規約しか作れない
グーグルなりからパクって来ても糞な運用糞な改変

理系の書いたクソつまんねー文章でスレ立てんなよ

怖がりにもほどがある

IT土方の比率が結構高いというのは２ｃｈの構造的欠陥だなｗ

壁紙がそんなに気になるのか？鈴木雅之は
たよりにも和解になってない
原型をとどめてない破壊ばかりで

ブラックカレーさえ有れば客は離れないよ

味平というとブラックカレーだよなw

>>200
IT関連の人がこういったスレに集まりやすいってだけでないの？

美しさを追求するのはいいんだけど、美しさを求める規約によって、より論理的なロジックが組みづらくなる
綺麗で汎用的でその上遅い、というプログラムが出来たりするのがね
シェル＋専用ツールで流せば早いのに、わざわざ汎用的に書き直して無駄が増えてるとか

ルールは守るべき物だけど、ユーザ要件は必ずしも規約を守る事を期待しているのではなく
エンドユーザの業務に支障が出ない事だったりすると思うので
オナニーみたいな規約は正直一度見直した方がいいとは思う

コードの話についてはハードウェアやOSといったコードが乗っかるモノの変遷も加味しようぜ

>>205
遅いのは美しくないので、美しさを追求できていないんでしょう。
ほかは同意。

>>207
いやあ、美しさは十分だったよ、元々自分が作ったプログラムではなかったけど
引き継いでソースを眺めた感じでは、一切の無駄が無いのは確認たから

但しそのアプリに求められた仕様が「汎用的に使えるDBローダの代用品」で
テーブル変更によるリコンパイルはしたくない（この為テーブル情報は外部設定ファイルに持てとの事）
となると、どうしてもデータを読み込んで動的SQLを組み立てるような構造になるんだけど、とにかく遅い

そんなのDB付属のローダにやらせれば処理も早いし無駄な開発なんかしなくていいじゃんって思ったけど
どうやら開発したアプリ（と公認されたライブラリ）以外を呼び出してはいけませんという規約があるらしくてね
（基にしたシステムはローダを使ってたらしいけど、どういう政治力が働いたのかは知らない）

>>208
「開発したアプリ（と公認されたライブラリ）以外を呼び出してはいけませんという規約」
が美しさを追求できていませんねw

汎用的な仕様のスーパークラスに、サブクラスで実装するとか、
汎用的な仕様のインターフェースクラスに、実装クラスをデリゲートするとか、
美しいままなんとかする手段はありそうだけどなぁ。

>>209
なるほど、確かに規約が美しくないｗ
ちなみに開発言語はCだった為、クラスの概念が無かったので・・・

最終的には「これじゃ遅くて非現実的すぎるだろ」って事で
テスト実行中にそのプログラムをスケルトンに個別テーブル用プログラムとして暇つぶし的に作成
最初はチームのリーダーも渋ってたけど、処理時間が約7時間から15分と1/30になったって事で納得させ
マネージャに掛け合わせた末、採用、別の遅くなりそうなテーブルに対しても仕様から直す事に同意を貰った
結局の所規約までは踏み込めなかったけど

O/Rマッパー使って一見綺麗なコード糞杉。
DBアクセスに何時間かかるだよってぐらい処理が終わらない。
1000件ぐらいのテストデータなら差がたいして出ない分罪深い。
使い方に慣れてる人ならそんなこと無いけどさ…

美的感覚の無い奴の「美しい」なんて
せいぜい凡百のグラビアアイドル崇拝するレベルなわけでね
真の美しさは一般的にはグロかったりするもんだし
こう書くと「美しいコードは誰が見ても美しい」とか言う人いるだろうけどさ

そういや劇中でも終始、味平は葛藤してたな
「美味いって何だ？」とね

>>4

使わせて頂くw

>>1
>結局この暫定料理人は、もとのマスターが築いた客との信頼関係(この店は多少高くても
>味で勝負する店だ)を食いつぶして、一時的に高い利益率を出していただけ。もとのマスター
>への信頼が残っているうちは来店するが、そのうち呆れて客は離れていく。
これって、現状のソニーやパナソニック（旧松下電工・ナショナル）のブランド食いつぶしてる
老害経営者やリストラ上げて短期の業績回復してる外人経営者
を彷彿とさせる

鼻田香作のブラックカレーよりまし

コーディングに適用できる話なのか？　これ。
そのためにリファクタリングやら様々あるわけで・・・

>>212
芸術的なソースって確かにあるわな
こんなロジックでいいのか、と

で、それが必ずしも一般受けするようなコードとは限らないので
規約からすれば認められないコードだったりとか

ソースコードの品質が低いからってと保守を請け負うときの費用が高くなるわけじゃないから
品質なんか上げても無駄
そもそもこれ、自社開発やってる会社の例だよね
そういうところでもこのレベルなの？

自社開発でも、人員足りないときとか、ノウハウのない部分の開発とかは外部の人間入れないといけないからね。

こんなんビジネスのやり方次第だろ

ひろゆきなんかが得意とする娯楽系WEBサービスは、参入が容易な業界だし差別化の要は
新鮮なアイデアだから、とにかく他社がやってない新しい遊びを早くリリースして、
アーリアダプタを惹きつけて、顧客を囲い込んでいくことが必要となる
だからスピードが求められるし、「コードの見た目は後でいい」という話になる

それに対して俺が居る金融系業務アプリなんかだと、システムのライフサイクルが異常に長いし
法対応を除けば時間的制約も比較的緩い
だから数年後にメンテするであろう人の事も考えて、綺麗なコードを書く事が求められる

それだけの事だと思うけどね
重要視する事象が違うだけでみんな正しい事言ってるでしょ

今はアウトソーシングですよ。
ユーザー会社か元請けか中抜き会社が貪欲なんですよ。

jie丁とかjisαとか、グループ派遣会社とか、いろいろあるでしょ？