アカウント名:
パスワード:
デカくて遅いけど便利なプログラミング言語と、フレームワーク的なものの普及によって、プログラミングに関しては従来ほど経験の価値がなくなっちゃったのさ。だから青二才が見よう見まねで書いたってとりあえずは動く。
プログラミング経験の市場価値が低下している一方で、プロジェクトマネジメント面では開発現場ほどの進歩がなく、いまだ経験が（というかKKDか）幅を効かせてるから、ある程度年季の入ったプログラマはそっちに行くことを求められてる。
結局さ、僕らが追い求めてきた美しいコード、効率的なアルゴリズム等々、そんなようなものは時代遅れになっちゃったのさ。
自動車のトランスミッションだってマニュアルからオートマになっちゃったじゃん。僕らはマニュアルなのですよ。たぶん。
デカくて遅いけど便利なプログラミング言語は、ハードウェアが速くなったおかげで、デカいけど速くて便利なプログラミング言語になっちゃったい。
案外、美しいコードで１０年持たせるよりも、フレームワーク上で青二才が作ったコードを１年ごとにとっかえひっかえする方が、経済的なんだろう。
PMは人身御供の別名なので、年季の入ったプログラマはそこで成仏させられる。
ということで、生き残った（のか？）僕らは、マニュアルミッションの自動車というよりは、蒸気機関車という方が近いかも。
＃ リストラをくぐり抜けて会社に逝き残っている者は、自らを「居残り組」と言っている今日この頃。
＞案外、美しいコードで１０年持たせるよりも、フレームワーク上で青二才が作ったコードを１年ごとにとっかえひっかえする方が、経済的なんだろう。さすがにそれはない。
単にマネージャー層に10年先を見通す能力がないだけで、毎年作り直してたら、いくら金があっても足りないよ。＃ていうか、10年もつビジネスが案外無かったりして。
誤：美しいコードで１０年持たせるよりも～経済的だ。正：最初はお金がないので行き当たりばったりで作った。 それでも美しいコードで１０年持たせるよりも～経済的だと思いたかった。（けど現実は違った。）
超ショボいサイトの中には、青二才に3ヶ月で作らせたゴミコードの山というのはあるかも。ただし、そういうサイトはゴミが年々積み重なっていくのみで、原則作り直しはしない。＞＞古い言語仕様、古いフレームワークのまま、年々屋根の上に屋根が重なっていく…のように。。。
そうでない会社だと、自分たちが作った技術的負債の重みでつぶれかけてました。
＞＞自動車のトランスミッションだってマニュアルからオートマになっちゃったじゃん。僕らはマニュアルなのですよ。たぶん。「運転手」としてはマニュアルよりオートマの方が簡単だけど、「開発者」としてはマニュアルよりオートマの方が難しくなってるだろ。
プログラマは後者なんだな。SIビジネスは前者かもしれんけど。
そんなことはないぞ。いまだ生きてるCOBOLの恐竜とかさ。善し悪しは別として。あるいは数百億円投じて作られる、いわゆる基幹システムとかさ。想定する耐用年数は10年どころじゃないぞ。SAPとかEBSなんてのは、フルスクラッチなら1000億のところ、半額で作れますみたいなもんでさ。
とはいえ多くの業務アプリケーションが設計段階において耐用年数をさして考慮していないのも事実だ。想定耐用年数＝使える限りみたいな。そんでもって将来の拡張を考慮した設計をしていない、もっといえばその能力がないのも事実だ。そんなことを深く考えるより、お客さんのお好みが安くて早い吉野家みたいなもんになっちゃってさ。僕らはつゆだくだのネギ抜きだのキムチ乗せだの、ほんのわずかなバリエーションはあれど、本質的にはくだらん物を量産する存在になっちまったわけだ。けどおかげさまで注文は増えたからなんとか食っていける。なんとかね。
言っとくけど、僕はそんなの良いとなんて思ってないぜ。
>＞案外、美しいコードで１０年持たせるよりも、フレームワーク上で青二才が作ったコードを１年ごとにとっかえひっかえする方が、経済的なんだろう。>さすがにそれはない。
それはある。ある種のweb関連のアプリケーションなどには数年で作り直す使い捨てに近いものがある。作り直すのは経済的な問題じゃなくて、実質的にはLook&FeelやUIの変更など見た目の違いを作るためだけだが。（その下のレイヤーはかっちり作るが、上っ面の部分はとりあえず作って動かして手直しをする）
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
逆だな (スコア:1)
デカくて遅いけど便利なプログラミング言語と、フレームワーク的なものの普及によって、プログラミングに関しては従来ほど経験の価値がなくなっちゃったのさ。だから青二才が見よう見まねで書いたってとりあえずは動く。
プログラミング経験の市場価値が低下している一方で、プロジェクトマネジメント面では開発現場ほどの進歩がなく、いまだ経験が（というかKKDか）幅を効かせてるから、ある程度年季の入ったプログラマはそっちに行くことを求められてる。
結局さ、僕らが追い求めてきた美しいコード、効率的なアルゴリズム等々、そんなようなものは時代遅れになっちゃったのさ。
自動車のトランスミッションだってマニュアルからオートマになっちゃったじゃん。僕らはマニュアルなのですよ。たぶん。
Re: (スコア:1)
デカくて遅いけど便利なプログラミング言語は、ハードウェアが速くなったおかげで、デカいけど速くて便利なプログラミング言語になっちゃったい。
案外、美しいコードで１０年持たせるよりも、フレームワーク上で青二才が作ったコードを１年ごとにとっかえひっかえする方が、経済的なんだろう。
PMは人身御供の別名なので、年季の入ったプログラマはそこで成仏させられる。
ということで、生き残った（のか？）僕らは、マニュアルミッションの自動車というよりは、蒸気機関車という方が近いかも。
＃ リストラをくぐり抜けて会社に逝き残っている者は、自らを「居残り組」と言っている今日この頃。
Re:逆だな (スコア:1)
＞案外、美しいコードで１０年持たせるよりも、フレームワーク上で青二才が作ったコードを１年ごとにとっかえひっかえする方が、経済的なんだろう。
さすがにそれはない。
単にマネージャー層に10年先を見通す能力がないだけで、
毎年作り直してたら、いくら金があっても足りないよ。
＃ていうか、10年もつビジネスが案外無かったりして。
誤：美しいコードで１０年持たせるよりも～経済的だ。
正：最初はお金がないので行き当たりばったりで作った。
それでも美しいコードで１０年持たせるよりも～経済的だと思いたかった。（けど現実は違った。）
超ショボいサイトの中には、青二才に3ヶ月で作らせたゴミコードの山というのはあるかも。
ただし、そういうサイトはゴミが年々積み重なっていくのみで、原則作り直しはしない。
＞＞古い言語仕様、古いフレームワークのまま、年々屋根の上に屋根が重なっていく…
のように。。。
そうでない会社だと、自分たちが作った技術的負債の重みでつぶれかけてました。
＞＞自動車のトランスミッションだってマニュアルからオートマになっちゃったじゃん。僕らはマニュアルなのですよ。たぶん。
「運転手」としてはマニュアルよりオートマの方が簡単だけど、
「開発者」としてはマニュアルよりオートマの方が難しくなってるだろ。
プログラマは後者なんだな。SIビジネスは前者かもしれんけど。
Re: (スコア:0)
10年持つようなシステムは開発コストがかかりすぎて、作ってられないだろう。もし作ったとしても、高性能・高価格路線で失敗した、日本の半導体産業のようになってしまうと思う。
Re:逆だな (スコア:1)
そんなことはないぞ。
いまだ生きてるCOBOLの恐竜とかさ。善し悪しは別として。
あるいは数百億円投じて作られる、いわゆる基幹システムとかさ。想定する耐用年数は10年どころじゃないぞ。SAPとかEBSなんてのは、フルスクラッチなら1000億のところ、半額で作れますみたいなもんでさ。
とはいえ多くの業務アプリケーションが設計段階において耐用年数をさして考慮していないのも事実だ。想定耐用年数＝使える限りみたいな。
そんでもって将来の拡張を考慮した設計をしていない、もっといえばその能力がないのも事実だ。
そんなことを深く考えるより、お客さんのお好みが安くて早い吉野家みたいなもんになっちゃってさ。
僕らはつゆだくだのネギ抜きだのキムチ乗せだの、ほんのわずかなバリエーションはあれど、本質的にはくだらん物を量産する存在になっちまったわけだ。けどおかげさまで注文は増えたからなんとか食っていける。なんとかね。
言っとくけど、僕はそんなの良いとなんて思ってないぜ。
Re: (スコア:0)
>＞案外、美しいコードで１０年持たせるよりも、フレームワーク上で青二才が作ったコードを１年ごとにとっかえひっかえする方が、経済的なんだろう。
>さすがにそれはない。
それはある。
ある種のweb関連のアプリケーションなどには数年で作り直す使い捨てに近いものがある。
作り直すのは経済的な問題じゃなくて、実質的にはLook&FeelやUIの変更など見た目の違いを作るためだけだが。
（その下のレイヤーはかっちり作るが、上っ面の部分はとりあえず作って動かして手直しをする）