統合システムを評価する
Ruby on Railsはさまざまな目的に使用できますが、趣味はモノリシックな統合システムです。 このようなシステムは、問題全体をまとめて解決することを目的としています。 インスタントページ更新のためのJavaScriptの生成から、プロジェクトが既に稼働しているときにデータベースをあるバージョンから別のバージョンに移行することで、すべてがRailsを通過します。
前に述べたように、そのような定式化では、タスクは非常に幅広いですが、一人でも可能です。 Railsは特別に設計されているため、1人の多目的な専門家または小さなグループが完全なシステムを作成できます。 さもなければ、専門家は高度に専門化されたニッチで立ち往生し、深刻なプロジェクトを実施するために、チーム全体がこれらの専門家から集められなければなりません。
個々の開発者の能力を拡張することが強調されており、統合システムへと私たちを押し付けています。 統合システムにより、不必要な抽象化を削除し、レイヤー間の重複を減らし（たとえば、サーバーとクライアントで同じテンプレートを使用する）、最も重要なこととして、最後に分散アーキテクチャへの移行を防ぐことができます。
分散システムの主な複雑さは、要素間のデータ転送を困難にする新しい境界の出現に関連しています。 あるオブジェクトで別のオブジェクトのメソッドを呼び出すことは、あるマイクロサービスから別のマイクロサービスでプロシージャをリモートで呼び出すよりもはるかに簡単です。 分散システムでは、依存関係の更新のスケジュール、サービスの利用不能、遅延など、多くの複雑な問題が突然発生します。
悲しいかな、時には分散アーキテクチャが不可欠です。 Webアプリケーションに、ユーザーがHTTP経由でアクセスするAPIが必要な場合は、何もする必要はありません。前述のほとんどすべての問題を解決する必要があります。 インターフェースがしばらく動作しない場合、ユーザーはこのインターフェースで問題を起こさないため、着信リクエストでの作業が発信リクエストでの作業よりもはるかに簡単であることは喜ばしいことです。 少なくともこの場合、開発者として耐えなければならない不便さはそれほど大きくありません。
システムが時期尚早にサービスに分割されたり、さらに悪いことにマイクロサービスに分割されたりするのは悪いことです。 「現代のインターネットアプリケーション」を開発する場合、必然的に同じシステムを何度も構築しなければならないという意見があります。一度はサーバー側で、一度はクライアント側でJavaScript MVCの形で、もう1つは各モバイルプラットフォームなどです。 。 しかし、この要件は何によっても条件付けられていません。そうすることは絶対に任意です！
異なるタスクとアクセス方法に同じシステム要素を簡単に使用できます。 デスクトップブラウザーとネイティブモバイルアプリケーションの両方に対して、コントローラーとビューの単一セットを作成します。 モノリシック統合システムにできるだけ多くの機能を集中させます。
同時に、分散アプリケーションの設計を急ぐ開発者を最適化するために、速度、使いやすさ、その他の特性は実質的に影響を受けません。
私たちのすべての努力は、シンプルで便利で理解可能な統合システムで、完全に調整された分散アプリケーションのすべての利点を得ることを目的としています。
安定性よりも進歩
Railsなど、システムが10年以上存在している場合、その自然な傾向は骨化です。 過去のシステムの振る舞いに依存している人にとって、どこの誰にとっても、すべての変更が問題になる可能性があるという理由は百万あります。 そして、特定の場合におけるこれらの理由は、個人にとって完全に真実です。
しかし、保守主義の声に注意深く耳を傾けると、コインの反対側が見えなくなります。 私たちは時々自由を取り、すべてが発展し成長する条件を変えなければなりません。 Railsを保護するのは、この開発です。10年間（数十年）の生存と繁栄の両方。
これはすべて理論的には簡単に理解できますが、実践するのは困難です。 特に、Railsのメジャーバージョンの変更により、アプリケーションが下位互換性違反から破壊された場合。 悪いコードをデバッグし、問題を明確にし、プロジェクトのライフサイクルを最終的に進めるためのエネルギーを高めるために、進歩が安定性を上回ることを忘れてはならないのはそのような瞬間です。
これは、誰かに不必要な痛みや過度の痛みを与えるような寛容ではありません。 Railsからバージョン2.xからバージョン3への大きな移行は、この移行に関与した人々の傷をいまだに興奮させます。 大変でした。 長い間バージョン2.xに多くの人を残した深刻な騒ぎであり、それらのいくつかはそこから戻れませんでした。 しかし、物事の壮大な計画によると、それはまだ価値がありました。
これらは私たちが続けなければならない難しい決定です。 Railsは今後5年間で今日の変更をより良くするでしょうか？ Railsは、今後数年間でメッセージキューやWebSocketなどの新しいタスクのスタックを適応させる方が良いでしょうか？ もしそうなら、袖をまくり上げて仕事に取り掛かりましょう。
この作業は、Railsだけで行われるべきものではなく、Ruby言語自体のより大きなコミュニティでも行われます。 Railsは開発の最前線に位置し、Rubyの進歩を支援し、そのコンポーネントに後のバージョンをより迅速に使用させる必要があります。
これまでのところ、私たちはこれで非常にうまくやっています。 始めた瞬間から、Rubyバージョン1.6、1.8、1.9、2.0、2.1、2.2を経て2.3になりました。 多くの主要な変更が途中で発生しましたが、Rubyを内部で使用し、開発プロセスをより迅速に実行できるようにするために、Railsが直接存在し、関与していました。 これは、一部は特権であり、一部はRailsへのコミットメントであり、Rubyの普及の基盤となっています。
これは、ワークフローサポートツールにも当てはまります。 Bundlerはかつて物議をかもしたアイデアでしたが、これは共有の未来の礎になるとRailsが主張しており、今日では当然の事実上のツールです。 これは、アセットパイプライン（ファイルパイプライン）やSpring、Railsアプリケーションプリローダーなどのツールとテクノロジーにも適用されます。 3つのツールすべてが発根段階を経るか、成長の痛みを経験し続けましたが、長期的にはそれらの価値の証拠がこの問題を克服するのに役立ちました。
進歩とは、最終的には主に人々と変化を推進する意欲に関するものです。 そのため、Rails CoreやRails Committersのようなグループは存在しません。 両方のグループは、フレームワークの進歩を達成するために積極的に取り組んでいる人を対象としています。 一部の人にとっては、そのような進歩への貢献はわずか数年で測定でき、他の人にとっては何十年も続くことができる一方で、彼らの仕事に永遠に感謝します。
したがって、コミュニティの新しいメンバーを歓迎し、奨励し続けることが非常に重要です。 より良い進歩を遂げるためには、新鮮な血と新鮮なアイデアが必要です。
大きなテントを建てる
非常に多くの物議をかもしているアイデアを含んでいるRailsは、すべての原則を一度に完全に尊重し続けることで、すぐにイデオロギーの隠者の島になることができます。
それが私たちがそうしない理由です！
意見の相違が必要です。 違いが必要です。 いろいろな考えや人が必要です。 このアイデアのるつぼで、みんなと共有するために最善を尽くします。 多くの人々は、コードを書くか討論するかに関係なく、何らかの形で貢献します。
そのため、このドキュメントでは理想主義的な方法で多くを説明していますが、日常の現実ははるかに細かい（そしてより興味深い）ものです。 Railsはそのような大規模なコミュニティを1つのテントでサポートすることができます。その文化には、「唯一の適切なアプローチのためのテスト」があるとしても非常に少ないからです。
テスト用のDSLであるRSpecが進化し続けるにつれて、私はしばしば深刻な不満を表明し、これは上記を完全に示しています。 私はRspecを真剣な仕事とは考えていないので、青に変わるほどります。それにもかかわらず、それは技術として栄え、栄えています。 そして、これは、「真の」技術のみを選択するよりもはるかに重要です。
HTTP APIとしてのRailsモードについても同じことが言えます。 私は個人的にコミットし、ビュー（ビュー）を含む統合システムに焦点を当てていますが、Railsには、アプリケーションをクライアントとサーバーパーツ（バックエンドとフロントエンド）に分割したい開発者に提供できるものがたくさんあります。 このような決定はRailsでマイナーとして開発される可能性があるため、これを受け入れる必要があります。これは可能であると確信しています。
しかし、「大きなテントを持っている」とは、みんなを喜ばせようとすることではありません。 それは、パーティーですべての人々に挨拶し、「彼ら自身の飲み物を持ち帰らせる」ことを意味します。 私たちは、他の人を招待して、支持者や価値観を失ってはなりません。また、すでに存在するものに付随する新しい貢献（「飲み物」）を混ぜることを非常によく学ぶことができます。
簡単ではありません。 これには、コミュニティとその中で働くことが友好的で歓迎的であることが必要です。 特にあなたの目標が、コミュニティの既存のメンバーに似ている人々を引き付けることだけではない場合。 コミュニティに入るためのしきい値を下げることは、私たちが常に真剣に考えなければならない仕事です。
ドキュメントのスペルミスを修正し始めたばかりの新しい開発者がRailsの次の大きな機能の実装をいつ終了するかを知らないかもしれません。 そして、彼がそれをやるかどうか。 しかし、あなたはあなたが微笑むかどうか、そして私たち一人一人にとどまる動機付けを許す小さな貢献に感謝を言うかどうかを知る機会があります。
railsfunを翻訳してくれてありがとう