Re:Ruby vs Java 5本勝負〜その1〜

Ruby vs Java 5本勝負〜その1〜 - GoTheDistance

小規模案件はライブラリをがっちゃんこすればすぐできちゃうって、それネタもいい所だろ。Railsのようなフルスタックでかつ「この流れで開発するとノリノリでいけちゃうよ」ならば分かるけど、Javaの場合はライブラリを統合して使うコストってのがそれこそバカにならん。StrutsとSpringとHibernateってまったく別じゃんか。所謂このSSHで1人で全部開発できますっていうJavaエンジニアがどれだけいるのかと。

まったく同感。
さらに言えば、StrutsとSpringとHibernateのSHHが業界標準になっていて、
どのJava案件に行っても同じだよっていうのならともかく、
この3つの中でどこでも大体使ってるのってStrutsだけで他二つについては案件ごとにまず違うし、
元請のレベルによってはSI・AOPなどという高度なものは使わないし、
Strutsについてもカスタマイズという名のデチューンが施されたものを使うことになったりもします。
なので、フレームワークを統合する組み合わせ自体が無数に存在するので、
ある案件で苦労してフレームワークの統合に成功したからといって、次の案件で楽できる保証がないわけですよ。
ぶっちゃけて言えば「Java案件」って言葉はほとんど情報を持ってないよなあなどと。

グタグタで硬直したコードを書いてしまうのは言語の問題ではなく設計の問題。ツールのせいじゃない。使い手のせい。

これもほんとそう思います。


Webアプリケーションのプラットフォームとして凄くいいなあと思ったものがあったのですよ。
フルスタックで、フレームワーク同士の組み合わせは容易で、
リッチなIDEの力もあってマスタメンテの画面なら10分くらいで作れちゃって、
資料は元締めの会社が出している本やwebサイトで豊富に提供されていて(日本語が変なことも多いけど)、
吐き出されるHTMLがキモイとか、採用した時点でOSが特定のものに確定してしまうので
ライセンス料が馬鹿にならないだとか難点はあったものの、
作っている側としては(当時は)特に困らなかったので仕事がはかどるのなんのって。


何かというと.NETの2.0なんですが、それで私の参画した案件が一段落した頃、
隣の案件が火を噴いてるので消してくれと言われて行ってみれば、
同じASP.NET2.0で見るも無残なコードが大量に書き散らかされてたので軽く絶望してしまいました。
幸い小さな案件だったので、納期までに、バラバラ死体だったところをフランケンシュタインの怪物くらいには
リカバリできましたが、その後どうなったのかは知りません。
結局人間の不出来をツールでフォローするのには限度があるので、

大規模案件とは「平均以下の開発者」を意味しているので、下駄を履かせることができるかどうかも考える必要がある

じゃなくて、平均以上の開発者の生産性を高めて、システムの規模が大規模であっても
平均以下の開発者を使わないで済むくらいには少人数で開発が行えるような方向に、
ツールを進化させては行けないものなのかななどと思います。