it-swarm.cn

什么时候不使用框架

如今,人们可以找到一种适用于几乎所有语言的框架,以适合任何项目。大多数现代框架都是相当健壮的(通常来说),具有逐小时的测试,经过同行评审的代码以及出色的可扩展性。

但是,我认为任何框架都存在一个缺点,即作为一个社区的程序员,可能会过于依赖其选择的框架,以至于他们不再了解基础工作原理,或者对于较新的程序员,他们永远也不会学习基础工作原理。首先。很容易变得专业化,以致于您不再是“ PHP程序员”(例如),而是“ Drupal程序员”,而不会包含其他任何内容。

谁在乎吧?我们有框架!我们不需要知道如何“手工完成”!对?

丧失基本技能的结果(有时将使用框架的程序员视为“过时”的程度)是在不需要框架的情况下使用框架的惯例或适当的。 features框架有助于结束与基本语言所具有的功能混淆的情况。开发人员甚至开始使用框架来完成最基本的任务,因此曾经被视为基本过程的现在涉及具有自己的怪癖,错误和依赖关系的大型库。曾经用20行完成的工作现在通过包含20,000行框架并编写20行使用该框架来完成。

相反,人们不想重新发明轮子。如果我正在编写代码来完成一些基本的,常见的小任务,当我知道XYZ框架提供了我所追求的所有功能以及更多功能时,我可能会觉得很浪费时间。 “更多”部分仍然让我担心,但是似乎没有更多的人考虑了。

必须有一个好的度量标准来确定何时使用框架。您认为阈值是什么,you决定何时使用框架,何时不使用框架。

38
Chris

“必须有一个好的指标来确定何时使用框架是合适的。”

并不是的。如果有确定适当使用任何技术的良好指标,您将不会看到语言,编辑器和方法论上的圣战。

我所合作的小组都做同样的事情-估算成本和收益,选择最有生产力的路线,并希望他们是对的。这不是非常科学的-一部分是直觉,一部分是经验,一部分是对市场的敏感性,一部分是狡猾,五部分是等级观点。

27
Corbin March

框架只是工具。我认为,如果过度使用它不是框架的错,而是过度使用它的人的错。俗话说“如果你有锤子,一切都像钉子”,表明这种思维方式早在计算机之前就已存在。

从长远来看,变得过于专业化确实会成为一个问题-对于开发人员和生物物种而言。为了长期生存,必须谨慎地平衡自己在多个领域发展技能的努力。

要回答您的特定问题,我认为没有衡量标准。当简化问题解决时,我更喜欢使用框架。如果使用框架帮助我用2行代码而不是20行代码解决问题,那么我显然会使用它。但是,即使它的20行相对于20行,我也可能决定使用一个框架,如果它能给我更好的抽象,更接近问题域,使代码更易于理解和维护。

14
Péter Török

我认为在某些情况下可能会过度使用框架,是的。框架只是工具,是的。框架使您可以非常快速地运行某些东西,因此这是一个出色的原型制作工具。

在我看来,当您的应用程序达到某种程度的复杂性时,框架中固有的限制会开始抑制进一步的增长。诀窍是识别出遇到此类引爆点的时间,然后决定要如何处理。

6
leed25d

我倾向于使用大多数Web应用程序,即使我试图变得笼统,我的回答可能不适用于您的编程领域。

我还将使用“框架”和“库”的同义词。


在实施框架之前,必须考虑一些事项,这里有一些一般示例。

#1框架会节省时间和精力吗?

这个问题的答案几乎总是。倾向于构建框架来解决特定问题并很好地解决它们。例如,诸如EntityFramework之类的框架可以为您省下完全编写SQL代码,如果您的编程团队不熟练使用SQL,那就太棒了。

框架的建立是为了a)向其他复杂的组件添加程序员友好的界面,或b)向已经众所周知(或已建立)的组件添加抽象。

后者(甚至在某些情况下甚至是前者)实际上妨碍了开发的。这适用于特别是,当您或您的编程团队打算实现一个新的框架时,他们从来没有曾经工作过。

这可能会减慢您的开发过程,并可能导致高昂的成本。

#2应用规模

据说“任何值得做的事都值得超越”,但通常并非如此。如果应用程序的重点是打印“ potato”,则可能没有充分的理由实现超大型框架

在开发应用程序(Web,桌面,移动或任何其他可能的应用程序类型)时-如果您觉得框架的规模“使”您(可能将来)的实现“相形见,”,那么这可能会很大警告标志说明您的框架可能只会使您的应用程序膨胀。一个很好的轶事是,如果您包括jQuery,则只是在文档准备就绪时将“已加载”类添加到您的正文标签中。仅使用本机JavaScript这样做可能会有点困难,但不会使您的应用程序肿。

另一方面如果框架在内部(即数据库框架)进行很多的工作很脏,那么即使只“部分”使用框架,也可以实施它一个不错的轶事是不是/尝试构建您自己的ADO.NET或MongoDB驱动程序,只是因为您不需要利用整个库。

有时,框架来自开源(并带有“随心所欲”许可)。这为编程团队仅选择框架的一部分开辟了新的可能性。

最终,这与问题1和问题3息息相关。

#3影响。

有时实现框架可能会直接影响最终用户。这对于Web应用程序尤其如此,因为拥有大型客户端框架可能会对最终用户的体验产生负面影响。计算机速度较慢的用户可能会遇到渲染速度慢,性能问题与低于标准计算机引起的javascript或类似问题。连接速度慢的用户可能会遇到缓慢的加载时间(至少是初始加载时间)。

即使在其他类型的应用程序中,最终用户也可能会受到应用程序依赖性的负面影响。框架至少总是占用一些磁盘空间,如果您正在开发移动应用程序(甚至是台式机应用程序),则可能需要考虑这一点。

服务器端框架(甚至更多特定于Web的框架)很可能不会影响最终用户,但会影响基础结构。某些框架具有本身),这可能需要您重新启动Web服务器。 ,或者完全是服务或服务器。

一些框架也可能是非常资源过多。

当然,这与点1和点2有关。


这只是一个很大的“考虑因素”,没有真正的科学方法来决定是否应该实施框架。

科宾·马奇总结得很好:

我与之合作的小组都做同样的事情-估算成本和收益,选择最有生产力的路线,并希望他们是对的。这不是非常科学的-一部分是直觉,一部分是经验,一部分是对市场的敏感性,一部分是狡猾,五部分是等级观点。

不要成为精英主义者也很重要。框架是可以使用的工具。我认识两个极端的人;一方面,您有一个让他自己过得很艰难的人,另一方面,您拥有构建缓慢,肿的应用程序的人。

所有框架都有用例,只是为了正确的目的实现它们即可。

6
die maus

其他开发人员是否知道框架?

如果所有开发人员都知道框架X,那么鉴于使用该框架的所有其他原因都是可行的,那就继续吧!对我来说,当大部分开发时间都花在学习框架的复杂性上时,强制学习特定框架没有任何意义。

关于您对不了解基础知识的新程序员的声明,您比我更有同情心!是的,这是一种耻辱,但是我是否会花时间担心别人的无能? up (基于社区的这些新成员没有立即与您合作的假设。)

4
J.K.

如果(且仅当)以下条件成立,我将使用框架:

该框架似乎可能会得到一段时间的支持。我以前让他们过了我的生命,这真令人讨厌。尤其是在您进入项目9个月时,切换不再是真正的选择。而且,如果该框架已不再受支持,则在使用该框架编写新内容之前,请三思而后行。无论您已经知道多少。

该项目实际上与框架匹配。作为一个非常古老的示例,您是否看到过MFC要做的事情?人们没有尽头让奇怪的事物适用于那些没有意义的应用程序类型。通常,在MFC上花更多的时间比在编写自己想要的应用程序上花更多的时间。

项目团队有能力在框架内工作。有些人不花时间或不花时间去理解应如何在给定框架中编写应用程序,而是以通常的方式而不是框架所需的方式来编写东西。代码和框架之间的这种不匹配通常最终会花费所有人很多时间和精力。

4
Michael Kohne