“魔法”出了什么问题？

Question

我正在尝试决定是否使用Rails或Django大师为我创建一个Web应用程序。我被推荐使用Django因为它使用较少的“魔法”。然而，从我的角度来看，Rails的“神奇”似乎是一件好事，因为它可以使我的承包商的开发更加简洁，从而减少了我的费用。我理解Django的优势可能是更细粒度的控制，但我怎么知道我是否需要这种控制？ “魔法”存在固有的问题吗？

Answer 1

好吧，考虑几个Rails“魔术”：当你编写一个控制器类时，它的方法可以访问某些变量和某些其他类。但是这些变量和类既未定义也未被您正在查看的Ruby代码文件中的任何内容导入; Rails在幕后做了很多工作，以确保它们能够自动存在。当你从控制器方法返回一些东西时，Rails确保将结果传递给适当的模板;您不必编写任何代码来告诉它使用哪个模板，在哪里找到它等等。

换句话说，就好像这些事情是通过“魔术”发生的;你不必抬起手指，它们只会发生在你身上。

相比之下，当您编写Django视图时，您必须导入或定义您计划使用的任何内容，并且必须明确告诉它使用哪个模板以及模板应该能够访问的值。 / p>

Rails的开发人员认为，这种“神奇”是一件好事，因为它可以让你更快地获得一些有效的东西，除非你想进入并开始，否则不会给你带来很多细节压倒一切。

Django的开发人员认为这种“魔法”是一件坏事，因为并没有真正节省那么多时间（一些import陈述在大计划中并不是什么大不了的事。事情），并且具有隐藏真实情况的效果，使得更难以找出如何覆盖内容，或者在出现问题时更难调试。

当然，这两者都是有效的立场，通常看起来人们自然而然地倾向于一个或另一个;那些喜欢围绕Rails或试图模仿它的框架的“神奇”的人，那些不会聚集Django的人或试图模仿它的框架（从更广泛的意义上说，这些立场是Ruby和Python的陈规定型观念）开发人员; Ruby开发人员倾向于喜欢以某种方式做事，Python开发人员倾向于喜欢以另一种方式做事。）

从长远来看，它可能不会对你说你关心的因素产生巨大的影响 - 可计费小时 - 所以让你的开发者选择他或她最熟悉的东西，因为这样更多可能会为你获得有用的结果。

Answer 2

当您不了解魔法时，会出现主要问题。这可能导致从严重绝育的应用程序到零星的，致命的崩溃的任何事情。

Answer 3

魔法很棒，直到出现问题。然后，你必须弄清楚所有这些技巧是如何运作的。

更多信息，请阅读Joel Spolsky的Law of Leaky Abtractions

Answer 4

Magic模糊了功能。它隐式地而不是显式地创建行为，这样程序员就不需要理解行为是如何工作的，更重要的是，他们可能会如何改变行为。

当编码人员完全掌握他们正在使用的代码库时，“魔术”可以大大提高生产力。但是，当使用像Web框架这样具有高度复杂性的第三方系统时，获得该级别的专业知识可能需要更长的时间。

现在，关于你应该聘请谁来做这项工作：如果你担心其他程序员能够理解你的承包商代码的长期能力，那么与Django一起使用可能是有道理的（这当然是我的偏爱）。但是，有许多Rails专家可以在未来很好地维护您的网站。

选择应归结为您正在评估的承包商中的哪一方，a）具有可靠的跟踪记录，以及b）您信任。一个好的开发人员可以在Rails或Django上做得很好。

Answer 5

当使用魔法......为了确保理解系统的一部分，你必须理解整个事物。因为很难确定是否没有任何魔法影响你正在检查的作品。

这就像读一个故事并让作者遗漏相关的情节曲折，因为它们是重复的。

沙札姆

Answer 6

“神奇”的问题在于它隐藏了很多东西，IMO会让你更难以追踪问题，或者一旦你开始思考“开箱即用”并最终知道该怎么做/优化一个“死魔法区”（即魔法无法帮助你的部分）。

IMO这是Ruby on Rails的主要问题（并且不要误会我的意思，我真的喜欢Ruby on Rails）;开始使用它太容易了，然后一旦遇到Rails不能为你工作的障碍，或者Rails的惯例不合适的地方......你几乎搞砸了，除非你'作为一个Ruby大师，因为你不能再依赖魔法了，因为它从你那里抽象了一切，你不知道怎么做“艰难的方式”

Answer 7

Magic通常的意思是“使用嵌入式假设来优化性能或语法”。当然，在记录良好的代码中，这些假设被称为显式约束。

有时候魔术是美妙的，因为它确实减少了你必须写的东西或显着提高速度。但是你可以用无数种方式违反这些假设，或者遇到意外错误，或者更糟糕的是，有不明显的错误。

Answer 8

谈论魔术，我相信Rails，Django和大多数，如果不是所有框架都在做某种魔术。他们抽象事物的方式，包括API中的低级服务，集成路线和控制器等，对于知之甚少的人来说是一种魔力。我承认Rails有更多的魔力，人们有时会迷失方向。但是，我们不应该因此而解雇Rails。就像我说的那样，并不是魔术非常糟糕，只有Rails才有魔力，大多数都是。我们应该看到Rails正在快速发展，其代码质量越来越好，并且它变得越来越模块化。 Rails周围的资源非常庞大。这些也应该加以考虑。

Answer 9

正如曹国良指出的那样，你总是会依赖某种“神奇”，从操作系统开始，“神奇地”将键盘输入并在屏幕上的正确位置渲染。每个Web框架都会解析发布到Web页面的参数，并将它们放在数据结构中以便于访问。对于可以神奇地完成的事情，Rails更加积极，因为它的创建者（我倾向于同意）对如何开发Web应用程序有非常强烈的意见。所以问题应该是“多少魔法”是合适的，而不是如果它存在固有的问题。