我正在尝试决定是使用 Rails 还是 Django 大师来为我创建 Web 应用程序。我被推荐使用 Django，因为它使用较少的“魔法”。然而，从我的角度来看，Rails 的“魔力”似乎是一件好事，因为它可以使我的承包商的开发更加简洁，从而减少我的计费时间。我知道 Django 的优势可能是更精细的控制，但我怎么知道我是否需要这个控制？ “魔法”是否存在固有问题？
【问题讨论】：
标签： ruby-on-rails django black-box
好吧，考虑一下 Rails 的一些“魔法”：当你编写一个控制器类时，它的方法可以访问某些变量和某些其他类。但是这些变量和类既不是由您正在查看的 Ruby 代码文件中的任何内容定义或导入的； Rails 在幕后做了很多工作，以确保它们会自动出现。当您从控制器方法返回某些内容时，Rails 会确保将结果传递给适当的模板；您不必编写任何代码来告诉它使用哪个模板、在哪里找到它等等。
换句话说，就好像这些事情是通过“魔法”发生的；您无需动动手指，它们就会发生在您身上。
相比之下，当您编写 Django 视图时，您必须导入或定义您计划使用的任何内容，并且您必须明确告诉它要使用哪个模板以及模板应该能够访问哪些值。
Rails 的开发人员认为，这种“魔法”是一件好事，因为它可以让您更轻松地快速开始工作，并且不会让您厌烦很多细节，除非您想接触并开始压倒一切。
Django 的开发人员认为这种“魔法”是一件坏事，因为并没有真正节省那么多时间（一些 import 声明在宏伟的计划中并不是什么大不了的事） ，并且具有隐藏真正发生的事情的效果，使得更难弄清楚如何覆盖东西，或者如果出现问题更难调试。
当然，这两种立场都是有效的，而且通常人们似乎只是自然地倾向于其中一种；那些喜欢“魔法”的人聚集在 Rails 或试图模仿它的框架周围，那些不聚集在 Django 或试图模仿它的框架周围的人（从更广泛的意义上说，这些立场有点刻板印象 Ruby 和 Python开发人员；Ruby 开发人员倾向于以一种方式做事，Python 开发人员倾向于以另一种方式做事）。
从长远来看，它可能不会对您所说的您关心的因素（计费时间）产生巨大影响，因此让您的开发人员选择他或她最满意的任何内容，因为这样更重要可能会为您获得有用的结果。
【讨论】：
当您不了解魔法时，就会出现主要问题。这可能会导致任何事情，从被严重绝育的应用程序一直到零星的致命崩溃。
【讨论】：
魔法是伟大的，直到某些东西破裂。然后，您必须弄清楚所有这些技巧是如何工作的。
更多信息，请阅读 Joel Spolsky 的 Law of Leaky Abtractions
【讨论】：
Magic 混淆了功能。它隐式地而不是显式地创建行为，因此程序员无需了解行为是如何工作的，更重要的是，他们无需了解如何进行更改。
当编码人员完全掌握了他们正在使用的代码库时，“魔法”可以极大地提高生产力。但是，当使用具有高度复杂性的第三方系统（如 Web 框架）时，可能需要更长的时间才能获得这种水平的专业知识。
现在，关于你应该雇用谁来做这项工作：如果你担心其他程序员理解你的承包商代码的长期能力，那么使用 Django 可能是有意义的（这当然是我的偏爱）。但是，有很多 Rails 专家可以在未来很好地维护您的网站。
选择应归结为您正在评估的承包商中的谁，a) 拥有可靠的业绩记录，以及 b) 您信任。一个优秀的开发人员在 Rails 或 Django 上都会做得很好。
【讨论】：
当使用魔法时……为了确保理解系统的一部分，你必须理解整个系统。因为很难确定是否没有魔法影响您正在检查的作品。
这就像阅读一个故事并让作者省略相关的情节曲折，因为它们是重复的。
沙赞
【讨论】：
“魔法”的问题在于它向您隐藏了很多东西，一旦您开始“跳出框框”思考并最终陷入一个“死魔法区”（即魔法对你没有帮助的部分）。
IMO 这是 Ruby on Rails 的主要问题（别误会，我真的喜欢 Ruby on Rails）；开始使用它太容易了，然后一旦遇到 Rails 不能为你完成工作的障碍，或者 Rails 的约定不适合的地方......你几乎搞砸了，除非你'重新成为 Ruby 大师，因为你不能再依赖魔法了，因为它从你身上抽象了一切，你不知道如何以“艰难的方式”做到这一点
【讨论】：
魔术通常意味着“使用嵌入式假设来优化性能或语法”。当然，在有据可查的代码中，这些假设被称为显式约束。
有时魔术很棒，因为它确实减少了您必须编写的内容或显着提高了速度。但是您可能会以无数种方式违反这些假设，或者遇到意外错误，或者更糟糕的是，出现不明显的错误。
【讨论】：
谈到魔术，我相信 Rails、Django 和大多数（如果不是所有）框架都在做某种魔术。他们抽象事物的方式，在 API 中封装低级服务，集成路由和控制器等，对于那些对背后知之甚少的人来说是一种魔力。我承认 Rails 有更多的魔力，人们有时会迷路。然而，我们不应该仅仅因为这个而放弃 Rails。就像我说的，并不是说魔法很糟糕，只有 Rails 会魔法，大多数都可以。我们应该看到 Rails 发展得非常快，它的代码质量越来越好，并且变得越来越模块化。 Rails 周围的资源是巨大的。这些也应该考虑在内。
【讨论】：
正如曹国亮指出的那样，您总是依赖某种“魔法”，首先是操作系统“神奇地”获取您的键盘输入并将其呈现在屏幕上的适当位置。每个 Web 框架都会解析发布到网页的参数，并将它们放入数据结构中以便于访问。 Rails 对可以神奇地完成的事情更加激进，因为它的创建者（我倾向于同意他）对应该如何开发 Web 应用程序有非常强烈的意见。所以问题应该是“多少魔法”是合适的，而不是它是否存在固有问题。
【讨论】：