我正在尝试决定是否使用Rails或Django大师为我创建一个Web应用程序.我被推荐使用Django因为它使用较少的"魔法".然而,从我的角度来看,Rails的"神奇"似乎是一件好事,因为它可以使我的承包商的开发更加简洁,从而减少了我的费用.我理解Django的优势可能是更细粒度的控制,但我怎么知道我是否需要这种控制？"魔术"有固有的问题吗？
好吧,考虑一些Rails"魔术":当你编写一个控制器类时,它的方法可以访问某些变量和某些其他类.但是这些变量和类既未定义也未被您正在查看的Ruby代码文件中的任何内容导入; Rails在幕后做了很多工作,以确保它们能够自动存在.当你从控制器方法返回一些东西时,Rails确保将结果传递给适当的模板; 您不必编写任何代码来告诉它使用哪个模板,在哪里找到它等等.
换句话说,就好像这些事情是通过"魔术"发生的; 你不必抬起手指,它们只会发生在你身上.
相比之下,当您编写Django视图时,您必须导入或定义您计划使用的任何内容,并且必须明确告诉它使用哪个模板以及模板应该能够访问哪些值.
Rails的开发人员认为这种"魔术"是一件好事,因为它可以让你更快地获得一些有用的东西,而且除非你想要进入并开始覆盖事物,否则不会给你带来很多细节.
Django的开发人员认为这种"魔法"是一件坏事,因为并没有真正节省那么多时间(一些import陈述在宏观方案中并不是很重要),并且具有隐藏真正发生的事情,使得更难以找出如何覆盖内容,或者在出现问题时更难调试.
当然,这两者都是有效的立场,通常看起来人们只是自然地倾向于其中一个; 那些喜欢围绕Rails或试图模仿它的框架的"神奇"的人,那些不会聚集Django的人或试图模仿它的框架(从更广泛的意义上讲,这些立场都是Ruby和Python的陈规定型观念)开发人员; Ruby开发人员喜欢以某种方式做事,Python开发人员倾向于以另一种方式做事.
从长远来看,它可能并没有对你说你关心的因素产生巨大的影响 - 可计费的时间 - 所以让你的开发者选择他或她最熟悉的东西,因为这更有可能获得对你有用的结果.
当你不理解魔法时,会出现主要问题.这可能导致从严重绝育的应用程序到零星的,致命的崩溃.
在事情发生之前,魔术很棒.然后,你必须弄清楚所有这些技巧是如何工作的.
有关更多内容,请阅读Joel Spolsky的漏涕法则
魔术混淆了功能.它隐式而不是显式地创建行为,这样程序员就不需要理解行为是如何工作的,更重要的是,他们可能会如何改变行为.
当编码人员完全掌握他们正在使用的代码库时,"魔术"可以大大提高生产力.但是,当使用像Web框架这样具有高度复杂性的第三方系统时,获得该级别的专业知识可能需要更长的时间.
现在,关于你应该聘请谁来做这项工作:如果你担心其他程序员了解你的承包商代码的长期能力,那么与Django一起使用可能是有意义的(这当然是我的偏好).但是,有很多很多Rails专家可以很好地维护您的网站.
选择应归结为您正在评估的承包商中的哪一方,a)具有可靠的跟踪记录,以及b)您信任.一个好的开发人员可以在Rails或Django上做得很好.
当使用魔法......为了确保理解系统的一个部分,你必须了解整个事物.因为很难确定是否没有魔法影响你正在检查的作品.
这就像阅读一个故事,让作者遗漏相关的情节曲折,因为它们是重复的.
Shazam的
"神奇"的问题在于它隐藏了很多东西,IMO让你更难以追踪问题,或者一旦开始思考"开箱即用"并最终陷入"死亡",就会知道该怎么做/优化魔法区"(即魔法无法帮助你的部分).
IMO这是Ruby on Rails的主要问题(并且不要误会我的意思,我真的很喜欢Ruby on Rails); 开始使用它太容易了,然后一旦遇到Rails不能为你工作的障碍,或者Rails的惯例不合适的地方......你几乎搞砸了,除非你'作为一个Ruby大师,因为你不能再依赖魔法,因为它从你那里抽象了一切,你不知道如何做到这一点的"艰难之路"
京公网安备 11010802040832号 | 京ICP备19059560号-6 