“魔法”有什么问题吗？
我正在尝试决定是使用 Rails 还是 Django guru 来为我创建一个 Web 应用程序。 我被推荐使用 Django，因为它使用的“魔法”较少。 然而，从我的角度来看，Rails 的“魔力”似乎是一件好事，因为它可以使我的承包商的开发更加简洁，从而减少我的计费时间。 我知道 Django 的优势可能是更细粒度的控制，但我如何知道我是否需要此控制？ “魔法”是否存在固有的问题？
I'm trying to decide whether to use a Rails or a Django guru to create a web app for me. I've been recommended to use Django because it uses less "magic". From my perspective however, the "magic" of Rails seems like a good thing since it could make development more concise for my contractor resulting in fewer billable hours at my expense. I understand the advantage of Django might be greater fine-grained control but how will I know if I need this control? Is there an inherent problem with "magic"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
魔法是伟大的，直到有东西被破坏。 然后，你必须弄清楚所有这些技巧是如何运作的。
有关更多信息，请阅读 Joel Spolsky 的泄漏抽象法则
Magic is great until something breaks. Then, you've got to figure out how all those tricks work.
For more, do read Joel Spolsky's Law of Leaky Abtractions
魔法混淆了功能。 它隐式而不是显式地创建行为，这样程序员就不需要了解该行为是如何工作的，更重要的是，他们不需要了解如何更改它。
当编码员完全掌握他们正在使用的代码库时，“魔法”可以极大地提高生产力。 但是，当使用具有高度复杂性的第三方系统（例如 Web 框架）时，可能需要更长的时间才能获得该级别的专业知识。
现在，关于你应该雇用谁来完成这项工作的问题：如果你担心其他程序员理解你的承包商代码的长期能力，那么选择 Django 可能是有意义的（这当然是我的偏好）。 然而，有很多很多 Rails 专家可以在未来维护您的网站。
选择应该取决于您正在评估的承包商中的哪些人，a）拥有良好的业绩记录，b）您信任。 优秀的开发人员无论是在 Rails 还是 Django 上都会表现出色。
Magic obfuscates functionality. It creates behaviors implicitly instead of explicitly, such that the programmer has no need to understand how the behavior works, and more importantly, how they might go about changing it.
When a coder has a complete grasp of the code base they are working with, "magic" can be a big productivity gain. But when working with a third-party system like a web framework, which has a high degree of complexity, it may take much longer to gain that level of expertise.
Now, to the matter of who you should hire to do the job: if you are concerned about the long term ability of other programmers to understand your contractors' code, it may make sense to go with Django (it is certainly my preference). However, there are many, many Rails experts out there who can maintain your website well into the future.
The choice should come down to who among the contractors you are evaluating, a) have a proven track record, and b) you trust. A good developer will do well on either Rails or Django.
当使用魔法时……为了确保理解系统的一部分，你必须理解整个系统。 因为很难确定是否没有魔法影响您正在检查的作品。
这就像读一个故事并让作者省略相关的情节曲折，因为它们是重复的。
沙赞
When using magic... to ensure understanding of one piece of the system you must understand the whole thing. Since it's difficult to determine if no magic is affecting the piece you're examining.
It's like reading a story and having the author leave out relevant plot twists, because they're repetitive.
Shazam
“魔法”的问题在于它向你隐藏了很多东西，而且在我看来，一旦你开始“跳出框框”思考并最终陷入“死胡同”，就很难追查问题或知道该做什么/优化。魔法区”（即魔法对你没有帮助的部分）。
在我看来，这是 Ruby on Rails 的主要问题（不要误会我的意思，我真的喜欢 Ruby on Rails）； 开始使用它太容易了，然后一旦你遇到了 Rails 无法为你完成工作，或者 Rails 的约定不适合的障碍......你就完蛋了，除非你'作为 Ruby 大师，因为你不能再依赖魔法了，因为它抽象了你的一切，你不知道如何以“困难的方式”做到这一点
The problem with the "magic" is that it hides a lot of things from you, and IMO makes it harder to track down problems or know what to do/optimize once you start thinking "outside the box" and end up in a "dead magic zone" (i.e. part where the magic doesn't help you).
IMO this is the major problem with Ruby on Rails (and don't get me wrong, I really like Ruby on Rails); it's far too easy to get started with it, and then once you run into a snag where Rails doesn't do the work for you, or where Rails' conventions don't fit... you're pretty much screwed unless you're a Ruby guru because you can't rely on the magic anymore and because it abstracted everything from you, you have no clue how to do it the "hard way"
魔法通常真正意味着“使用嵌入的假设来优化性能或语法”。 当然，在有详细记录的代码中，这些假设被称为显式约束。
有时魔法是美妙的，因为它确实减少了您必须编写的内容或显着提高了速度。 但是您可能会以无数种方式违反这些假设，并且要么遇到意想不到的错误，要么更糟糕的是，出现不明显的错误。
Magic often really means "using embedded assumptions to optimize performance or syntax". Of course, in well-documented code those assumptions are mentioned as explicit constraints.
Sometimes magic is wonderful, since it really cuts down on what you have to write or dramatically improves speed. But you can violate those assumptions in countless ways, and either run into unexpected errors, or worse, have unnoticeable bugs.
正如曹国良指出的那样，您总是依赖某种“魔法”，从操作系统“神奇地”获取您的键盘输入并将其呈现在屏幕上的正确位置开始。 每个 Web 框架都会解析发布到网页的参数，并将它们放入数据结构中以便于访问。 Rails 只是对于神奇的事情更加积极，因为它的创建者（我倾向于同意他）对于如何开发 Web 应用程序有非常强烈的意见。 所以问题实际上应该是“多少魔法”是合适的，而不是它是否存在固有的问题。
As Guoliang Cao pointed out, there's always some sort of "magic" that you're relying on, starting with the operating system "magically" taking your keyboard input and rendering it on the screen in the proper location. Every web framework parses the parameters posted to the web page and puts them in a data structure for easy access. Rails is just much more aggressive about what can be done magically, since its creator (who I tend to agree with) has very strong opinions about how web applications should be developed. So the question should really be "how much magic" is appropriate, not if there's an inherent problem with it.
谈到魔法，我相信 Rails、Django 和大多数（如果不是全部）框架都在发挥某种魔法。 他们抽象事物、将低级服务包装在 API 中、集成路由和控制器等的方式，对于那些了解甚少的人来说是一种魔力。 我承认 Rails 有更多的魔力，但有时人们会迷路。 然而，我们不应该仅仅因为这个就抛弃 Rails。 就像我说的，并不是说魔法很糟糕，只有 Rails 才可以魔法，大多数都可以。 我们应该看到Rails的发展非常快，它的代码质量越来越好，并且变得越来越模块化。 Rails 周围的资源非常丰富。 这些也应该考虑在内。
Talking about magic, I believe Rails, Django and most, if not all frameworks are doing some kind of magic. The way they abstract things, wrap up low level services in APIs, integrate routes and controllers etc, are kind of magic for people who know little behind. I admit Rails has more magic and people can get lost sometimes. However, we should not dismiss Rails just because of that. Like I said, it is not that magic is very bad and only Rails does magic, most do. We should see that Rails is evolving very fast and its code quality gets better and it has become more and more modular. Resources around Rails are huge. Those should be taken into consideration too.
好吧，考虑一下 Rails 的一些“魔法”：当您编写控制器类时，它的方法可以访问某些变量和某些其他类。 但是这些变量和类既不是由您正在查看的 Ruby 代码文件中的任何内容定义也不是导入的； Rails 在幕后做了很多工作，以确保它们会自动存在。 当您从控制器方法返回某些内容时，Rails 会确保将结果传递到适当的模板； 你不必编写任何代码来告诉它使用哪个模板、在哪里找到它等等。
换句话说，就好像这些事情是通过“魔法”发生的； 你不需要动一根手指头，它们就会发生在你身上。
相比之下，当您编写 Django 视图时，您必须导入或定义您计划使用的任何内容，并且必须明确地告诉它要使用哪个模板以及模板应该能够访问哪些值。
Rails 的开发人员认为，这种“魔法”是一件好事，因为它可以更轻松地快速让某些东西发挥作用，并且不会因为大量细节而让您感到厌烦，除非您想深入了解并开始覆盖某些东西。
Django 的开发人员认为这种“魔法”是一件坏事，因为并不能真正节省那么多时间（一些
import语句在宏伟的计划中并不是什么大问题。东西），并且具有隐藏真正发生的事情的效果，使得更难弄清楚如何覆盖东西，或者更难在出现问题时进行调试。当然，这两种立场都是有效的，而且一般来说，人们似乎很自然地倾向于其中一种。 那些喜欢“魔法”的人聚集在 Rails 或试图模仿它的框架周围，那些不喜欢 Django 或试图模仿它的框架的人（从更广泛的意义上来说，这些立场有点刻板的 Ruby 和 Python）开发人员；Ruby 开发人员倾向于以一种方式做事，Python 开发人员倾向于以另一种方式做事）。
从长远来看，它可能不会对你所说的你关心的因素（计费时间）产生很大的影响，所以让你的开发人员选择他或她最舒服的任何东西，因为这更有可能得到对您有用的结果。
Well, consider a couple bits of Rails "magic": when you write a controller class, its methods have access to certain variables and certain other classes. But these variables and classes were neither defined nor imported by anything in the file of Ruby code you're looking at; Rails has done a lot of work behind the scenes to ensure they'll just be there automatically. And when you return something from a controller method, Rails makes sure the result is passed along to the appropriate template; you don't have to write any code to tell it which template to use, where to find it, etc., etc.
In other words, it's as if these things happen by "magic"; you don't have to lift a finger, they just happen for you.
By contrast, when you write a Django view, you have to import or define anything you plan to use, and you have to tell it, explicitly, which template to use and what values the template should be able to access.
Rails' developers are of the opinion that this sort of "magic" is a good thing because it makes it easier to quickly get something working, and doesn't bore you with lots of details unless you want to reach in and start overriding things.
Django's developers are of the opinion that this sort of "magic" is a bad thing because doesn't really save all that much time (a few
importstatements isn't a big deal in the grand scheme of things), and has the effect of hiding what's really going on, making it harder to work out how to override stuff, or harder to debug if something goes wrong.Both of these are, of course, valid stances to take, and generally it seems that people just naturally gravitate to one or the other; those who like the "magic" congregate around Rails or frameworks which try to emulate it, those who don't congregate around Django or frameworks which try to emulate it (and, in a broader sense, these stances are somewhat stereotypical of Ruby and Python developers; Ruby developers tend to like doing things one way, Python developers tend to like doing things another way).
In the long run, it probably doesn't make a huge difference for the factor you say you're concerned with -- billable hours -- so let your developer choose whatever he or she is most comfortable with, since that's more likely to get useful results for you.
当你不理解魔法时，主要的问题就会出现。 这可能会导致各种情况，从应用程序严重失效到零星的致命崩溃。
The primary problem occurs when you don't understand the magic. This can lead to anything from applications that are badly neutered all the way to sporadic, fatal crashes.