⛴️ 🎗️ 🌞 Railsに別れを告げる時です 👃🏻 ⛅️ ⚡️

昨年、私はもうRailsを使用しないことを決定し、gemsでRailsをサポートしません。さらに、仕事で再びRailsに出会うことがないように最善を尽くします。

私は多くのRubyプロジェクトに関与しているため、Railsが好きではない理由や、Railsにどんな問題があるのかなど、よく聞かれます。そこで、すべてをまとめて説明するために、この長い投稿を書くことにしました。

この記事は部分的に技術的であり、部分的に個人的であり、残念ながら部分的に怒っています。これは、注目を集めたり、訪問者を獲得したりしないために書いています。これには興味がありません。 Railsについての議論を終了したいので、同じ質問を聞くたびにリンクを提供する場所があるので、これを書きます。

また、「初心者のRails開発者」はおそらく聞いたことがないかもしれないいくつかのストーリーをお伝えし、少なくともそれらについて考えるのに十分重要ないくつかの問題を強調したいと思います。

良い部分

Railsのすべてが悪い、間違っている、そしてフレームワークが悪の具現化であるというふりはしません。それは不公平で、ただ愚かなことでしょう。 Railsについて多くのことを言うことができます。そして、バランスを維持するためのいくつかの（明白な？）事柄に言及します。

そのため、RailsはRubyの人気を高めました。これは事実です。私はRuby開発者になりました。それが私のキャリアを変え、Railsのおかげで多くの素晴らしい機会を与えてくれました。当時の多くのルビストは同じように行きました。 Railsのおかげでここにいます。多くの場合、Railsは実際に人々に大きな影響を与え、文字通り彼らの生活を改善しました。人々はより良い仕事、より良い機会、そして良いお金を得ました。これは私たちの多くにとって「ゲーム」という用語の根本的な変化でした。

長年にわたり、Rails＆DHHは、他のコミュニティの人々を含む多くの人々に、彼らがしていることを再考するよう促しました。たとえば、RailsはPHPコミュニティの改善に貢献したと確信しています（私が間違っていることを証明することはできますが、SymfonyがRailsから多くのインスピレーションを得た方法についてはかなり鮮明な思い出があります）。 Javaでも同じことが起こりました。Playフレームワークは一例です。

他にも素晴らしい面があります。 Railsは常に使いやすさとWebアプリケーションの迅速な構築を目指しており、Rails Girlsなどのイニシアチブの成功につながっています。 Railsは、プログラミング経験がなくても比較的短時間で独自に何かを作成できることを人々に証明しています。これは、そうでなければプログラマーになることさえ考えない人々にとって、プログラミングの世界への入り口になりやすいため、驚くべきことです。

私の旅

私の経歴とRailsに来た経緯について少しお話しましょう。

私の論文はRailsについてだったので、2006年の終わりにRubyを使い始めました。私は卒業証書を書きながら言語を勉強しました。楽しかったし、面白かったし、私にとっては新しいものでした。その後、私はまだPHP開発者として働いていました。そして、2005年から2005年の典型的なPHPプログラマとして、私はこれらすべての典型的なことをしました：プレゼンテーションテンプレートでSQLクエリを書き、手続き型スタイルで書き、それから私自身のフレームワークと私自身のORMを開発し、失望して燃え尽きました。 C、C ++、Java、およびPythonに関するある程度の知識にもかかわらず、RailsのためにRubyに切り替えることにしました。私は卒業証書のためにそれらを選んだのですが、偶然地元のRailsストアからの仕事のオファーを見つけました。私は答え、彼らは私を雇った。それは2007年3月でした。

そのため、2007年3月にプロとしてRubyを使い始め、2009年のどこかでRubyのOpenSourceプロジェクトに貢献し始めました。それ以来、主に大規模で複雑なプロジェクトで、コンサルティング会社で3.5年間働いています。その後、彼は数年間フリーランサーとして働き、多くのクライアントと仕事をし、彼自身の会社を開き、その後フルタイムで、そして再びフリーランスで働きました。そして今、私は再びフルタイムの従業員です。 Railsアプリケーションをゼロから作成し、比較的大規模なRailsアプリケーションの開発に参加しました。

話を聞かせてください。既存のプロジェクトに参加したら。オンラインショッピングコミュニティのWebサイトを運営する素晴らしいアプリでした。洗練された販売モデル、複雑なプロモーション、商品の複雑な構成、クーポン、ユーザーグループ、メッセージなど、すべて揃っていました。いくつかの新しい機能を追加するために参加しました。私の最初のタスクの1つは、...ページ上の何かへのリンクを追加することでした。この愚かなリンクを追加するのに数日かかりました。なんで？このアプリケーションは、複雑なドメインロジックの大きな玉であり、いくつかのレイヤーに展開され、リンクを追加する目的のテンプレートを見つけることさえ容易ではないほど複雑なビューを備えていました。このリンクを作成するために注文からのデータが必要だったので、どのように取得するかは明らかではありませんでした。内部アプリケーションAPIがなく、ActiveRecordのみに依存しているため、このタスクは非常に困難でした。私は冗談ではありません。

Railsに対する私の最初の不満はかなり早い時期から始まりました。 ActiveRecordを使用してから約6か月後に不満を感じました。また、RailsがJavaScriptとAJAXにどのようにアプローチしたかについても気に入っていません。 RailsがUJSアプローチを採用する前のバージョンを覚えていないか、見つけられなかった場合（2007-2008年の議論のヒット）、RailsはテンプレートでインラインJavaScriptを使用し、多くの厄介なヘルパーによって生成されました。 Railsのすべての機能と同様に、「最初は簡単で楽しい」ものでしたが、サポートされていないがらくたになりました。最終的に、Railsはバージョン3.0でUJSを採用し、コミュニティはこれが最良のアプローチであることに同意しているようです。そのとき、Merbは ~~殺された~~ Railsに注がれました。ああ、あなたはMerbが何であるか分かりませんか？ OK、それについて話しましょう。

Merb＆DataMapperに満足した理由

Merbは、Ezra Zygmuntowiczによって作成されたプロジェクトです。ファイルのダウンロードを高速化し、スレッドセーフにするためのハックとして始まりました。そして、彼はこのハックから、Webアプリケーションを開発するためのモジュール式のスレッドセーフで高速なフルスタックフレームワークへと、興味深い方法で取り組みました。 2008年に人々がMerbについて話し始めたときのことを覚えていますが、新しいことが起こっていて、それは素晴らしいことだという驚くべき感覚でした！

APIモードがRailsに登場したとき、あなたは喜んでいたでしょうか？うーん、Merbには3つのモードがありました。フルスタックモード、APIモード、マイクロモードで、最小限にカットされていましたが、これはRubyの世界で最も速いものだったことを今でも覚えています。それは7年以上前です。考えてみてください。

同時に、別のプロジェクトDataMapperがコミュニティの注目を集めました。彼はMerbスタックの一部となり、ORMの選択肢になりました。 ActiveRecordにあった多くの問題を彼がどのように解決したか、私はとても興奮していました。すでに2008〜9にあるDataMapperには、モデル、カスタムタイプ、遅延クエリ、より強力なDSLクエリなどの属性定義があります。 2008年、Yehuda Katzはプロジェクトの中心的な開発者の1人でした。彼は積極的にプロジェクトを推進し、これには大きな興奮がありました。 DataMapperは、最終的に2008〜9年のActiveRecordよりも優れたORMでした。 Sequelがほぼ同時に登場し、優れたソリューションであるにもかかわらずActiveRecordよりもはるかに使用されていないことは言うまでもありません。

MerbとDataMapperは、Railsに対してより良いことを行い、健全な競争を生み出すことができるという希望をもたらしたので、私は喜んでいました。どちらのプロジェクトもモジュール式アプローチとスレッドセーフを奨励しているだけでなく、コードを記述するためのより優れた標準であるということは言うまでもなく、私は興奮していました。

MerbがRailsに「注がれ」、バージョン3.0の大規模なRailsリファクタリングが行われたため、両方のプロジェクトが最終的にRailsに殺されました。 DataMapperはコミュニティの注目を失い、あまりサポートがなければプロジェクトを開発できませんでした。これは、MerbがRailsに「注がれ」なかった場合と同様でした。

このソリューションにより、Rubyエコシステムは多数の重要なプロジェクトを失い、Railsのみが恩恵を受けました。 Merbを殺すという決定が良いかどうかは個人的な意見の問題であり、決定がなされなかった場合に何が起こり得たかを推測することができます。しかし、競争については簡単な真実があります-それは素晴らしいことです。競争の欠如は独占を意味し、独占についての単純な真実があります-これは素晴らしいことではありません。競争は進歩と革新を促進し、競争は健全な生態系を生み出し、人々がより多くの共同作業を行って共通点を共有し、より良い基盤を作成できるようにします。これはRubyコミュニティで起こることではありません。

Merb＆DataMapperが（長期的に）ほぼ破壊された後、Rubyエコシステムで何か新しいものを作成することは非常に困難でした。人々はRailsに焦点を合わせていたため、新しいプロジェクトは大きな影響を受けました。控えめに言っても、新しいアイデアを打ち破るのは困難でした。何かを表示するたびに、人々は単にRailsのようになり、Railsとうまくやりたいからです。 Railsで動作するプロジェクトを作成することは困難ですが、後でこの質問に戻ります。

これらの年月を経て、最終的にはエコシステム全体を支配する1つのフレームワークに到達し、何千人もの開発者に影響を与え、非常に物議を醸す標準を作成しました。 2008年に成長し始め、Railsによって抑制された生態系の多様性を失いました。

ねえ、私はそれが陰謀理論のように聞こえる方法を知っていますが、そのようにとらえないでください。ここで私が言ったことは、私の個人的な感情と混ざった事実です。 2009年末にDataMapperに参加し始めましたが、DataMapperが崩壊するのを見るのは非常に悲しかったです。

難しさ！

複雑さは私たちの最大の敵です。 Railsに対する人々の熱意は薄れ始めました。複雑さの増大に対処するために、多くの疑問が解決されないことがすぐに判明したためです。 DHH＆co。が提供するもの。多くの問題を解決するのに十分ではなかったため、数千人の開発者が2007〜2008年に苦労し始めました。 Merb / DataMapperが改善をもたらすことを期待した人もいましたが、何が起こったのかがわかったので、Rails 3.0がリリースされた2010年に全員がRailsに戻りました。

数日前、誰かが「サービスオブジェクト」を使用してコードを整理することに関する記事へのリンクを/ r / rubyに投稿しました。これは、そのような多くの記事の1つです。これが最近のトレンドだと思う場合は、2010年3月のJames Golickの記事「Crazy、Heretical、and Awesome：The Way I Write Rails Apps」をご覧ください。

私たちは、約6年間でRailsアプリケーションのアーキテクチャを改善する方法について話し合ってきました。私はできる限りこの議論に貢献しようとしました-記事、会議でのスピーチ、様々な複雑な問題を解決しようとする多くのオープンソースプロジェクトに取り組みます。

ただし、そのような議論やアイデアは、Rails Core Teamのメンバー、特にDHHによって常に笑されます。それは私を脅かし、落胆させました。そして、これが私がRailsに貢献しようとしたことがない理由です。私の提案が吹き飛ばされることになると確信しています。猿パッチ？さあ、問題ありません。10年前が大好きです。新しい抽象化？誰がそれを必要としているか、Railsは簡単です！ TDD？問題ありません、彼女は死んでいます、心配しないでください！ ActiveRecordは肥大化しています-それで、それはとても便利です、さらに機能を追加しましょう！

Railsのエコシステム、特にそのコアチームは、私に良い印象を与えたことはありません。変更を提案することを恐れていることを認めることは問題ではありません。私が提案する最初のことは「ActiveSupportを削除してください」であるため、これは特に当てはまります（笑...これを想像してください！）。

さて、技術的な詳細に取り掛かりましょう。

利便性指向のデザインレール

先ほど言ったように、Railsは使いやすさを重視して構築されました。これを単純さと混同しないでください。ちょうど昨日、私はそれをすべて言っているこのツイートに出会いました：

シンプルvsイージー

Railsの仕組みを次に示します。典型的な例です。

User.create(params[:user])

, ( , User ActiveRecord), . , . / , ?

, , , " " , :

params -
params
params , ,
, ( I18n)
params ,

, . (coupling) .

Rails . Rails SRP ( SOLID ) ", , ". , , , Rails YAGNI. , , , Rails, tenderlove, “use ActiveSupport::Concerns”.

Rails- , , - ActiveRecord, , .

— , . Rails, , , , , . , . ActiveRecord , Rails , Rails .

, ActiveRecord , Attributes API ( , ). , ActiveRecord 200 concerns, ORM, .

Rails? . , - , Rails . — ActiveRecord.suppress

, DHH. , Ruby , : ", , CreateCommentWithNotificationsFactory". -!

ActiveCoupling

Rails ? , , - . , , Rails . Rails, . , , DHH :

Rails is your app

, ? ", ". , ? !

Rails , , , , .

ActiveRecord . . , . Rails , ActiveRecord, SRP, LoD, . Rails.
"" Rails ActiveModel, Active Record ORM ( Sequel, )
Rails-,
Rails-,
Rails, gems, Rails, ( mixins, ). Rails gems , , , — .

, , Rails — . , , . Rails , , "" Java . Rails - .

. .

, Rails — ActiveSupport. , , . .

, , - ActiveSupport Rails Ruby. Rails . , , , , API, - . !

Rails , . - Rails, , ActiveSupport, , , , , Rails , .

, Rails, , . , , Rails ( , , Rails), . , , Rails? , , ActiveRecord, , — ActiveModel, ActiveRecord Rails 3.0.

, Rails .

, . Rails , . , , Spring. , , Rails. , , . , Ruby , . , , Rails. Rails, , , , , . - , . , , , , , , F5. .

, , , ! Rails . , .

ActiveSupport, ActiveRecord , ORM, , , - Rails.

Rails

Rails OpenSource Ruby, . , Rails. , . , , - Rails. ! ! Rails , , - , , -. -, Rails ! .

. , dry-rb, hanami and trailblazer rom-rb. , , , , Merb DataMapper.

, , , . , , .

Ruby

, Rails — — Ruby . . , Ruby. Elixir . Clojure, " ". , . , Haskell, . Scala. , , , TypeError . — , , - .

, Rails, . Monkey-patching, , ORM — .

, " Ruby - , , , , ". . , Ruby - (, ..). -, , , Ruby-. , , — .

, Ruby. . , . rom-rb, dry-rb, hanami trailblazer. , , .

, , .

. Rails .

, . , , . , , . , , "" -, , , , , . Rails, , .

, , , Rails ,

. , GitHub, 2435 OSS . . , Rails - , . , , . , OpenSource , GitHub.

OSS, Rails

. , , . Rails . Rails, , ActiveSupport ActiveRecord .. - , (. Hanami).

Railsに別れを告げる時です