ruby-on-rails - Ruby on Rails で発生する技術的負債 (ある場合) は?

Question

私は ruby​​ on rails の大ファンで、web アプリケーション プログラミング手法の「最大のヒット」の多くが組み込まれているようです。特に構成よりも慣習は、私の心にとって大きな勝利です。

しかし、私が得ている便利さの一部は、将来的に返済する必要がある技術的負債を犠牲にしてもたらされていると感じています. 多くの場合、ROR には多くのベスト プラクティスと適切なデフォルト オプションが組み込まれていると思うので、ROR が迅速で汚いと思っているわけではありません。ただし、まだいくつかのことをカバーしていないように思えます (特に、フレームワーク内のセキュリティに対する直接的なサポートはほとんどなく、私が見たプラグインの品質はさまざまです)。

ここで宗教的な意見や論争を求めているわけではありませんが、Rails を改善する必要がある分野や、Rails のユーザーが自分で注意する必要があることについて、コミュニティの意見を知りたいと思っています。フレームワークは彼らの手を握って正しいことをするように導くことはありません.

Answer 1

フレームワークに関係なく、プログラマーは自分が何をしているかを知る必要があります。フレームワークのサポートなしで行くよりも、Ruby on Rails のように成熟し、適切に設計され、広く適応されたものを使用して安全な Web アプリケーションを構築する方がはるかに簡単だと思います。

プラグインに注意して、それらがどのように機能するかを調べてください (自分が何をしているかをもう一度確認してください)。

Answer 2

Rails も大好きですが、使用しているフレームワークの欠点を理解することは重要です。これらの問題に対処することは幅広いトピックかもしれませんが、誰も傷つけることはありません.

セキュリティの問題とは別に、もう 1 つの大きな問題は、共有ホストでの展開です。PHP は共有ホスティング環境で成功しますが、Rails は依然として遅れをとっています。

もちろん、プロの Rails 開発者のほとんどは、自分のアプリが本番用に微調整されたサーバーを必要とすることを知っており、Rails 固有のホストにデプロイすることは明らかです。

Rails が成功し続けるためには、コア チームがこの問題に対処する必要があります。

これの例は簡単です: 私は bluehost アカウントを持っていて、cpanel に Rails アイコンがあることに気付きました。ブルーホストのサポートに問い合わせたところ、多かれ少なかれダミーのアイコンであり、適切に機能しないとのことでした。

Rails アプリをデプロイしたい専門家は、bluehost を使用しません。、しかし、ホストがRailsをサポートしていると言い、ユーザーがサポートが何も知らない問題に遭遇すると、それはRailsを傷つけます..

Answer 3

どのレベルの抽象化でも、多少の犠牲が伴います。汎用化されたメソッドは、目的のために構築されたものに固有のメソッドほど高速ではありません。幸いなことに、変更しても大丈夫です。動的検索メソッドから出てくるクエリ プランが好きではありませんか? 自分で書いてください。

上記の誰かがうまく言いました-ハードウェアは開発者よりも安いです。「十分に少ない量のハードウェアで」追加します

Answer 4

私はDeploying Rails Applicationsを読んでおり、あなたの懸念に答えるために強くお勧めします。

この本には、Rails 開発を後回しにするのではなく、デプロイメントを意識したアプローチをゼロから取り入れて、生活を楽にするための提案がたくさんあります。

RoR の選択が技術的負債を意味するものではないと思いますが、最初の数章を読んだだけで、アップグレードによって中断されないようにコア Rails gem をフリーズするなど、特に共有ホストで従うべきプラクティスについて警告を受けました。ホスト上。

共有ホストに関する 30 ページの章には、アカウントごとに 1 つの Rails アプリで複数のアカウントを使用する (可能であれば) など、メモリの見積もりに関するヒントが含まれています。また、RMagick などの一般的なライブラリが、プロセスが強制終了されるポイント (100MB の制限など、一部のホストが定期的に適用されることを示唆する) までメモリ サイズをプッシュする可能性があることについても警告します。

Answer 5

あなたが参照する記事では、技術的負債を次のように定義しています

[the] ずさんなソフトウェア アーキテクチャと性急なソフトウェア開発の最終的な結果

Rails では、テスト駆動型でない開発には技術的負債が発生します。しかし、それはどのプラットフォームにも当てはまります。

アーキテクチャ レベルでは、Rails にはいくつかの展開上の課題があります。ビジーなサイトは、多くのハードウェアで拡張するか、インテリジェントなキャッシュ戦略を使用する必要があります。

Rails を採用する人への私のアドバイスは次のとおりです。

• すべての開発に TDD を使用する
• テストを読んで、使用するプラグインの品質を確認してください。それらが明確で完全でない場合は、プラグインを避けてください
• 「Rails Recipes」と「Advanced Rails Recipes」を読んでください (Advanced Rails Recipes には、RESTful な方法で認証を追加するための優れたレシピがあります)
• サイトをスケーリングするためのハードウェアに支払う準備をする (ハードウェアは開発時間よりも安い)

Answer 6

私の経験から、RoR で支払う最大の料金は次のとおりです。

• かなり大きなデフォルト スタック (使用している可能性のあるプラグインは数えません)
• モデルの更新は、少なくとも実稼働サーバーでは、面倒な作業になる傾向があります。
• Rails や Ruby 自体の更新は必要以上に複雑ですが、これはサーバーの設定によって異なります。
• evalshe が述べたように、展開は時々厄介であり、さらに先に進むと、必要に応じて、ほとんどの開発フレームワークと同様に、スケーリングが少し不安定になります。

そうは言っても、私はいくつかのプロジェクトで RoR の熱心なユーザーであり、実際のハードウェアの状態では、それを使用するためにいくらかの技術的負債を支払うことになりますが、それはほとんど無視できます. そして、これらの問題が最終的に見直され、解決されることを期待できます。