Hatena::ブログ(Diary)

moroの日記 このページをアンテナに追加 RSSフィード

2006-06-19

Railsの生産性とそれで提供したい価値

昨晩の続き。じゃあ仕切り直してなんでRailsって生産性が高いっていうの?というお話です。

DB設計はやっぱり必要で、UIも考えなくちゃいけないうえ、自動生成は客寄せで、ワークフローエンジンもないけれども、Railsの強みって言うのは一つはまさにRubyで書けるということ。二つ目はシンプル哲学に基づいたフルスタックフレームワークいまある、ということ。

言語重要

えっと、まず予防線を。JavaはダメでRuby最高、といいたいわけではなく。

Railsの強みはRubyのシンタックスの柔軟さから来るDSLっぽい記法や、Rubyの動的な側面から来る徹底的な(自動生成じゃない部分、手動で書くべきロジックの)コードの削減だったりするんじゃないかと。ブロックと遅延評価だったり、括弧が省略できることであったり、クラスインスタンスであったり動的にメソッドが定義できたり、っていうのはすべて書きたいコードに直接的にたどり着くための手段です。

羽生さんのロングテール時代のSIというエントリには完全に同意します。私もSIとしてやっていくんであればこういう方向を目指したいと思いますし、それで世の中をハッピーな方向に廻す、というのが目指すべき方向性であると思います。

で、そのときの原価削減というかQCDを満足させるためには、できるだけコードを書かないようにすること、非本質的なロジックで煩わされないことが重要で、そのときにRuby言語としてのよさやRailsの厚いフレームワーク層が役立つんじゃないでしょうか。Write less Software.を実現できる言語&フレームワークですよ。

エンプラ言語としての成熟という面ではたしかにRubyはまだまだ実績は少ないかもしれませんが、速いサイクルでより安くお客さまへシステムを届けるという目的のもと、少なくとも当面はRubyRailsが最適な落としどころだと思ってます。ってこれじゃRailsを褒めてるというよりかは決意表明のような感じですが。

フルスタックフレームワークであること

Railsのよさのもう一つは極端過ぎるくらいに密に結合したさまざまなコンポーネント(ActiveRecordとかscript.acoulo.usを取り込んでたりとか)を含んだフルスタックフレームワークだということです。UIからビジネスロジックまでいろんなボキャブラリがあるために、簡単なコードでそれなりのUIが簡単に作れてしまいます*1

また、コードジェネレーションの話とも関係しますが、アプリケーションの雛型を生成した時点でユニットテスト結合テストのためのコードも生成されます。

フレームワーク側が用意する至れり尽くせりによってプログラマ側に「オレってすげー」感が産まれること、それがRailsの生産性が高い(少なくとも人気がある)ところの理由じゃないでしょうか。

まとめると

Railsの生産性の高さは、少ないコードの記述リッチアプリケーションができること、これが大きいのかと感じています。

コードの記述量が少ないということは「お客さま要求に振り回されてもついていける」ことに通じます。お客さまの要求が次々と変わる場面で、アプリケーションも作った片端から作りなおしという場面でも、その変化にキャッチアップしていくためのフレームワーク、それがRailsです、と。

ですので、churaで目指すのならDBからビューのコードジェネレータよりも、テスト雛型のジェネレータであったり、一手でページネートできるようなユーティリティメソッドとか、そちらを目指してほしいと思います。Ajaxライブラリも取りこんでしまう、とか。

ということでRailsが生産性高いっていうのはコードを書く量が減る訳ですよ、明らかに。これはジェネレータで自分が書くコードが減る、というだけではなくフレームワーク側で大抵のことをやってくれるで、純粋にソースの行数が減ります。行数が減ると何が嬉しいか、保守対象のコードが少なくなって、作りなおすためのコストを低く保つことができるようになります。

また、忘れてはならないのはそれで少なく抑えてコードでできあがるアプリが、決して簡易版だとか実用には遠いものだとかではないこと。少ないコードでもちゃんとしたアプリができる、と。

で、そうするとさらにお客さまの「作りなおしたい」「大幅に変えたい」要求に答えられますよ、と。それができる気にさせてくれるからこそRailsの現在の人気があるのだと思います。

まぁ結局Buriはないですし、DBの設計もちゃんとやんなきゃいけませんが、それらをきちんとやった上で、コーディングの部分での無駄取りをするためのものです。Railsは。

なので高橋さんの「ERD本とRailsがあれば最強じゃね?」発言に通じるわけです。

ということでRails使ってる人は絶対に読んどくべき知識です。> ERD本。いや、できるんならいいんですけど、そうじゃないなら、Davidの示したSubscriptionのCRUDに(゜д゜)ポカ−ンとするなら読んどいて損はないはずです。


楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

すらすらと手が動くようになるSQL書き方ドリル

すらすらと手が動くようになるSQL書き方ドリル

2006/06/19 22:11 追記
  • 誤字脱字や誤変換を訂正。
  • コードが少ないことそれ自体だけが嬉しいわけではない、というニュアンスを追加したつもりです

*1Ajaxを使ったオートコンプリートとか、ページネートとか

sshisshi 2006/06/21 00:00 はじめまして。どこで補足するか迷いましたが、ブクマコメントへ返事をコメントします。まずかったら消してください。
個人的には、Railsには本気でビジネスに使うには、足りない部分がまだまだあると感じているので、Railsのどこが足りないか?どこを補えば使えるか?といった視点の話を期待していたのですが、カンファレンスでは「Railsスゲー」感をアピールすることに終始している印象を受けました。
で、「ヤドカリの人」さんの記事を読んで、Rails使いにも「scaffoldは実際は使わない」「テーブル設計重要」「Generatorは重要じゃない」という認識の人が多いなら、やっぱり「スゲー」だけじゃなくてRailsを補完するような話のほうが良かったんじゃないかと再び感じた、というわけです。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

Connection: close