Ruby on Rails有什么好处？经过两个十年的编程，我使用了Rails

本文概述

• Ruby的好处
• 实用主义
• 表现力
• 社区
• 到期
• 市场行销
• (不)重新发明轮子
• 总结

有时, 我听到有人抱怨客户, 说他们坚持使用Rails, 他们有太多的Kool Aid。如果他们是招聘人员, 那么他们几乎不得不为寻找Ruby on Rails的” primadona”开发人员而感到不适。然后, 他们提出了与Git和PHP之间这种令人惊讶的无知比较相似的东西, 以证明他们的观点。他们说：”他们甚至都不知道他们要什么。”

对于作为程序员的我们来说, 有时候确实确实似乎我们的客户毫无头绪。我们喜欢夸大这种情况。当你对此稍加思考时, 认为给我钱来建造东西的人在某种程度上受到限制并且”就是没有得到”是不对的。实际上, 我相信大多数客户都知道他们的选择很好, 但他们仍然决定选择使用Rails。

我将尝试说明我认为, 什么使Rails受益匪浅, 可以认真考虑大量项目和需求。

Ruby的好处

如果不是Rails本身, 可能甚至没人会知道Ruby的好处。有些人喜欢贬低Ruby, 说它”拥有Ruby的发光骑士盔甲称为Rails, 对Ruby来说是如此简单”, 而没有Rails的话, ” Ruby则无关紧要”。我不能肯定地说那是不是真的, 但我确实知道, 如果世界错过这种精湛的语言, 那将是巨大的耻辱。事实是：Rails的作者故意选择了Ruby, 他的”疯狂”赌注引起了极大的兴趣。他当时所看到的, 今天还有许多其他人可以看到。 Ruby以某种方式使程序员能够以一种特殊的方式使程序员难以向”未洗净的群众”进行解释。那么, 为什么要使用Ruby on Rails？如所宣传的, Ruby使程序员感到高兴。

尽管大多数开发人员都认为Ruby很方便, 但有些人认为它太过方便了。他们担心Ruby允许的所有自由以及可能被滥用的一切会发生什么。让我用一些猴子补丁来说明：

"1".to_i 
#=> 1

class String
  def to_i
    raise 'foobar'
  end
end

"1".to_i 
#=> RuntimeError: foobar

就是这么简单：只需五行代码, 我们就可以使用现有的类并覆盖其行为。 Nohting是神圣的, 甚至不是String。这个特定的错误很容易发现, 但是事情变得更加险恶：

class String
  def to_i
    self.to_f - 1.13
  end
end

"2".to_i 
#=> 0.8700000000000001

就像这样, 我们在String类中引入了一个错误, 该错误可能会被复杂性逐层包裹并掩盖。

因此, 你可能会想：每个人和他们的母亲都可以弄乱我宝贵的申请吗？虽然这种行为确实看起来很吓人, 但事实并非如此。在使用Ruby的五年中, 我的行为完全没有问题。看起来似乎违反直觉, 但话又说回来, 在相反方向上以60英里/小时的速度行驶的汽车在道路中间仅被一条细白线隔开。在实践中, 两者都表现出色。

看起来似乎违反直觉, 但话又说回来, 在相反方向上以60英里/小时的速度行驶的汽车在道路中间仅被一条细白线隔开。在实践中, 两者都表现出色。

另一个好处是Ruby是一种多功能工具。因此, 它具有锋利的刀状边缘。我喜欢认为大人可以很好地处理刀子-儿童防护是为孩子们准备的(鸣叫)。而且, 在IT中像小孩子一样受到对待, 使你成为Paul Graham的Blub悖论的受害者：你认为如果没有某些你不了解的功能或有人告诉你太危险, 你会变得更好。当然, 今天我们问的是”为什么使用Ruby on Rails”？因此, 这是另外一次辩论。诚然, Ruby错过了其他语言具有的某些功能(Lisp hmm, hmm)。总而言之, Ruby接近”语言能力连续体”的顶部。

我在Ruby的头几年很谦卑。我通过阅读别人的代码学到了很多东西。有时候, 我很惊讶；有时候, 我很生气；但是最终, 这种知识使我能够比以前更有效地与计算机进行通信。我几乎为其他一些”繁文tape节”的语言而感到遗憾, 这些语言使你跳过篮球只是为了跳过它们, 同时还告诉你”我只是在做对你最有利的事情, 对你自己有利！”

实用主义

人们对以最低的最低水平编织到Rails DNA中的实用主义深表敬意。结合Ruby的优点, 这种实用主义产生了优雅的解决方案, 并鼓励/启发了Ruby on Rails开发社区这样做。实用主义通常被宣传为Rails的帐篷, 因此这种说法并不新鲜, 但是最近我被我的一位朋友试图向我展示Hibernate到底有多酷的事实提醒了它的真实性。他在挣扎。我感到非常痛苦, 因为他无法设置无数的选项和配置参数, 而这些选项和配置参数本来应该是框架默认值。

随着年龄的增长, 我对人为复杂性的标准越来越高。考虑到我在1989年11岁时就开始编写生产代码(从我在Clipper Summer ’87的隔壁邻居开始一个项目开始), 我对不必要的复杂性几乎零容忍。 Rails在那个部门的得分很高。这不仅仅是”按配置进行约定”；我说的是整个实用主义的心态, 它在Rails社区中受到高度重视并渗透到整个社区中。

表现力

Rails尽可能接近英语(除非你使用的是COBOL)。它使用所谓的内部DSL, 以自己的语义扩展Ruby。有效地开发新语言时, 构造DSL总是很危险的。由于它是内部的, 因此你无需使用外部解析器, 但从某种意义上讲, 它就像是一种新语言。 Rails团队在其DSL上取得了很好的平衡, 在合理的地方使用了DSL, 并且很少超载, 证明了出色的自我控制能力。我认为, 无论有Rails经验如何, 任何程序员(甚至是一些非程序员)都可以理解这一点：

class User < ActiveRecord::Base
  devise :database_authenticatable, :registerable

  validates_numericality_of :years_of_experience, :allow_blank => true

  acts_as_taggable
  acts_as_taggable_on :certificates, :expertise_kinds

  validates_presence_of :first_name, :last_name, :email

  has_many :translations

  has_attached_file :avatar, :styles => {:small => "240x240>"}
  has_attached_file :cv
...

实际上, 如果你不熟悉Ruby, 这可能看起来很奇怪-几乎就像它不是编程语言一样。一旦意识到这只是不带括号的方法调用, 你就可以开始了。尽管如此, Rails DSL仍然感觉到它是一种用于描述需求的特殊语言, 而实际上这只是Ruby出色语法的智能命名和固有用法。

社区

Rails拥有大量提交者, 以确保其始终处于最佳状态。许多项目随着年龄的增长而逐渐消失, 但是在使用Rails的情况下, 当需要做出决策时, 火花仍在飞舞。感觉就像维护人员仍然在乎, 并希望人们使用Ruby on Rails并了解其好处。

许多项目随着年龄的增长而逐渐消失, 但是在使用Rails的情况下, 当需要做出决策时, 火花仍在飞舞。

鸣叫

在Rails本身的下面, 首先是Ruby, 其强大的软件包管理器RubyGems在软件包数量方面可与CPAN媲美-并且考虑到CPAN的年龄, 这一说法令人印象深刻。 Rails尝试制作自己的” Rails插件”时发生了短暂的出轨。幸运的是, 这并没有发生, 因此RubyGems仍然是非常聪明的人编写的统一, 优质的代码源。

出色的语言, 实用的Web框架和精湛的社区之间的协同作用使Rails的结果比其各个部分的总和要好得多。

到期

Rails一直在街区附近。以时髦的方式, 它不再那么酷了。在选择技术堆栈时, 这是一件好事：你想要证明的东西。 Rails就是这样。我们最近写了一篇文章, 讨论了现在可用的各种Ruby解释器和运行时。

市场行销

我知道我知道。作为一名IT专业人员, 我应该真正重视”严肃的”事情, 而忽略”闪烁的事物”。它看起来似乎很浅, 但是让我们面对它：

1. 与竞争对手相比, Rails网站看起来不错。
2. 回来时, Rails的第一个屏幕投稿只是令人屏息。今天, 它看起来似乎并不那么令人印象深刻, 但请记住, 我们都知道Java的唯一原因是, 每个人都对在浏览器中运行Java Applet的可能性大为恼火。事实证明这毕竟不是那么重要, 但是仍然使Java受到关注。同样, 这个15分钟的博客引擎截屏非常受欢迎, 这使很多人兴奋。

这甚至与虚荣无关。这是关于尽可能多地吸引聪明人来为工厂加水。考虑框架时, 最好的选择就是在人群中。选择这些聪明的人关注的框架仅意味着已经为你覆盖了更多的领域。这将我带到了下一点。

(不)重新发明轮子

我对小型框架情有独钟。当我可以理解特定框架在做什么以及为什么时, 我很喜欢。从这个意义上说, Rails有点肿, 有时甚至不堪重负。

这里的难题是：你想一次又一次写相同的东西？我敢肯定, 其中一些可以更好地重写, 但这需要时间-很多时间。你允许Rails为你做的事情越多, 你就不必担心重写或重新实现功能。

Rails(正如他们所说)是”包括电池”。如果你热衷于稀疏性, 或者觉得需要全面了解一切工作原理, 那么这不是一件好事。在实践中, 如果你放开恐惧, 它似乎确实有效。 Rails几乎为你所需的所有内容提供了合理的默认值, 并且模块化程度足以避免使你陷入困境。

总结

再问一遍, 为什么要使用Ruby on Rails？ Rails适用于与Single Page JavaScript应用程序竞争的最新公共网站, 以及通常看起来有点”难看”(具有更通用, 更低保真度的UI)的复杂企业核心系统应用程序, 但可以弥补这一点带有大量复杂的业务规则和逻辑的缺陷。它的好处是它用途广泛, 能够与时尚和强大的产品竞争。

对于大多数常见问题, Rails几乎提供了一个随时可用的组件, 其文档始终高于平均水平(以某种方式, Rails核心团队说服了贡献者, 编写文档很酷(即使我们都知道而不是), 从而可以编写出精巧, 简洁且省时的文档)。

当你撇开独角兽和星期五的拥抱时, 你将得到一个强大的框架, 该框架可用于将来的游戏规则改变者和下一个中间业务站点。有了顶级的宝石库, 你的指尖便可以在计算机编程中实现一些最聪明的想法。没有大惊小怪。

相关：时间戳截断：Ruby on Rails ActiveRecord故事