Ruby on Rails欠点と警告

Question

これは、RoRバッシングの冒頭の目標ではありません。正直です。

私はRubyとRailsフレームワークを学習しています。一見すると、PHPに比べてかなりクールで素晴らしい経験のように見えます（実際、 C＃と.NETで幸せな日々を思い出させてくれます。）

しかし、これに入ると、私はこのフレームワークまたは言語での経験がなく、私は興味があります-あなたが始めていたときにあなたが知りたいと思っている現在の欠点やことは何ですか？

（たぶん、これはコミュニティウィキにする必要がありますか？）

Wayne Molina · Accepted Answer

これは、Railsでの比較的単純なアプリケーションの学習、学習の継続、および作成の経験に基づいています。

1）学習曲線

Railsは一見シンプルです。チュートリアル、ビデオ、および書籍はすべて、（醜い場合に）機能するアプリケーションをどれだけ迅速に入手できるかを示していますが、これらは実際には表面をなぞっただけです。彼らは、コード生成と「足場」に大きく依存する傾向があり、これは確かに学習時には優れたツールですが、すぐにその有用性よりも長生きします。

間違いありません、Railsは習得が困難です。基本を乗り越えたら（これについては後で詳しく説明します）、非常に単純化した以上のことを行う必要がある場合は、壁にぶつかります。デモアプリ」の機能が推奨されています。Rubyの基本的な知識があれば学習できますが、すぐに習得する必要がありますRubyまたはRails制約の外に出る必要がある場合は、高湿で乾燥したままにしておきます（DRYの良い種類ではありません）。

Railsは、私がそれを愛らしい方法で呼びたいので、Paint by numbersプログラミングです。慣習に100％固執する場合（つまり、ライン内に留まり、使用するように指示された色を使用する場合）、適切なアプリケーションをすばやく簡単に作成できます。ただし、逸脱する必要がある場合は、Railsが親友から最悪の敵に移動する可能性があります。

2）ハンマーさえあれば...

Railsは単純なCRUDアプリケーションを非常にうまく実行します。問題は、アプリがデータベースからの読み取り/書き込み以上のことを行う必要がある場合に発生します。さて、記録のために、最後に使用したRailsバージョンは2.3.4でしたので、その後変更された可能性がありますが、ビジネス要件が変更されたときにmajorの問題が発生しました。アプリケーションには小さなワークフローシステムが組み込まれていて、レガシーPHPアプリケーションと統合する必要がありました。Rails「1つのフォーム、1つのモデル」の規則）ささいなアプリやデータ入力アプリケーションでは問題なく機能しますが、処理ロジックを実行する必要がある場合や、ワークフローがある場合、または一般的な「ユーザーがいくつかのテキストフィールドにデータを入力し、送信する」タイプではないものはそれほど多くありません。。canできますが、それは決して「簡単」ではなく、最後にRailsを使用したときではありませんでした。

また、Railsは、データアクセスの推奨される方法を使用していない他のアプリケーションとうまくやりたくありません。「Web 2.0を持たないアプリケーションとインターフェイスする必要がある場合"スタイルAPI、あなたは回避する必要がありますRailsそれを使う代わりに;これは私に起こったことなので、ここでの経験から話します。

3）新しい

最後に、Railsは、多くの分野でまだ「ブロックの新しい子供」です。これは、個人的な使用や「かっこいいと思って学習したい」タイプのシナリオには関係ありません。 Rails私の日課で、Railsが普及している場所にいない場合、 Rails開発者としてフルタイムの仕事を見つけることは困難です。それは依然として大部分が「ヒップ、新しいスタートアップ」の領域であり、ほとんどの大都市圏の主要なプレーヤーではありません。この点であなたのマイレージは異なるかもしれませんが、私は私の地域（タンパ）を知っていますRailsは基本的に存在しません。

4）火と動き

Railsは常に変化しています。これは良いことでも悪いことでもあります。コミュニティは進化し、新しいコンセプトを取り入れているので、それは良いことです。コミュニティが進化し、新しいコンセプトを取り入れているので、それは悪いことです。 Rails初心者にとっては非常に圧倒される可能性があります。通常、問題が発生し、周りを見回すと、そのような宝石を修正するように勧めている人や、その方法はとにかく悪いので使用しないでください、これがより良い方法です...そして、Rails Rails cognoscenti。Git、BDD/RSpec、Cucumber、Haml/Sassのようなもの、および他のすべての宝庫標準を使用しているため、Railsランドで「適切な方法」としてプッシュされ、経験から言うと、ダース以上のテクノロジーを学習しようとすると、結局、Railsに加えてとなる可能性があります。 Railsツールキットは「間違っている」と感じます。

Rails 3.1により、すべてのもののSassとCoffeeScriptがデフォルトになり、合計Rails初心者が学習するだけでなく、RubyとRailsですが、Sass（CSSを知っていれば間違いなく単純です）およびCoffeeScript（非常に難しいことではありませんが、生のJavaScriptとは十分に異なります）最低限はじめに、それはGitと見なすことができます。RSpecや友人を考慮せずに、通常は最終的に何十ものジェムを使用しなくても、4は異なるものですRails applications。これをC＃やJavaなどの言語と比較するか、PHP where your HTML/CSS/JavaScript/SQLの知識は変わらないので、言語自体とおそらくフレームワークのニュアンスを学ばなければなりません。

Mladen Jablanović · Answer

ドキュメンテーション。

Railsガイドは優れた学習リソースですが、Rails（およびRuby、一般的には）ライブラリリファレンスは簡単にナビゲートできません。たとえば、belongs_to 方法。 ActiveRecord::Baseサブクラス（自分のモデル）、 ActiveRecord::Base docs、but a mixin でクラスがインポートします。基本的に、オブジェクトで使用できるすべてのメソッドの包括的なリストを1か所で表示することはできません（irbを起動してオブジェクト自体をチェックする場合を除く）。

Rubyのように非常に動的な言語では、使用しているメソッドがどこから来たのかを知るのは簡単ではありません。これは、特に新しいテクノロジースタックを把握しようとするプログラマを学習する場合に問題になる可能性があります。

pdr · Answer

Ruby on Railsはかなりの学習曲線を持っています。最初に言語の奇妙さを学び、次にフレームワークを学び、次にRailsのやり方を学ぶ必要があります次に、よく使用される多くの宝石について学びます。

しかし、あなたがそれらのことを学んだとき、それは信じられないほど自然に来ます。実際、他のフレームワークは負担のように感じ始めます。

Railsは非常にTDD/BDD指向であるため、そうでない場合は、有能なプログラマーになる前に、さらに2つのことを学ぶ必要がありますRailsプログラマー。コンパイラーがなく、 IDEはあなたをバックアップするので、テストカバレッジは非常にフォールバックです。

私も含めて、多くのTDD擁護者は、これをRoRの強みの1つであると同時に、その悪態を考慮します。 TDDの記述を開始すると、テストカバレッジによって提供されるセキュリティは、コンパイラによって提供されるセキュリティよりも優れていることがわかります。次に、コンパイラーを喜ばせるためにコードJUSTを書く必要があるだけで負担になります。

TDDはRoRの追加のタスクのように感じられません。それは、作業する唯一の方法のように感じられます。

Railsには重大なパフォーマンスの問題が1つあります。ほとんどのフレームワークのようにスレッド化したり、Node.jsやTwisterのようにブロックイベントで他のリクエストを解放したりするのではなく、各リクエストは現在アクティブなリクエストの後ろにキューイングされます。これは、応答時間を速くするためにコーディングする必要があることを意味しますが、ほとんどの場合、それは非常に簡単です。

Railsはまた、コンテンツシステムを非常にうまく処理するように設計されています。 Webゲームやeコマースシステムなど、もう少し複雑なことを行うと、新しい宝石を学ぶことになります。あなたはすぐにすべての宝石がそこにあることを学びますが、やりたいことをもっと曖昧にすればするほど、良いドキュメントを見つけることが難しくなります。

ohho · Answer

私の個人的な経験では、主な頭痛は互換性あたりです。

いつ：

x Railsプロジェクトがデプロイされています、
各プロジェクトはy gemsを使用します。
railsにはnバージョンがありますが、
さらに、インストールされているgemのmバージョン、
rubyのseveralバージョンでは、
単一のLinuxボックス上で実稼働マシンとして。
プログラマーは別のOS X開発ノートブックで作業します。

ほとんどのものを更新/アップグレードする余裕がないフリーランサーとして、上記の変数から多くの互換性の問題に直面します... Rails、gems、およびRubyは変化/進化を続けます。

back2dos · Answer

速度は間違いなく問題です。 Rubyの極めて高い柔軟性は、パフォーマンスに大きな影響を与えます。

水平方向のスケーリングは自明ではないタスクですが、そのタスクのために特別に設計されたテクノロジーは例外です。
テクノロジーAを使用すると、テクノロジーBの場合よりもマシンごとに100倍のリクエストを処理できる場合、単一のサーバーから時間枠でデータを提供できると考える理由がある場合は、テクノロジーAを使用することを検討する価値があります。これにより、後で並列化を追加できます。
2009年も、stackoverflowは 1つのWebサーバーから提供されていました。もちろん、これはもはやオプションではありません。しかし、彼らが、スケールアウトについて心配する必要がなくなる前に、単一のインスタンスで多くのユーザーにスケールアップできるテクノロジーから始めたのは良かったと思います。

それと比較して、RoRは本当に遅いです。単純なリクエストを処理する時間は重要であるため、多くのクライアントを処理することは問題です（これはすべて、より高速な代替策との関連で見られるものです）。

曖昧な方向付けのために、以下にいくつかの数値を示します。Web開発に適した他のさまざまな言語をRubyと比較しています。

これは、フレームワークXをJavaに使用すると、RoRよりも200倍高速になることを意味しません。ただし、これらのベンチマークで測定された速度の違いは、アプリの全体的なパフォーマンス。

netshade · Answer

Railsには、複雑さをユーザーから隠す多くの機能があります。（ActiveRecordアソシエーション、検証/保存ライフサイクル全体、提供されたヘッダーに基づく要求データの解釈）始めたばかりのとき、これは素晴らしいことです。成長するにつれ、アプリを「Rails」の方法で処理するようになり始めます-これは良い場合もあれば、無害な場合もあり、実際には直感に反する場合もあります。あなたがしようとしている。すべてのデータベーステーブルをオブジェクトとしてモデル化する必要があるわけではありません。検証手順は他の場所で行う必要がある場合もあります。多くのRailsプログラマは、フレームワーク（通常は賢明）との戦いを避けていますが、これは...あなたがRailsの癖を彼らが必ずしも求められていない場所に連れて行くでしょう。
コミュニティは、「魔法」として請求されるソフトウェアを書く習慣があります-魔法のように機能するlibをキャッシングします！魔法のように高速化するイベントI/O！マジックマジック！ここで通常当てはまるのは、欠けている技術的なソリューションのために非常に魅力的なAPIが提供されており、意図したとおりに機能する非常にきれいな例にだまされ、後でそれが不完全なソリューションをカバーしていることに気付く場合です。これのサイクルはかなり一定であり、あなたはそれを使いこなすことを学びますが、あなたが依存しているたくさんのコードを読むという考えに確実に慣れるべきです（良いことです！）。 Railsコミュニティマジックソリューションは、READMEが示唆するほどマジックではない、と私は言っています。
上記の結果：Railsを使用するほど、そのソースをより多く読む必要があります。フレームワークの内部をよく理解すればするほど、長期的に幸せになります。これについては特にRails固有ではありませんが、ここでの経験からお伝えします。メソッド名は、実際には得られないものを約束することがあります。
貨物カルト主義はRailsの問題ですが、それはおそらくすべてのフレームワーク/ langコミュニティの真実です。 Railsでは（私にとって）それがより顕著に見えるようであり、そのため、Railsコードに奇妙な世代の外観を与える傾向があります-異なるRailsプロジェクトで作業するとき、特定の傾向に気付くでしょうそれらが作成された期間を裏切る傾向があります。その声明から推測できるように、コミュニティは新しいソリューションの採用と古いソリューションの廃止にかなりのスピードで動く傾向があります。 Rubyのニュースを本当に理解している必要があります。毎日目にするコードのいくつかを理解するためです。
一般的に言えば、データの同時実行性の問題は通常コミュニティでは十分に対処されていないと思います。アプリを成長させると、データをシャーディングし、物理的にリモートの変更をロールバックし、データへのアクセスをロックする必要があるときに、ソリューションは次のようになります。もう少し手作業で調整します。これにより、見栄えの良いRailsのものが、正確さの技術的必要性によって、すべて混乱してしまいます。 Railsは、Webアプリで発生するすべての問題を解決するわけではありませんが、私は言っていると思います。作成者は確かにそのメッセージを伝えていませんが、暗黙のうちにだまされていると簡単に騙されます。

Pratik Naik · Answer

Railsには重大なパフォーマンスの問題が1つあります。ほとんどのフレームワークのようにスレッド化したり、Node.jsやTwisterのようにブロックイベントで他のリクエストを解放したりするのではなく、各リクエストは現在アクティブなリクエストの後ろにキューイングされます。これは、応答時間を速くするためにコーディングする必要があることを意味しますが、ほとんどの場合、それは非常に簡単です。

これは非常に誤解されていると思います。 Railsマルチスレッドモードで実行できます。マルチスレッドモードで実行する場合は、GILをリリースするIOライブラリのみを使用する必要があります（例： 'mysql2' gem ）そうでなければ、それは一種の無意味になります。

JRubyを使用している場合は、単一のRailsプロセスをマルチスレッドモードで実行し、利用可能なすべてのCPUパワーを完全に利用できます。ただし、MRIを使用している場合（Ruby 1.8.xまたは1.9.x）、CPUを完全に利用するには複数のプロセスを実行する必要があります。これはnode.jsの場合も同様です。

Xorlev · Answer

見方によっては、Railsの変化の速さは、あなたにとって警告になるかもしれませんし、そうでないかもしれません。ソリューションが必要です。

あなたが活発な開発をしているなら、あなたはこれのパルスにあなたの指を持っているでしょう。