Rails 信条

原文： https://rubyonrails.org/doctrine/

译文： https://ruby-china.org/wiki/the-rails-doctrine

以下是我的翻译（机翻）。

Ruby on Rails 的惊人崛起很大程度上归功于新技术和时机。但技术优势会随着时间的推移而消退，而良好的时机并不能单独维持长期的走势。因此，需要更广泛地解释 Rails 如何继续不仅保持相关性，而且扩大其影响力和社区。我认为，持久的推动因素一直是并且仍然是其有争议的学说。

这一学说在过去十年中不断发展，但其最强大的支柱也是创始支柱。我不主张这些想法的基本独创性。Rails 的主要成就是围绕关于编程和程序员本质的广泛异端思想团结并培养了一个强大的部落。

说了这么多，下面是 Rails 学说的九个最重要的支柱，正如您真正认为的那样：

1. 为程序员的幸福而优化
2. 约定优于配置
3. 菜单是 omakase
4. 没有一个范式
5. 赞美美丽的代码
6. 提供锋利的刀具
7. 价值集成系统
8. 稳定的进步
9. 包容并重

为程序员的幸福而优化

没有 Ruby 就没有 Rails，所以第一个教义支柱直接从创建 Ruby 的核心动机中提炼出来是合适的。

Ruby 最初的异端确实是把程序员的幸福放在一个基座上。超越了之前驱动编程语言和生态系统的许多其他竞争和有效的问题。

Python 可能会吹嘘 “有一种方法，最好只有一种做某事的方法”，而 Ruby 则喜欢表现力和微妙之处。在 Java 倡导强有力地保护程序员免受自身侵害的地方，Ruby 在欢迎套件中包含了一套锋利的刀具。Smalltalk 追求纯粹的消息传递，而 Ruby 则以近乎贪婪的胃口积累关键字和构造。

Ruby 与众不同，因为它重视不同的事物。而这些东西大部分都是为了程序员对幸福的向往。这种追求不仅与大多数其他编程环境不一致，而且与程序员是什么以及他们应该如何行动的主流看法不一致。

Ruby 不仅认识到，而且适应和提升程序员的感受。无论它们是不足的、异想天开的还是喜悦的。Matz 跨越了令人震惊的复杂性实施障碍，使机器看起来对它的人类同谋微笑和恭维。Ruby 充满了视觉错觉，在我们看来，看似简单、清晰和美丽的东西实际上是引擎盖下杂乱无章的电线。这些选择不是免费的（询问 JRuby 工作人员是否试图对这个神奇的音乐盒进行逆向工程！），这正是它们如此值得称赞的原因。

正是这种对编程和程序员的另类愿景的奉献，使我对 Ruby 产生了浓厚的兴趣。这不仅仅是易用性，不仅仅是积木的美学，也不是一项单一的技术成就。这是一个愿景。一种反文化。一个让现有专业编程模式不适应的地方，可以归属和联想到类似的想法。

过去，我曾将 Ruby 的这一发现描述为找到了一款完美贴合我大脑的神奇手套。比我想象的任何手套都适合。但不仅如此。正是这一事件标志着我个人从 “因为我需要程序而做编程” 到 “因为我爱上了它作为一种智力锻炼和表达方式而做编程” 的个人转变。它正在寻找一个流动的喷泉并能够随意打开它。对于熟悉 Csikszentmihalyi 工作的人来说，这件事的影响再怎么强调也不为过。

当我说 Ruby 改变了我并为我一生的工作设定了方向时，我并没有夸大其词。启示是如此深刻。它使我充满了为马茨的创作服务的使命。帮助传播这一深刻的创造及其好处。

现在我可以想象你们中的大多数人都难以置信地摇头。我不怪你。如果有人在我还生活在 “编程只是一种工具” 的范式下向我描述上述经历，我也会摇头。然后我可能会嘲笑宗教语言的过度使用。但要使这成为一个真实的叙述，它也必须是诚实的，即使这对某些甚至大多数人来说是令人反感的。

无论如何，这对 Rails 意味着什么，这个原则如何继续指导它的发展？为了回答这个问题，我认为看看早期经常用来描述 Ruby 的另一个原则是有益的：最小惊喜原则。Ruby 的行为应该符合您的预期。与 Python 相比，这很容易描述：

    $ irb
    irb(main):001:0> exit
    $ irb
    irb(main):001:0> quit

    $ python
    >>> exit
    Use exit() or Ctrl-D (i.e. EOF) to exit

Ruby 接受 exit 和 quit 以适应程序员退出交互式控制台的明显愿望。另一方面，Python 迂腐地指示程序员如何正确地执行所请求的操作，即使它显然知道是什么意思（因为它显示错误消息）。这是一个非常明确但很小的 PoLS 示例。

PoLS 在 Ruby 社区中失宠的原因是这个原则本质上是主观的。谁最不惊讶？嗯，对马茨。还有和他一样惊讶的人。随着 Ruby 社区的发展，以及对与 Matz 不同的事物感到惊讶的人的比例也随之增长，这成为邮件列表上无用的自行车脱落的来源。因此，该原则逐渐退居幕后，以免引发更多关于 X 人是否对行为 Y 感到惊讶的争论。

再说一遍，这与 Rails 有什么关系？好吧，Rails 的设计原则与最小意外原则（To Matz）类似。The Bigger Smile (of DHH) 的原则，这正是它在罐头上所说的：API 设计时非常注重任何能让我笑得更开更宽的东西。当我这样写出来时，这听起来几乎是可笑的自恋，甚至我也很难反驳这种第一印象。

但是创建 Ruby 或 Rails 之类的东西至少在一开始是一种非常自恋的努力。这两个项目都出自一位独特的创造者的头脑。但也许我在这里将自己的动机投射到 Matz 上，所以让我将我的声明范围缩小到我所知道的范围：我为我创建了 Rails。让我微笑，首先。它的实用性在很大程度上取决于它让我更享受生活的能力。丰富我每天为 Web 信息系统的需求和请求争吵的辛劳。

像 Matz 一样，我有时会竭尽全力地为我的原则服务。一个例子是 Inflector，这个类只理解英语语言的模式和不规则性，可以将 Person 类映射到 People 表，将分析映射到分析，以及简单地将评论映射到评论。这种行为现在被认为是 Rails 的一个不容置疑的元素，但在早期，当我们仍在整合该学说及其重要性时，争议之火熊熊烈火。

另一个需要较少实施工作的示例，但引发了几乎同样多的惊愕：Array#second 到 #fifth（以及 #forty_two 用于良好的控制措施）。这些别名访问者深深地冒犯了一个非常直言不讳的支持者，他们谴责了一些可以写成 Array#[1]、Array#[2]（和 Array[ 41]）。

但直到今天，这两个决定仍然让我微笑。我喜欢在测试用例或控制台中编写 people.third 。不，这不合逻辑。效率不高。它甚至可能是病理性的。但它继续让我微笑，从而实现了原则并丰富了我的生活，帮助证明我在服务 12 年后继续参与 Rails 是合理的。

与优化性能不同，很难衡量优化是否为幸福。这使得它几乎本质上是不科学的努力，这使得它不那么重要，如果不是完全令人沮丧的话。程序员被教导去争论和征服可测量的东西。有明确结论并且可以明确证明 A 优于 B 的那些。

但是，虽然在微观层面上很难衡量对幸福的追求，但在宏观层面上观察却要清晰得多。Ruby on Rails 社区充满了正是因为这种追求而来到这里的人。他们吹嘘更好、更充实的工作生活。正是在这种情绪的聚合中，胜利是显而易见的。

因此我们得出结论：为幸福而优化可能是 Ruby on Rails 最具形成性的关键。今后仍将如此。

约定优于配置

Rails 的早期生产力格言之一是：“你不是美丽而独特的雪花”。它假设通过放弃虚荣的个性，你可以跳过平凡决策的艰辛，并在真正重要的领域取得更快的进展。

谁在乎你的数据库主键是用什么格式描述的？它是 “id”、“postId”、“posts_id” 还是 “pid” 真的很重要吗？这是一个值得反复审议的决定吗？不。

Rails 的部分使命是在开发人员为网络创建信息系统时面临的不断增长的、不断重复决策的丛林中挥舞大刀。有数以千计的这样的决定只需要做一次，如果其他人可以为你做，那就更好了。

将配置转移到约定不仅使我们免于深思熟虑，而且还提供了一个郁郁葱葱的领域来发展更深层次的抽象。如果我们可以依赖映射到 people 表的 Person 类，我们可以使用相同的变形来映射声明为 has_many :people 的关联以查找 Person 类。良好约定的力量在于它们在广泛的使用范围内产生红利。

但除了专家的生产力提高之外，惯例还降低了初学者的进入门槛。Rails 中有很多约定，初学者甚至不需要知道，但可以从无知中受益。在不知道为什么一切都是这样的情况下，可以创建出色的应用程序。

如果您的框架只是一本厚厚的教科书而您的新应用程序是一张白纸，那这是不可能的。甚至要弄清楚从哪里开始以及如何开始都需要付出巨大的努力。前进的一半是找到一条可以拉动的线。

即使您了解所有部分如何组合在一起，情况也是如此。当每个更改都有明显的下一步时，我们可以快速浏览应用程序的许多部分，这些部分与之前的所有其他应用程序相同或非常相似。一个放置一切的地方，一切都在它的位置。即使是最有能力的头脑，约束也会解放。

但是，与任何事情一样，约定俗成的力量也并非没有危险。当 Rails 使做这么多事情变得如此琐碎时，很容易认为应用程序的每个方面都可以由预切模板构成。但大多数值得构建的应用程序都有一些在某些方面独一无二的元素。它可能只有 5% 或 1%，但它就在那里。

困难的部分是知道什么时候偏离惯例。偏离的细节何时严重到足以保证远足？我认为，大多数想要成为美丽而独特的雪花的冲动都被考虑不周，并且偏离轨道的成本也被低估了，但只是其中的一部分不足以让您需要仔细检查所有这些。

菜单是 omakase

当你不知道什么是好的时，你怎么知道在餐厅点什么？好吧，如果你让厨师选择，你可能会假设一顿美餐，甚至在你知道什么是 “好” 之前。那是 omakase。一种吃得好的方法，既不需要你是美食专家，也不需要在黑暗中盲目采摘。

对于编程而言，这种做法的好处是让其他人组装您的堆栈，这与我们从约定优于配置中得出的好处类似，但处于更高级别。CoC 关注我们如何最好地使用单个框架，omakase 关注哪些框架以及它们如何组合在一起。

这与将可用工具呈现为个人选择并赋予个人程序员决定特权（和负担！）的受人尊敬的编程传统背道而驰。

您肯定听说过并且可能点头表示 “使用最适合工作的工具”。这听起来非常基本，无可争议，但能够选择 “最佳工具” 取决于一个可以自信地确定 “最佳” 的基础。这比看起来要困难得多。

这是一个类似于餐厅用餐者的问题。就像在八套餐中挑选每门课程一样，挑选每个单独的库或框架并不是孤立完成的工作。两种情况下的目标都是考虑整个晚上或系统。

因此，对于 Rails，我们决定减少一个好处，即程序员在他们的工具箱中选择每个工具的个人特权，以获得更大的一个：更好的工具箱。红利丰厚：

数字是安全的：当大多数人以相同的默认方式使用 Rails 时，我们就有了共同的经验。这种共同点使教导和帮助人们变得更加容易。它为讨论方法奠定了基础。我们昨晚 7 点都看了同一个节目，所以我们可以在第二天谈论它。它培养了更强烈的社区意识。
人们正在完善相同的基本工具箱：作为一个全栈框架，Rails 有很多活动部件，这些部件如何协同工作与它们各自独立做什么一样重要。软件中的大部分痛苦不是来自单个组件，而是来自它们的交互。当我们都致力于减轻以相同方式配置和失败的组件的共同痛苦时，我们都会经历更少的痛苦。
替换仍然是可能的，但不是必需的：虽然 Rails 是一个 omakase 堆栈，但它仍然允许您用替代品替换某些框架或库。它只是不需要你。这意味着您可以推迟这些决定，直到您开发出一个可能更喜欢偶尔出现的差异的清晰的个人调色板。
因为即使是来到并留在 Rails 的最有学问和最熟练的程序员也不可能反对菜单的所有问题。（如果是的话，他们可能不会坚持使用 Rails。）所以他们勤奋地挑选他们的替代品，然后继续与其他人一起享受其余的策划共享堆栈。

没有一个范式

选择一个单一的中心思想并根据它得出合乎逻辑的结论作为您的架构基础具有强烈的情感吸引力。这种纪律有一种纯洁性，所以很清楚为什么程序员会自然地被这种明亮的光所吸引。

Rails 不是这样的。它不是单一的、完美的布料。是被子。许多不同想法甚至范式的组合。如果单独和一一对比，通常会在冲突中看到许多。但这不是我们想要做的。这不是一个必须宣布唯一获胜者的优秀想法的单一冠军。

以我们在 Rails MVC 饼图中构建视图的模板为例。默认情况下，所有允许我们从这些模板中提取代码的助手只是一大堆函数！它甚至是一个单一的命名空间。哦，震惊和恐怖，就像 PHP 汤！

但是我认为 PHP 在呈现很少需要交互的单个函数时做得对，就像视图模板中的很多抽象一样。为此，单一命名空间，一大堆方法，不仅是一个合理的选择，而且是一个很好的选择。

这并不意味着我们在构建视图时不希望偶尔使用更面向对象的东西。Presenters 的概念，我们包装了许多相互依赖的方法及其下面的数据，有时可以成为解决因依赖而变质的方法汤的完美解药。但它通常被证明是罕见的而不是常见的。

相比之下，我们通常将 MVC 层蛋糕中的模型视为面向对象优势的主要堡垒。为对象找到合适的名称，增加一致性，降低耦合是领域建模的乐趣所在。这是一个与视图非常不同的层，所以我们采用了不同的方法。

但即使在这里，我们也不认同单一范式教条。Rails 关注点，Ruby 的 mixin 的特殊性，通常用于为单个模型提供非常广泛的表面积。这非常适合 Active Record 模式，让相关方法可以直接访问它们与之交互的数据和存储。

甚至 Active Record 框架的基础也冒犯了一些纯粹主义者。我们将与数据库直接交互所需的逻辑与业务领域和逻辑混合在一起。如此混杂的境界！是的，因为它被证明是一种实用的方法来为 web 应用程序猫设置皮肤，它实际上总是与某种数据库对话以保持域模型的状态。

在意识形态上如此灵活是使 Rails 能够解决如此广泛的问题的原因。大多数个人范式在问题空间的某一部分内表现得很好，但当超出其自然舒适范围时会变得笨拙或僵化。通过应用许多重叠的范例，我们覆盖了侧翼并保护了后方。最终的框架比任何个人范式所允许的都要强大得多。

现在，这种与许多编程范式的多角关系的成本是概念上的开销。仅仅了解面向对象的编程就可以愉快地使用 Rails 是不够的。最好同时提供程序和功能体验。

这也适用于 Rails 的许多子语言。我们不会试图让您免于学习，例如，用于视图的 JavaScript 或用于偶尔复杂查询的 SQL。至少不会达到可能性的顶峰。

减轻一些学习负担的方法是在理解框架的每一个方面之前，简单地让入门变得容易，创造一些真正有价值的东西。出于这个原因，我们急于进入 Hello World。您的餐桌已经准备好，开胃菜已送达。

我们的想法是，通过尽早提供真正有价值的东西，我们将鼓励 Rails 的从业者快速升级。接受他们的学习之旅是一种乐趣，而不是障碍。

赞美美丽的代码

我们编写代码不仅仅是为了让计算机或其他程序员能够理解，而是为了沐浴在美丽的温暖光芒中。美观的代码本身就是一种价值，应该充满活力地追求。这并不意味着漂亮的代码总是胜过其他问题，但它应该在优先级表中占有一席之地。

那么什么是漂亮的代码呢？在 Ruby 中，它通常介于原生 Ruby 习语和自定义域特定语言的强大功能之间。这是一条模糊的线，但非常值得尝试跳舞。

这是 Active Record 的一个简单示例：

class Project < ApplicationRecord
  belongs_to :account
  has_many :participants, class_name: 'Person'
  validates_presence_of :name
end

这看起来像 DSL，但它实际上只是一个类定义，带有三个接受符号和选项的类方法调用。这里没什么好看的。但它肯定很漂亮。这当然很简单。它从这几个声明中提供了巨大的力量和灵活性。

美的一部分来自于这些对先前原则的尊重，比如约定优于配置。当我们调用 belongs_to :account 时，我们假设外键称为 account_id 并且它位于 projects 表中。当我们必须将 Person 的 class_name 指定为参与者关联的角色时，我们只需要该类名定义。我们将再次从中派生外键和其他配置点。

这是数据库迁移系统的另一个示例：

class CreateAccounts < ActiveRecord::Migration
  def change
    create_table :accounts do |t|
      t.integer :queenbee_id
      t.timestamps
    end
  end
end

这就是框架权力的本质。程序员根据某些约定声明一个类，例如实现#change 的 ActiveRecord::Migration 子类，框架可以完成所有相关工作，并且知道这是要调用的方法。

这使得程序员只需编写很少的代码。在迁移的情况下，这不仅允许调用 rails db:migrate 来升级数据库以添加这个新表，它还允许它以另一种方式通过另一个调用删除这个表。这与让所有这些发生并从他们自称的库中将工作流拼接在一起的程序员大不相同。

然而，有时漂亮的代码更微妙。与其说是制作尽可能简短或强大的东西，不如说是制作声明流程的节奏。

这两个语句的作用相同：

if people.include? person
  …

if person.in? people

但流程和重点略有不同。在第一条语句中，重点是集合。那是我们的主题。在第二个陈述中，主语显然是人。两个陈述之间的长度并不多，但我会争辩说，第二个陈述要漂亮得多，而且在与人有关的情况下使用时，可能会让我微笑。

提供锋利的刀具

Ruby 在其功能抽屉中包含了许多锋利的刀具。不是偶然，而是设计。最著名的是猴子补丁：改变现有类和方法的能力。

这种力量经常被嘲笑为对于普通的程序员来说太过分了。来自更严格环境的人们过去常常想象各种灾难会毁灭 Ruby，因为该语言向其演讲者展示了此功能的巨大信任。

如果您可以更改任何内容，有什么可以阻止您覆盖 String#capitalize 以便 “something bold”.capitalize 返回 “Something Bold” 而不是 “Something bold”？这可能适用于您的本地应用程序，但会破坏依赖于原始实现的各种辅助代码。

没什么，就是答案。Ruby 中没有任何编程方式可以阻止您使用其锋利的刀具来与理性断绝关系。我们通过惯例、推动和教育来强化这种良好的感觉。不是禁止在厨房使用锋利的刀具并坚持每个人都用勺子切西红柿。

因为猴子修补的另一面是能够完成诸如 2.days.ago（从当前日期返回两天前的日期）之类的奇迹。现在你很可能认为这是一笔糟糕的交易。如果这意味着防止程序员覆盖 String#capitalize，那么您宁愿失去 2.days.ago。如果那是您的职位，Ruby 可能不适合您。

然而，很难——即使对于那些会为了某种安全而放弃这种自由的人——争辩说改变核心类和方法的能力已经注定了 Ruby 作为一种语言。相反，该语言之所以蓬勃发展，正是因为它为程序员的角色提供了一种不同而激进的观点：他们可以用锋利的刀来信任。

不仅值得信赖，而且还教他们如何使用这种功能强大的工具。假设大多数程序员都想成为更好的程序员，能够挥舞锋利的刀而不切断他们的手指，我们可以提升整个职业。这是一个令人难以置信的有抱负的想法，并且与许多程序员对其他程序员的直觉背道而驰。

因为在争论利刃的价值时，总是与其他程序员有关。我还没有听到一个程序员举手说 “我不能相信自己拥有这种力量，请把它从我身边拿走！”。总是 “我认为其他程序员会滥用它”。那种家长式作风从来没有吸引过我。

这将我们带到了 Rails。框架提供的刀具不像语言提供的刀具那么锋利，但有些仍然非常热衷于切割。我们不会为提供此类工具作为套件的一部分而道歉。事实上，我们应该庆祝对我们的程序员同行的愿望有足够的信心，敢于信任他们。

随着时间的推移，Rails 中的许多功能都被认为 “太自由” 了。但目前流行的一个例子是关注特征。这是围绕 Ruby 模块的内置特性的一层薄薄的语法糖，旨在允许单个类封装多个相关但独立理解的关注点（因此得名）。

指控是担心为程序员提供了易于膨胀的对象，他们用一套全新的抽屉来塞满他们的杂物。这是真的。确实可以这样使用关注点。

但是巨大的谬误是认为通过不提供像关注点这样的功能，即使是有能力的人也可以使用它来雄辩地部分分离概念，我们会让程序员走上架构幸福的道路。如果不能信任您将厨房水槽排除在过度担心的问题之外，否则您可能不会最终获得优雅的闪亮灯塔。

没有学会使用锋利刀的程序员还不会制作蛋白酥皮。这里的操作词：然而。我相信每个程序员都有自己的道路，即使没有权利，也可以成为完全有能力的 Ruby 和 Rails 程序员。我所说的有能力，我的意思是有足够的知识，知道他们应该何时以及如何，根据他们的情况，使用抽屉里不同的、有时是危险的工具。

这并没有放弃帮助他们实现目标的责任。语言和框架应该是耐心的导师，愿意帮助和指导任何人成为专家。虽然认识到唯一可靠的路线是通过错误的土地：使用错误的工具，一点血，汗，甚至一些眼泪。没有别的办法。

Ruby on Rails 是适合厨师和希望成为厨师的人的环境。您可能会从洗碗开始，但您可以逐步管理厨房。不要让任何人告诉您，作为该旅程的一部分，您不能信任行业中最好的工具。

价值集成系统

Rails 可以在许多环境中使用，但它的最爱是集成系统的制作：雄伟的单体！一个解决整个问题的完整系统。这意味着 Rails 关注从进行实时更新所需的前端 JavaScript 到在生产中如何将数据库从一个版本迁移到另一个版本。

正如我们所讨论的，这是一个非常广泛的范围，但不会比对单个人的实际理解更广泛。Rails 专门寻求装备通才的人来制作这些完整的系统。它的目的不是将专家分成小众的领域，然后需要整个团队来构建任何具有持久价值的东西。

正是这种对赋予个人权力的重点指向集成系统。在集成系统中，我们可以删除许多不必要的抽象，减少层之间的重复（如服务器和客户端上的模板），最重要的是，避免在我们绝对必须之前分发我们的系统。

系统开发中的大部分复杂性来自于在元素之间引入新边界来限制您在 A 和 B 之间进行调用的方式。对象之间的方法调用远比微服务之间的远程过程调用简单。等待着那些冒险进入分发巢穴的人，在故障状态、延迟问题和依赖更新计划方面有一个全新的世界。

有时，这种分配只是必要的。如果你想为你的 web 应用程序创建一个 API，其他人可以通过 HTTP 调用，那么你只需要解决它并处理许多这些问题（尽管处理入站请求而不是将它们发送到出站要容易得多——您的停机时间是其他人的故障状态！）。但这至少对您自己的个人发展经历造成了有限的损害。

更糟糕的是，系统过早地分解并分解为服务，甚至更糟的是微服务。这个驱动经常源于这样一种误解，即如果你想要一个现代互联网应用程序，你只需要多次构建系统：一次在服务器端，一次在 JavaScript MVC 客户端，一次用于每个本机移动应用程序等。这不是自然法则，也不必如此。

跨多个应用程序和访问共享整个应用程序的大块是完全可能的。为桌面 Web 使用与嵌入在本机移动应用程序中相同的控制器和视图。尽可能地集中在那个辉煌、雄伟的巨石中：集成系统。

所有这一切都没有在速度、用户体验或其他错误地吸引开发人员过早发布的属性方面放弃太多。

这就是我们寻求的最重要的东西：单独调整和分布式应用程序的所有功能，以及单个集成系统的易用性和理解能力。

稳定的进步

当系统已经存在十多年时，就像 Rails 一样，它们的自然趋势是趋于僵化。有上百万个理由可以解释为什么每个变化对某个依赖过去行为的人来说都是一个问题。对于个人而言，这些也是合理的理由。

但是，如果我们过于仔细地倾听保守主义的声音，我们将永远看不到另一边是什么。我们必须敢于偶尔打破和改变事物的发展和成长方式。正是这种演变将使 Rails 在未来几十年（s？）中适合生存和繁荣。

这在理论上很容易理解，但在实践中很难接受。特别是当您的应用程序从 Rails 的主要版本中向后不兼容的更改中中断时。正是在那个时候我们需要记住这个价值观，我们珍惜进步而不是稳定性，给我们力量去调试被破坏的东西，弄清楚它并与时俱进。

这不是随意造成不必要或过度伤害的许可。2.x 到 3 的大 Rails 迁移仍然在许多为此而生的人的伤痕组织中徘徊。这是一场艰难的比赛。一场严重的剧变让许多人在 2.x 领域落后了很长一段时间，有些人变得令人信服。不过，从大局来看，还是值得的。

这些是我们必须继续进行的艰难讨价还价。五年后，Rails 会因为我们今天所做的改变而变得更好吗？未来几年，Rails 是否会因为采用另一个问题领域而变得更好，比如工作队列或 WebSockets？如果是的话，那么让我们把它搞定并开始工作。

这项工作不仅需要在 Rails 本身中进行，还需要在更大的 Ruby 社区中进行。Rails 应该站在帮助 Ruby 进步的前沿，推动其成员更快地采用更高版本。

到目前为止，我们在这方面做得很好。从我开始，我们已经从 Ruby 1.6、1.8、1.9、2.0、2.1、2.2、2.3、2.4、2.5 过渡到了 2.6。在此过程中发生了许多重大变化，但 Rails 在那里得到了 Ruby 的支持，并帮助每个人更快地使用该程序。这部分是 Rails 作为 Ruby 的主要普及者的特权和义务。

对于链条的辅助工具也是如此。Bundler 曾经是一个有争议的想法，但由于 Rails 坚持认为它是共同未来的基石，今天它被视为理所当然。对于资产管道和 Spring（持久性命令过程）之类的东西也是如此。所有这三个都经历了或仍在经历成长的痛苦，但从长远来看，它们的价值显而易见，帮助我们度过了难关。

进步最终主要是关于人和他们推动变革的意愿。这就是为什么在像 Rails Core 或 Rails Committers 这样的组中没有终身席位的原因。这两个组都是为那些积极致力于为框架取得进展的人准备的。对于某些人来说，他们在这种进步中的利益可能只会持续几年，我们将永远感谢他们的服务，而对于其他人来说，这种服务可能会持续几十年。

同样，这也是我们继续欢迎和鼓励社区新成员如此重要的原因。我们需要新鲜的血液和新鲜的想法来取得更好的进展。

包容并重

有了这么多有争议的想法，Rails 可能很快就会成为一个孤立的意识形态隐士，如果我们要求每个人始终表现出对所有原则的完全尊重。所以我们不！

我们需要分歧。我们需要方言。我们需要思想和人的多样性。正是在这个想法的大熔炉中，我们将获得最好的共享资源以供所有人分享。许多人在代码或经过深思熟虑的争论中花两分钱。

因此，虽然这一学说描述了一种理想化的形式，但日常现实却更加微妙（也更有趣）。Rails 能够在一个帐篷下支持如此庞大的社区，正是因为试金石很少。

RSpec 的持续成功是我经常表达严重不满的一种用于测试的 DSL，就是完美的证明。我可以咆哮直到我在面对为什么我不认为这是要走的路时脸色发青，但它仍然可以开花和繁荣。这一点才是最重要的！

Rails 作为 API 的出现也是如此。虽然我个人的重点和奉献精神是包含视图的集成系统，但对于想要预先分发客户端和服务器的人来说，Rails 无疑有很好的空间。我们应该接受这一点，因为它可以作为次要任务共存，我相信它肯定可以。

不过，拥有一个大帐篷并不意味着要为所有人服务。这只是意味着您欢迎所有人参加您的聚会，并允许他们自带饮料。我们不需要通过提供他人加入我们而失去我们的灵魂或价值观，我们很可能会学习如何混合一两种新的美味饮料。

这不是免费的。它需要工作才能受欢迎。特别是如果您的目标不仅仅是吸引更多与社区中的人一样的人。降低准入门槛是我们应该始终认真对待的工作。

您永远不知道下一个开始修复文档中拼写错误的人何时最终实现了下一个伟大的功能。但是你有机会发现你是否微笑并说谢谢你让动力流动的任何小贡献。