Rails是黑盒子吗？

Question

我最近一直在做一些简单的rails应用程序。我非常了解红宝石，但是当我开始做“铁路方式”的事情时，我注意到有些事情是“仅仅因为”，并且（铁路）新手很难知道代码的作用。

铁轨是否错过了这一点并变成某种第四代语言？我的意思是，你必须做一些事情（你不需要理解）才能开发rails网站，另一种方法是探索源代码来弄清楚它是做什么的。

我也看到人们向能够做好导航教程的人付钱......我们正在谈论一个简单起见的框架，是否需要支付好的教程？

不要误解我的意思，我相信rails已经为主流带来了非常好的想法（比如常规配置），但这种过度简化（“只是把这行代码和......它的工作原理！”）降低了简单性框架试图实现？

Answer 1

我认为这是一个透视问题。从广泛的角度来看，Rails社区已经将框架视为 的简单框架。但事实是，事实并非如此。事实上，我使用Rails的次数越多，我就越少成为一名粉丝。我不认为这是Rails的错，但我认为很多人都有这样的印象：写一个Rails是应用程序，就像挥动魔杖一样（我自己也嘲笑过kool-aid）。

Rails确实提供了许多承诺，因为它提供了许多功能，几乎不需要配置。诸如ORM，模型关系和验证之类的东西很容易设置，并且需要花费更多的时间来完成诸如微调应用程序逻辑和专注于设计之类的事情。 Rails代码也非常非常容易重新考虑。 Rails绝对可以让你用很少的代码完成很多工作。

我感到沮丧的是，当我想走出人迹罕至的道路时。我可能想要实现'非常具体的功能X'，但我找不到从哪里开始。我发现越深入到框架中，信息越稀疏。 API的部分内容严重不足。这迫使我依赖第三方插件，其中一些没有文档，并且维护得不好。我几乎停留在一篇博文中，告诉我将这些代码或代码复制到我的应用程序中，事情就会起作用（谢天谢地，他们通常会这样做）。

我的一些麻烦可能与我一般缺乏经验有关（仍然是从设计师到程序员的过渡），但我经常觉得虽然Rails提供了构建网站的优秀工具，但它至少在表面上并没有提供用于构建其他工具的强大工具。它有潜力，但你真的需要深入挖掘。

Answer 2

约定优于配置的问题是您需要知道约定。至少有一个配置文件，你有一些东西可以在开始时阅读...一旦你知道了约定，它会更快，但同时你有学习悬崖可以应对。

Answer 3

  

Rails是黑盒子吗？

Rails确实有一些“魔法代码”，你只需要写一个教程写的东西，然后神奇地工作，但它根本不是黑盒子。

1. 根据定义，“黑匣子”是你无法看到的东西。因此，您不能拥有“黑匣子”开源项目。 Here's the rails 2.1 stable source code，看看

2. 如果阅读源代码不是你的事，大多数这些“神奇功能”都有很好的文档记录并在许多网站和博客上进行了解释（如果不是，你可以随时问这里，我就是100确定你会得到一个好的回复）

3. 请记住，如果你还处于教程阶段，那么任何教程都会有很多'只需将这行代码放入'，因为他们正在尝试获取概念横跨，而不是挖掘一切的内部运作。地球上的每一个框架，不仅仅是铁轨，在他们的教程中都有“魔力”

Answer 4

我发现Rails很容易使用。您可能想要选择Agile Web Development with Rails。学习“Rails方式”对我来说是一个很大的帮助。我更多地将它用作参考而不是教程，但它会引导您完成创建应用程序并解释发生了什么。 FWIW，我比ASP.NET（我还在学习）更快地选择Rails，并且知道Rails在学习ASP.NET MVC方面有很大的帮助。

Answer 5

与任何事情一样，我认为魔鬼在细节中。是的，很容易让一个站点离开地面并将各个部分混合在一起以制造有效的东西，但是想出一个设计良好且功能强大的系统需要更深入的设计和思考。很容易开始做出错误的OO决定，例如违反Demeter的法则，因为事情很快就会组合在一起。 Rails 很容易。伟大的Rails不是。

Answer 6

我相信“了解你的惯例”不是问题。我知道如果我做X然后我有Y工作。但是X做了什么？ Rails对我来说似乎是一个黑盒子，具有讽刺意味的是当它谈到“约定优于配置”时，构建Rails应用程序的整个过程更像是配置而不是编程。

前一段时间我跟随Jruby on Rails（Ola Bini）的例子后，我有这个奇怪的例外......

  

不缺少CreateProductCategories   常量ProductType！

这是因为导轨版本不同，但重点是......一切都很好，直到你滑开黄金路径，黑盒子不再帮助你了，然后你意识到你不知道是什么你正在做所有的时间并开始在论坛/邮件列表中寻求帮助（然后你发现大多数人不知道他们在做什么或为什么，只是它有效）。

无论如何，我很高兴知道我并不疯狂，而且有些人遇到过这类问题。感谢大家。

PS：英语不是我的自然语言，所以如果你发现语法错误，请编辑它们。

Answer 7

我对rails内部的工作方式有一些小知识，我真的希望Katz为rails 3.0做的工作将使rails内部更容易理解，特别是更多的文档记录。 AFAIK，他一直在“模块/层”之间创建一些定义良好的接口，例如所有ORM共享一个公共接口，因此您不仅可以替换ORM，还可以轻松理解与rails和ORM。

对于主流观点，我认为rails是一个非常困难的框架，远远超过纯PHP。在你不理解的框架上接力有一些后果，并且学习rails内部结构并不容易，即使对于经验丰富的rubyist也是如此。

另一方面，铁轨生态系统的移动速度非常快，而且增加了另一层难度，在上个月我添加了至少3个4个宝石，而在我完全改变工作流程之前的一个月，将黄瓜添加到我的流程中。但是，我想这就是我为IT行业付出的代价。

Answer 8

我同意Bryan M。

这么多黑魔法和诡异的事情发生了，数千行代码，元元编程到处都是。

但是公平的Rails让我非常喜欢规范驱动的开发，REST和良好的Ruby理解。

现在我正处于20％的时间是平稳的，而另外80％的我花在与Rails惯例上挣扎。当我编写纯Ruby时，我感觉更有效率。

在某些时候，Merb似乎是一个选择，下一个项目我将使用Rack / Sinatra和CouchDB。

Answer 9

Pablo你可能想要研究Django，它是由一个专注于提供高质量文档作为优先事项的小组开发的。