何时不使用框架

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

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

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

基本技能丧失的结果（有时，不使用框架的程序员被视为“过时的”）是在不需要或不适当的地方使用框架成为一种常见的做法。框架的功能有助于将结束语与基本语言的能力混淆。开发人员甚至开始使用框架来完成最基本的任务，因此曾经被视为基本过程的现在涉及具有自己的怪癖，错误和依赖关系的大型库。曾经在20行中完成的工作现在通过包含20,000行框架并编写20行以使用该框架来完成。

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

必须有一个好的指标来确定何时使用框架。你有什么考虑的门槛是，如何你决定何时，当不使用框架，或。

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

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

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

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

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

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

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

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

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

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

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

＃1 框架会节省时间和精力吗？

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

构建框架的目的是：a）向其他复杂的组件添加程序员友好的接口，或b）向已经众所周知（或已建立）的组件添加抽象。

后者（在某些情况下甚至是前者）实际上可以阻碍发展。这在您或您的编程团队将要实施他们从未使用过的新框架时尤其适用。

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

＃2应用规模

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

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

另一方面，如果一个框架在内部（例如数据库框架）做了很多肮脏的工作，那么即使您只是“部分”使用该框架，也可以实施它。一个很好的轶事就是不要尝试构建自己的ADO.NET或MongoDB驱动程序，只是因为您不需要利用整个库。

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

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

＃3影响。

有时实施框架会直接影响最终用户。对于Web应用程序尤其如此，因为拥有大型客户端框架可能会对最终用户的体验产生负面影响。使用较慢计算机的用户可能会遇到渲染速度慢，JavaScript性能问题或由低于标准计算机导致的类似问题。连接速度慢的用户可能会经历缓慢的（至少是初始）加载时间。

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

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

有些框架可能也很耗资源。

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

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

科宾·马奇总结得很好：

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

不要精英人士也很重要。框架是要使用的工具。我认识两个极端的人。一方面，您可以让自己为自己的生活变得非常艰难；另一方面，您可以让您创建缓慢而肿的应用程序。

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

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

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

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

如果（且仅当）以下条件成立，我将使用框架：

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

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

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