エンタープライズRuby

前回に続き、Enterprise Integration with Ruby。もうちょっと、考えてみました。

前回紹介した、Enterprise Integration with Ruby
ずいぶんいいかげんなエントリをしてしまったのを反省してますが、
でも、やっぱり考え込んでしまいます。今回は、そんな私の自問自答。

常識的な自分

Rubyのような動的型付けの言語で、企業システムをつくるのは、実際たいへんだろう。

Javaでは、たくさんの設計者やプログラマが分担して製造したモジュールを、最後にくっつけて、システムが完成する。最後に無事くっつくかどうかは、「(ルール・契約・コンパイラ)」が、保障する。
これが常識!

考え込む自分

これが常識だと思っていること自体が、もしかしたら古い考え方なのかもしれない。

そもそも、なんで大人数で分担しなければならなかったのか?と言えば、J2EEが難しいからだ。だとすれば、徹底的に開発を簡単にしたRailsの登場で、「そんな分担いらないじゃん」となってしまう。

よくよく考えてみれば、Railsでこのブログを作っているときは、「ビジネスロジックはSQLに委譲」したケースが多かった。その程度のロジックなら、あえて分業するまでもないことは確かだ。

常識的な自分

いやいや、そうはいっても、実際の企業システムは、もっと複雑なロジックやデータが入り組んでいて規模も大きい。いくら優秀なプログラマだとしても、数人で開発できるものではない。

だとすれば、やはり、ウォーターフォールとまではいかないまでも、確固たるフレームワーク上で、しかるべき分業をすべきだ。

考え込む自分

基幹システムのスクラッチ開発なんて時代おくれだ。業務パッケージが提供されてるのだから、馬鹿正直に同じような開発ばかりやってないで、そういうものを使うべきだ。

そしたら、巨大なシステム開発そのものがなくなっていく。今は、分業をどうするかなんてことにコストをかける時代ではないのかもしれない。

常識的な自分

スクラッチ開発が全くなくなるということはない。それに、Java業界では準備できてるかもしれないけど、Rubyの業務パッケージなんてないだろう。

ちょっとすっきりした自分

巨大な業務システムを動的型付け言語で作るなんて、無理だ。それはわかる。Rubyは、業務システムの分野なんて、そもそも狙っていない。

今の時代の「型」とは、どこのことを指しているのか?と言われれば、Web APIだ。Web APIが主戦場だとすれば、開発言語の型付け仕様なんて全く関係ない。

ああ、だから、この本のタイトルは、
  Enterprise Application with Ruby
を飛び越えて、
  Enterprise Integration with Ruby
なんじゃないのか?

さらに考え込む自分

でも、ネクタイ締めたおじさんが、会議室でRubyのことしゃべってるなんて・・・。想像できねーなー・・・・(泣。

もう考えるのやめた。
知り合いに、Rubyがだーいすきなカリスマエンタープライズエンジニアがいるので、彼に教えてもらうことにします。


コメント

コメントしてください

closed.