読者です 読者をやめる 読者になる 読者になる

GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

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

システム開発 java ruby

RubyRails の導入・研修・各種コンサルをやっている Relevance, LLCという所のブログで、Ruby vs. Javaというシリーズ記事が公開されています。

お得意のテケト-和訳でご紹介。今日は#1だけ。これだけでも議論になるネタが豊富にありすぎる。

Ruby vs. Java Myth #1: Project Size

Myth #1: Ruby is suitable for small projects, and Java is better for large, complex projects.

This is exactly backwards. In fact, Java is more suitable for small, well-defined projects, while Ruby is better for large, complex, open-ended projects.

Rubyは小規模案件、Javaは大規模で複雑な案件に向いているという都市伝説は正反対だぞ、と言っています。で、その論拠が以下の通り。

Javaが小規模案件に合う理由

原文の紹介は省略します。興味のある方は、原文をご覧ください。どこの部分かすぐにおわかりになるかとおもいます。

  1. 小規模案件は適切なOSSライブラリを見出せば何もしなくてもいい。Javaはいっぱいライブラリあるし。なのでJava優位。
  2. 小規模案件は不意の仕様変更で予算がふっとんじゃう。JavaRubyよりも非常に良く知られているしドキュメント化されてる。なのでJava優位。
  3. 小規模案件は新しくスキルを獲得する時間も金もない。Javaなら既に色んなとこで知られている。なのでJava優位。

Rubyが大規模で複雑な案件に合う理由

これも原文の紹介は省略。

  1. 大規模案件は新たにやることがたくさんあるので、言語の生産性の方が多様なライブラリよりも重要。なのでRuby優位。
  2. 大規模案件は様々な仕様変更があるので、変化に対応するための最大の柔軟性が必要になる。なのでRuby優位。
  3. 大規模案件は再教育してペイするかも重要。この辺過小評価している会社もある。5週間のトレーニングを受けたら1年で10%以上生産性を向上すればペイできる。よってRuby優位

個人的なまとめ

これ、ネタ記事じゃないのか?大丈夫か?

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

仕様変更に対する柔軟性が求められるのは小規模だろうが大規模だろうが一緒。言語特性の柔軟性という意味ではRubyに一日の長があるけど、グタグタで硬直したコードを書いてしまうのは言語の問題ではなく設計の問題。ツールのせいじゃない。使い手のせい。

教育については、RubyはXXXな理由によりJavaよりも学習効率が高いのであるという話ならわかるんだけど、なんかそういう話でもないみたいだし。スキル獲得の金がないから新しい言語やフレームワークをやらないってのはありえなくて、小規模だから新たな技術を実践の場、つまりお金をもらって作るシステムの屋台骨として採用できるという事実もある。仮にトラブっても金銭的損失は少ないし、工期も自分が頑張ればどうとでも挽回できる。大規模案件は自分が頑張ってもどうにもならない。全体をコントロールできるようで全くコントロールできない。

なんというか、JavaRubyを引き合いにして「どういうサイズの案件に適しているか」という議論は不毛だと思う。

多くの会社のエンジニアと同調したりオフショアをしたりする場合は、必然的にエンジニア人口が多いJavaが選ばれるだろう。それにRubyのIDEってコンパイラと実行環境にちょっと色つけました、ぐらいのものでしかないはず。赤の他人と開発する場合はEclipseVisual Studioのような統合的開発環境が求められる。CheckStyleFindBugsのようなコード品質を高めるプラグインも豊富にあるJavaの開発環境は、かなり強力な選択肢であると思う。ヒトモノカネの集合によって決められるべき。

コメント欄のご紹介

本文よりもコメントのほうが面白い件。お時間が許す方は以下コメントをお楽しみください。

But I wonder how dynamic languages work on teams with many developers? (let’s say more than 15, in 3 remote offices)

With this in mind, I wonder about some of the flexibility of the “new wave” of dynamic languages. As team size grows, does the “wild frontier” of dynamic coolness pose a threat to good development principles (in a social context) ?

動的言語による"wild frontier"が人間系の側面から優良な開発規範・指針を脅かしてしまうんじゃないのか、ということを言っています。これは「プログラマには余計なことをさせたくないのである。均質、つまりみんなが同じやり方に従う方がよいのである」という主張です。でもこの主張って「やってはいけないこと」を防ぐために言われることなんだよね。DBのコネクション管理を個々のクラスでやっちゃうとか、StrutsのActionクラスに業務ロジック書くなとか、Handlerに例外を返す設計なのに勝手にcatchすんなとか。そういう負の要素を避けるための「自由の強制」なのであって、そこから先は自由であるべきだと思う。

Large project have to be scalable. Advantage: Java. Large project could be easily outsorced. Advantage: Java. Large projects must handle a lot of workload. Advantage: Java. Large projects should just work. Advantage: Java.

Javaのほうが大規模案件に向いているよというもの。スケールさせないといけないからJava優位。アウトソースしたいからJava優位。多くの仕事量を捌かないとといけないからJava優位。動かすことが重要*1だからJava優位。

特にスケールとアウトソースのダブルパンチが印象的。確かにこの2点においてはJava優位であると思う。

Large projects mean more less-than-average-quality developers (Ruby is much more difficult to learn for the average guy), need to have strong tool based refactoring support (not possible in Ruby), more compile time typechecking support (Ruby offers no compile time type checking), ability to construct rich domain models (Rails couples your persistence logic with domain model) and a rich set of libraries and frameworks (much more in Java than Ruby).

大規模案件とは「平均以下の開発者」を意味しているので、下駄を履かせることができるかどうかも考える必要がある、と。下駄としては、ツールベースの強力なリファクタリングのサポート、コンパイル時の型チェック、リッチなどメインモデル豊富なライブラリとフレームワークなんかがあるよ、と。リファクタリングについてはRubyでもサポートしてるよという指摘と、DSL書くのはそんなに難しくないよなんていう指摘もありました。

なんかこの流れに沿っていくと、Java is next COBOLなら、Ruby is next Javaって言われるのもそう遠くないのかな。

*1:should just workの訳し方が今ひとつ・・・