これ読みました。
 |
JavaからRubyへ ―マネージャのための実践移行ガイド 角谷 信太郎 オライリー・ジャパン 2007-04-21 |
誤字が多いのが気になりますが、大変面白かったです。
いやー、ほんと、システム開発っていろいろあって面白い。
一体何が真実なんだか。
ま、なんにせよ、選択肢は複数あった方が良い。
テクノロジーでは解決できない問題もたくさんあるだろうけど。
Martin Fowler氏へのインタビューより引用。
Q : Javaはどこで道を誤ったのでしょうか？
Java界は、スキルの未熟な開発者にもシステムを台無しにされないようにすることに力点を置きすぎています。結果から言えば、この考えは破綻しています。銃で自分の足を打ち抜かないようにするという考え方は魅力的ですが、現実に私たちが目にしているものは理想からは程遠いものです。あまりにも複雑でひどいJavaアプリがそこら中に転がっています。全体的に、Javaは複雑すぎるのです。「銀の弾丸はない」 [略] というのは、本質的複雑性と偶発的複雑性とを区別するということです。たとえば、給与支払システムの開発では、給与支払の業務ルールは本誌的な複雑性です。しかし、Javaの労力のほとんどを占めているのは偶発的複雑性です。EJBの大失敗はこの最たる例です。EJBは、それ自体がとんでもなく複雑なフレームワークであるばかりでなく、私たちが経験してきたアプリケーションのほとんどにとって複雑すぎます。SpringとHibernateはEJBに比べれば格段に進歩していますが、それでもまだ、偶発的複雑性に満ち満ちている印象を拭えません。
– p.28
「本質的複雑性」と「偶発的複雑性」っていうのは良い表現だなぁ。
プログラマって、複雑なものに惹かれる本能を持ってる気がする。
「こんな複雑なことをやってのけちゃう俺すげー！」みたいな。
それがバッドノウハウにつながったりもする。
あとは、焦り。
「この新技術をマスターしないと時代に乗り遅れる！」みたいな。
そういうのが問題を生んだりする。
以下、その他諸々コピペ。
EJBはだんだん良くはなっていますが、それでもまだ難しすぎます。 [略] EJBは象を撃つ大砲のなかでも最高級品なのです。しかし、筆者の知るEJB開発者のほとんどは、EJBをWebインターフェイスを備えたリレーショナルデータベースアプリケーションの開発に使っています。どんなに贔屓目に見ても、EJBに適しているのは、分散トランザクションのような高度な機能が要求されるニッチな分野です。
– p.30
[略] Javaで言語を拡張するために（Dependency Injection やアスペクト思考プログラミングといったバズワードや、XMLベースの設定を利用するような）厄介で複雑な方式が必要不可欠なのは、動的言語のような方式ではJavaの拡張が難しいからです。
– p.52
要は、DIって「苦肉の策」的なものなんじゃないかなぁ。
Javaの良くないところは、もっと素朴なテクノロジを使うべきユーザに対しても、エンタープライズフレームワークを使うように働きかけていることです。
– p.60
Javaは言語の選択肢としては安全かもしれません。しかし、正しいフレームワークの選定は、たとえ専門家であっても難しいのです。
– p.68
確かに、Javaにおいてはフレームワークの選択は非常に難しい。
ていうか、RubyがJavaに取って代わるかはどうでもよく、現時点でのJavaの問題点をきちんと把握しておくことが重要だな、と思った次第。
