Rails 最大的优点是 “约定优于配置。” 基本上, Rails 有很多默认的选择关于命名,位置和其他的东西。这也是为什么一个有经验的程序员使用Rails的时候会特别有生产力: 仅仅遵循着“黄金路径”,其他的一切问题都会迎刃而解 . Rails的第二个优点就是‘full stack(一般的翻译是全栈,不过我觉得保留原词比较好)’ 的特性: Rails包含你需要的一切东西。 Rails在任何方面没有想做到最小化(最小可用)。把这两个优点放到一起, Rails对于你的应用里的每样东西都作了许多假设。
但是当有很多人不需要这种默认的约定的时候会发生什么?
首先, 让我们先看一下实际上的默认的技术线。自从 Rails is omakase这篇文章发布之后, 我就称之为 ‘37signals 线路’。大体上, 这个线路包括:
还有第二条默认的技术线路出现了一段时间. 我称之为 “首选线路”. 这条线路大概的选择是:
这非常棒! 正如 David (应该是DHH,Rails的创始人)所说:
有例外是完全被允许的. 为了一些原因,其他的情况应该被允许. 所以如果你不喜环test/unit? 没问题,用你自己的rspec. 不喜欢用 CoffeeScript 作为甜点?在你的Gemfile中删掉这一行就是了.
要考虑到有不少人正在使用这样的技术路线。 所以首选线路不是规定死的非常重要: 比如你可能完全不使用Cucumber, 又或者你没有service 层. 所以重要的事情是你默认使用的选项:一大群人假设你没有使用MiniTest, 你正在使用 Rspec, 并且选择了 Cukes 或者 Capybara. 这就造成了“第二默认”影响.
多栈生态
那么意义在哪里呢? 在我继续之前, 我需要明确一件事: 我并不是在给他们排名, 或许仅仅是‘更好的选择.’ 我并不感兴趣, 至少在这篇文章里, 他们之间应该以什么顺序排名. 那是另一个问题. 在这里我想讨论的是‘第二默认栈’对整个Rails生态系统的影响。
回顾一下历史, 首选栈来自 37signals 栈. 一些人发现大多数他们使用Rails的时候都会替换掉一些东西, 所以首选栈出现了。 鉴于这是一个历史过程, 许多博客文章描述了这种变化: 以 “Waiting for a Factory Girl”为例.
但是等到! 几年以后, 你又发现有人讨论factories是糟糕的。 以我自己的文章 “ Why I don’t like factory_girl” 为例:在thoughtbot,我们跟fixtures一起使用它(factory_girl).
所以这是factories导致的结果: factories的约定让Rails测试策略和软件设计后退了两年。
也许我的用词有点强烈。 总之,首选栈也会由引发很多讨论, 很多博客文章, 还有在很多会议的发言。 每个人都喜欢争论. 如果我今年给 RailsConf 提交一个名为“Why Fixtures are :metal:”的演讲, 人们会以为我是在讽刺。 人们总是假设事情在慢慢变好: 如果一开始的建议是“使用fixtures” 然后新的建议是 “使用 Factories” 然后最新的建议就应该是 “使用另一种不是这两个的东西”… 没有可能“正确答案”是“使用 fixtures,” 对吧? 不是这样么(2007有特殊意义么)?
对于那些接触了很长时间Rails的人来说, 这种讨论是有意义并且有趣的。我可以在记忆里想起关于Factory Girl的文章, 因为我记得当它刚发表的时候我读过.在过去的六年里我写过很多Rails应用, 对于来说使用哪种技术是因为我的经历决定的。
但是对于那些今天才开始接触Rails的人呢?
初学者的困惑
今天早些有一个人对我说“在现在开始学习Rails就像从第七季开始看一个剧集” 像大多数的诙谐的语言一样,这里有真也有假。 但是, 作为一个初学者, 在37signals 栈和 首选栈之间你该怎么选择?
对我来说这就是问题所在。如果今天,你发表了一个twitter说你正在使用fixtures来开发一个Rails应用, 人们会告诉你 Stop It。 我今天早上就看见了这个事情。 这很常见, 因为相当多的Rails开发者使用首选栈, 并且对于他们选择非37signals栈的观点非常慷慨激昂。这没问题。
问题在于: 对于初学者会造成很大的负担: 他们必须学习37signals栈和可替换的。在一个人刚开始的, 基本一无所知的时候, 他们就被迫作出很多选择。 这时他们几乎不能对他们需要的东西进行正确的认识和评估并进行选择。 现在不仅仅是 “你刚刚学过Ruby了, 现在来学习 Rails吧,” 现在是“你刚刚学过Ruby了, 现在来学习Rails, RSpec和Cucumber等, 然后来使用这些我们推荐的高级建模技术吧。噢,你的唯一帮助是这些博客文章,享受你的工作吧!”
正如我在文章的一开始所说,约定优于配置是 Rails嘴的的优点。所以当一个人新开始学习Rails的时候,我们告诉他们的第一件事是做一大堆配置。任何有理性的开发者都会询问 “如果这些选项真的都这么好, 我为什么需要自己配置他们? 并且我应该选择哪个? 哦滴神啊!”
帮助大家构建更好的应用
我们希望编写更好并且更加容易维护的应用. 并且许多人(包括我)也不断的将 Rails 的 COC 等等好的观点向前推进着.但我们好像正在沙漠中慢慢偏离了方向一样.与其不断推进如何清晰区分不同技术使用的(边界定义)选择, 也许我们也同样应该帮助大家将现在已经拥有的技术变得更好.因为这两者我们都需要(新的技术与已经存在的技术的增强). 现在为了构建一个 Rails 应用, 已经有太多的东西需要去学习, 不断的添加 gems(ruby 的库) 和技术并不总是帮助.
当那些初学者慢慢熟悉了37signals栈,并且希望更多的时候, 他们就能知道哪种新技术能解决在默认的流程中哪种特定的让他们苦不堪言的问题. 但是跳过让我感觉到这种苦不堪言的痛苦,我还没有感觉到这种痛苦的时候就扔给我相应的工具,一点帮助都没有, 仅仅让我更迷惑。
我们继续研究首选栈, 但是不要在其他人还没有搞明白怎么回事之前就强求他们跟上目前演了几百集的电视剧。
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务