Ruby on Rails的缺点和警告[关闭]

这不是RoR打击的开端-老实！

我正在学习Ruby和Rails框架。从表面上看，它看上去很酷，与PHP相比，它是一种很棒的体验。（实际上，这让我想起了使用C＃和.NET的美好时光。）

但是，进入这个过程，我对这种框架或语言没有任何经验，而且我很好奇-开始时希望知道哪些当前的缺点或事情？

（也许这应该做成社区Wiki？）

这是从经验学习，继续学习以及在Rails中编写相对简单的应用程序中获得的。

1）学习曲线

Rails看似简单。这些教程，视频和书籍都展示了您可以多么迅速地获得一个正常运行的应用程序（如果很丑），但是这些实际上只是表面上的问题。他们倾向于严重依赖代码生成和“脚手架”，这在学习时固然是一个很好的工具，但很快就超过了它的用处。

毫无疑问，Rails很难掌握。一旦您掌握了最基本的知识（稍后会详细介绍），如果您需要做的事情远远超出您所吹捧的极其简单的“演示应用”功能，那么您将无所适从。您可以在学习时掌握Ruby的基本知识，但是很快就需要学习Ruby，否则，DRY如果您需要脱离Rails的限制，就会变得无所事事。

我喜欢用一种爱的方式来称呼它，Rails是用数字编程来绘画的。如果您100％遵守约定（即保持习惯并使用被告知要使用的颜色），则可以快速轻松地制作出不错的应用程序。如果并且当您不得不偏离时，Rails可以从您最好的朋友变成您最大的敌人。

2）当你所有的都是锤子时...

Rails非常擅长简化CRUD应用程序。当您的应用程序要做的不仅仅是从数据库读取/写入时，就会出现问题。现在，为了记录在案，我使用的上一个Rails版本是2.3.4，因此此后可能有所变化，但是当业务需求更改时，我遇到了主要问题，因此该应用程序必须内置一个小型工作流系统并与之集成旧版PHP应用程序。Rails的“一种形式，一种模型”约定对于琐碎的应用程序和数据输入应用程序很好用，但是当您需要执行处理逻辑，拥有工作流或不是典型的“用户将数据输入到一些文本字段，点击“提交”类型的内容。它可以做，但它绝不是“易”，或者说：这不是什么

另外，Rails不喜欢与其他未使用其首选数据访问方法的应用程序很好地兼容。如果必须与不具有“ Web 2.0”样式的API的应用程序接口，则必须解决Rails而不是与其一起使用；我再次根据经验讲，这就是发生在我身上的事情。

3）这是新的

最终，Rails在许多领域仍然是“新手”。这对于个人使用或“我认为很酷并且想学习”这种类型的场景都没有关系，但是如果您不在Rails所在的位置，请作为愿意在我的日常工作中使用Rails的人讲话作为一个Rails开发人员，要找到全职工作可能非常困难。在大多数大都市地区，它仍然主要是“ hip，新创业公司”的领域，而不是主要参与者。在这方面，您的行驶里程可能会有所不同，但是我知道我所在的区域（坦帕）的Rails本质上是不存在的。

4）火与运动

Rails不断变化。这既是好事又是坏事。这是件好事，因为社区在不断发展并接受新的概念。这很糟糕，因为社区不断发展并接受新的概念。对于Rails的新手来说，这可能是非常不堪重负的，因为通常当您遇到问题并四处张望时，您会看到有人推荐这样的宝石来修复它，或者说这种方式很不好，您不应该如果不使用它，这是一个更好的方法……您最终将获得一份额外的工具清单，以与Rails一起学习，以跟上Rails的认知。之类的东西Git，BDD/RSpec，Cucumber，Haml/Sass，以及其他各种事物的聚宝盆，它们在Rails-land成为“正确的做事方式”，并被推而广之。从经验上讲，您可能最终会被淹没，试图在 Rails 之外学习更多或更多的技术，因为使用标准的Rails工具包感觉“不正确”。

Rails 3.1现在使Sass和CoffeeScript成为所有事物的默认值，这使情况更加复杂，因此，一个总的Rails新手不仅必须学习Ruby和Rails，而且还需要Sass（如果您知道CSS的话可以说很简单）和CoffeeScript（并不疯狂，但可以肯定）至少与原始JavaScript完全不同），并且可以假定为Git。即使不考虑RSpec和朋友，以及通常会遇到的十几个或更多宝石，在认真开始编写Rails应用程序之前，您还必须学习4种不同的东西。将此与C＃，Java，甚至PHP的语言进行比较，您的HTML / CSS / JavaScript / SQL知识不会改变，您只需要学习该语言本身，也许还可以学习框架的细微差别。

文档。

尽管Rails Guides是很好的学习资源，但是Rails（通常是Ruby）库参考并不容易浏览。假设您想进一步了解belongs_to方法。尽管它用在ActiveRecord::Base子类（一个人的模型）上，但没有记录在ActiveRecord::Base文档中，而是记录在该类导入的mixin中。本质上，您看不到可以在一个位置上对一个对象使用的所有方法的完整列表（除非您启动irb并检查该对象本身）。

对于像Ruby这样的高度动态的语言，要说出您所使用的方法从何而来并不容易。这可能是个问题，特别是对于那些试图掌握新技术堆栈的学习型程序员。

Ruby on Rails具有重要的学习曲线。首先，您必须学习语言的特殊性，然后学习框架，然后学习Rails的处事方式，然后了解许多常用的Gems。

但是，当您了解了这些内容后，它的确会自然而然地出现。实际上，其他框架开始让人感到负担。

Rails非常面向TDD / BDD，因此，如果您不是这样，那么在成为合格的Rails程序员之前，您还必须学习两件事。您没有编译器和IDE来备份您，因此测试覆盖率很大程度上是您的后备。

许多TDD倡导者，包括我本人在内，都会认为这是RoR的优势之一，也是它的诅咒。一旦开始编写TDD，您会发现测试覆盖范围提供的安全性优于编译器提供的安全性。然后只需要编写代码来取悦编译器就成了负担。

TDD在RoR中感觉不像是一项额外的任务，而是唯一的工作方式。

Rails存在一个严重的性能问题：每个请求都在当前活动的请求之后排队，而不是像大多数框架那样对它们进行线程化，或者像Node.js和Twister那样允许阻塞事件释放其他请求。这意味着您必须编写代码以缩短响应时间，但是在大多数情况下这很容易做到。

Rails的设计也非常好，可以很好地处理内容系统，公平地说，这是很多Internet的内容。做一些稍微复杂的事情，例如网络游戏或电子商务系统，意味着学习新的宝石。您很快就会知道所有的宝石都在那里，但是您想要做的事情越模糊，找到好的文档就越困难。

以我的个人经验，主要的头痛是兼容性。

什么时候：

• 有x部署轨项目，
• 每个项目都使用y宝石。
• 虽然有n护栏的版本，
• 加上m已安装宝石的版本，
• 与several红宝石版本，
• 在单个Linux机器上作为生产机器。
• 程序员在另一个OS X开发笔记本上工作。

作为一个自由职业者，谁不奢侈到更新/升级大部分的东西，会面临很多的兼容性问题从上述变量...同时rails，gems和ruby不断变化/演变。

速度绝对是一个问题。Ruby的极高灵活性带来了显着的性能损失。

除了为该任务专门设计的技术外，水平缩放是一项显而易见的任务，通常要权衡简单性才能很好地进行缩放。
如果使用技术A可以处理每台计算机的请求数量是使用技术B可以处理的请求数量的100倍，那么值得考虑使用技术A，前提是您有理由相信可以在一个时间范围内从单个服务器提供数据，从而可以添加之后并行化。
2009年，仍然通过一台Web服务器提供stackoverflow 。当然，这不再是一种选择。但是我认为他们从一项技术开始就很好，该技术可以在单个实例上扩展到很多用户，而不必担心扩展。

相比之下，RoR确实很慢。处理简单请求的时间很重要，因此处理许多客户端是一个问题（这与更快的替代方法有关）。

为了模糊的定位，这里有一些数字，将适用于Web开发的其他各种语言与Ruby进行了比较：

• 走
• Clojure
• JavaScript V8（node.js）
• JRuby（一个不被遗忘的替代方法-取决于您的问题区域，JRuby可能是使Rails应用程序速度更快的更好或更坏的选择）
• 斯卡拉
• 爪哇
• C＃

请注意，这并不意味着，如果您将X框架用于Java，它将比RoR快200倍。但是，这些基准测试中测得的速度差异对应用程序的整体性能有重要影响。

Rails存在一个严重的性能问题：每个请求都在当前活动的请求之后排队，而不是像大多数框架那样对它们进行线程化，或者像Node.js和Twister那样允许阻塞事件释放其他请求。这意味着您必须编写代码以缩短响应时间，但是在大多数情况下这很容易做到。

我认为这是非常误导的。您可以在多线程模式下运行Rails。在多线程模式下运行时，应仅使用释放GIL的IO库（例如'mysql2'gem），否则它将变得毫无意义。

如果您使用的是jRuby，则只需在多线程模式下运行单个rails进程即可充分利用所有可用的CPU能力。但是，如果您使用MRI（Ruby 1.8.x或1.9.x），则必须运行多个进程才能充分利用CPU，node.js也是如此。

• Rails有很多优点，可以使您摆脱复杂性。（ActiveRecord关联，整个验证/保存生命周期，基于提供的标头的请求数据的解释）刚开始时，这很棒。随着您的成长，您会发现您开始使自己的应用适合“ Rails方式”来处理事物-有时这很好，有时这是无害的，有时实际上与您尝试做的事情背道而驰。并非所有数据库表都应建模为对象，验证步骤可能需要在其他地方进行，等等。许多Rails程序员都避免不与框架作斗争（这通常是明智的），但是这样做的长期影响是...您将把Rails的习惯带到您不一定需要的地方。

• 该社区有一种习惯，即编写被称为“魔术”的软件-缓存可以正常工作的库！先进的I / O神奇地使您更快！魔术魔术！通常这里的情况是为缺乏的技术解决方案提供了非常有吸引力的API，而您被这些漂亮的示例所欺骗，该示例可以满足您的要求，直到后来发现它涵盖了一个不完整的解决方案。这样的周期是相当恒定的，您可以学习滚动它，但是您一定应该熟悉阅读很多依赖的代码的想法（一件好事！）。我说的是，Rails社区的魔术解决方案不像自述文件所建议的那样魔术。

• 上面的推论：您使用Rails的次数越多，应该阅读的源代码越多。您对框架内部的了解越深，长期的满意度就越高。这并不是真的特定于Rails，但我只是从经验中告诉您。方法名称有时会向您承诺您实际上没有得到的东西。

• 货物崇拜是与Rails有关的一个问题，但是对于所有框架/语言社区来说，这可能是正确的。在Rails中（对我而言）似乎更明显，因此趋向于使Rails代码看起来很古怪-当您在不同的Rails项目中工作时，您会注意到某些趋向于背离创建它们的时间段。从该声明中可以猜到，社区在采用新解决方案和弃用旧解决方案方面趋向快速发展。您应该真正了解Ruby新闻，只是要了解您每天都会遇到的一些代码。

• 总体而言，我认为社区通常无法很好地解决数据并发问题-随着应用的发展，当您需要分片数据，物理回滚远程更改并锁定对数据的访问时，解决方案就变成了稍微多一点的手工调整，这会使Rails看起来不错的事情变得更加混乱，而又没有准确性的技术要求。我想我想说的是，Rails并不能解决您使用Web应用程序时遇到的所有问题，尽管创建者当然没有宣扬该信息，但很容易被愚弄以至于暗示它是隐含的。

根据您的看法，Rails更改的速度可能对您来说可能是警告，也可能不是。随着越来越多的东西从需要解决的问题中脱颖而出，情况每年都会发生根本性的变化。

如果您处于积极的开发中，那么您将全力以赴。