logo标签列表

“魔法”有什么问题？

ruby-on-railsdjangoblack-box
36

我正试图决定是雇用 Rails 还是 Django 极客为我创建一个 Web 应用程序。有人建议我使用 Django，因为它使用的“魔法”较少。然而根据我的观察，Rails 的“魔法”似乎是一件好事，因为这可以使开发更为简洁，从而减少我的承包商所需的计费时间。我理解 Django 的优势可能在于更大的细粒度控制，但我如何知道我是否需要这种控制呢？ “魔法”存在固有问题吗？

9个回答
85

考虑一些Rails的“魔法”：当你编写一个控制器类时，它的方法可以访问某些变量和其他类。但是这些变量和类既没有在你查看的Ruby代码文件中定义，也没有被导入; Rails在后台做了很多工作，以确保它们自动出现。当您从控制器方法返回东西时，Rails会确保结果传递给相应的模板；您不需要编写任何代码告诉它使用哪个模板，找到它在哪里等等。

换句话说，就像这些事情发生了“魔法”一样；你不用抬起手指头，它们就为你自动发生。

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

Rails的开发人员认为这种“魔法”是好事，因为它使得快速启动变得更加容易，除非您想进入并开始覆盖某些东西，否则它不会让你感到无聊。

Django的开发人员认为这种“魔法”是不好的，因为它并没有真正节省多少时间（在伟大计划中，几个import语句不是什么大问题），并且会隐藏正在发生的事情，使覆盖某些内容变得更加困难或者如果出现问题则更难调试。

当然，这两种观点都是有效的，通常人们自然而然地倾向于其中之一；喜欢“魔法”的人聚集在Rails或尝试模拟它的框架周围，不喜欢的人聚集在Django或尝试模拟它的框架周围（从更广泛的意义上讲，这些立场在某种程度上有点成为Ruby和Python开发人员的典型; Ruby开发人员倾向于以某种方式做事，Python开发人员则倾向于以另一种方式做事）。

从长远来看，对于你所关注的因素——计费时间，这可能并没有太大的影响。因此让你的开发者选择他或她最熟悉的工具，这更有可能为你带来有效的结果。

37

主要问题出现在您不理解“魔法”时。这可能导致应用程序被彻底削弱，甚至出现偶发性的致命崩溃。

你能解释一下 "neutered" 吗？ - Gosuda
18
由于开发人员不知道框架提供的某个特定功能，导致应用程序未能充分发挥其潜力。 - Ignacio Vazquez-Abrams
24

魔术很棒，直到某些东西出了问题。然后，你就得想办法弄清楚所有那些戏法是如何运作的。

欲了解更多，请阅读 Joel Spolsky 的 关于漏斗抽象的定律

3
同意这个观点。这正是我对使用RoR持怀疑态度的原因，尽管我认为它是一个很棒的框架。一旦我无法使用其中的“魔法”，我就会遇到巨大的障碍。 - Wayne Molina
14

魔法混淆了功能。它隐式地创建行为，而不是明确地创建行为，这样程序员就不需要理解行为的工作原理，更重要的是，他们如何进行更改。

当程序员完全掌握他们正在处理的代码库时，“魔法”可能会带来很大的生产力提升。但是当使用像Web框架这样具有高度复杂性的第三方系统时，可能需要更长时间才能获得那种专业水平。

现在，关于你应该雇用谁来完成工作的问题：如果你担心其他程序员长期无法理解承包商的代码，那么选择Django可能是明智的选择（这肯定是我的首选）。然而，有很多Rails专家可以维护您的网站，直到未来。

选择应该取决于您正在评估的承包商中哪些人 a）有过实践经验，并且 b）值得信任。一个好的开发人员可以在Rails或Django上做得很好。

从现在开始，您认为我将更容易找到Rails专家而不是Django专家 - 有更多的Rails开发人员可供选择？ - Gosuda
不，你不会遇到找不到 Django 开发者的问题。我是说，如果你认为 Rails 开发者更加合适，那么不要让这些问题改变你的想法。我认为 Django 的设计哲学更优秀，所以如果这是你唯一的标准的话，我会选择 Django。 - Daniel Naab
11

使用魔法时...为了确保理解一个系统的一部分，你必须理解整个系统。因为很难确定你正在检查的部分是否受到魔法的影响。

这就像读故事时，作者留下了相关情节的重复，导致读者无法理解故事的全貌.

沙赞

1
我明白了。所以从长远来看，这可能会使我维护应用程序更加麻烦/昂贵，因为需要更多的“大局”理解。谢谢。 - Gosuda
就像宇宙一样，要完全理解一件事情，你需要完全理解所有东西。 - lprsd
10

"魔法"的问题在于它会将很多东西隐藏起来，让你难以追踪问题或知道该怎么做/优化，一旦你开始思考"超越框架"并陷入"死亡魔法区"(即魔法无法帮助你的部分)。

我认为这是Ruby on Rails的主要问题(不要误解，我非常喜欢Ruby on Rails)。使用它太容易了，但一旦遇到Rails无法为您完成工作或Rails的规定不符合实际情况的问题时，除非您是Ruby大师，否则您基本上就束手无策了，因为您不能再依赖魔法。由于它抽象了所有东西，所以你不知道如何用"艰苦的方式"去做。

5
魔法通常指的是“使用内置假设来优化性能或语法”。当然，在文档完备的代码中，这些假设会被明确地表述为约束条件。
有时魔法很神奇，因为它真正减少了你需要写的内容或者显著提高了速度。但你可以以无数种方式违反这些假设，要么遇到意外错误，要么更糟糕的是，出现不易察觉的错误。
4
正如Guoliang Cao所指出的那样，你总是依赖于某种“魔法”，从操作系统“神奇地”接收键盘输入并将其呈现在屏幕上的正确位置。每个Web框架都会解析发布到网页的参数，并将它们放入数据结构中以便于访问。Rails只是更加积极地使用了这些“魔法”，因为其创造者（我倾向于同意他的观点）对Web应用程序的开发有非常强烈的看法。因此，问题实际上应该是“多少魔法”是适当的，而不是是否存在固有的问题。
在使用显式魔术和隐式施法之间存在重要区别。如果我使用线程/进程等，则明确地使用该魔法提供的接口。如果某些东西隐含地使用线程，如果我不知道这一点，它可能会造成严重破坏。Ruby/Perl等语言提供了许多隐式的魔法行为，但Python这样的语言只选择显式魔法。 - DrEsperanto
3
谈到魔法，我相信Rails、Django和大多数框架都在做某种形式的魔法。它们抽象事物的方式，用API包装低级服务，集成路由和控制器等等，对于那些知道很少的人来说，这是一种魔法。我承认Rails有更多的魔法，有时人们会迷失方向。然而，我们不应该仅因此而忽视Rails。正如我所说，魔法并不是非常糟糕，只有Rails才有魔法，大多数框架都有。我们应该看到Rails正在快速发展，其代码质量越来越好，变得越来越模块化。围绕Rails的资源非常丰富，这些也应该考虑在内。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接