大量的框架会使程序员感到沮丧吗？[关闭]

如今，有了所有可用的框架，ORM，依赖项注入（DI），控制反转（IoC）等，我发现许多程序员正在迷失或没有解决难题所需的解决问题技能。很多时候，我已经看到意外的行为蔓延到应用程序中，并且开发人员无法真正挖掘和发现问题。在我看来，对引擎盖下正在发生的事情的深刻了解正在丢失。

不要误会我的意思，我并不是在暗示这些框架不是很好，也没有使行业向前发展，只是问开发人员是否没有获得深入了解所需的知识和技能，这是意想不到的结果系统。

同意 我目前正在开发一个受框架限制的软件包，几乎无法理解其业务。一旦框架使您脱离实际解决业务问题，而不仅仅是解决MVC，那就太过分了。如您所言，IMO许多程序员尝试使用架构师/程序来解决ORM和MVC，他们很少问这是否真的以任何方式有助于解决软件最初存在的问题。

是的，我知道在JSP页面中看到一些原始SQL 是“不可以”，但是，如果您是现场顾问，这在哪里适合特定解决方案？不，这并不意味着该框架是不正确的，并非所有客户都动20动用2万美元来确保在页面上投影一个次要数据点。

这个论点经常以许多领域和形式出现。

该参数的一般形式为：

使用[x：工具/技术]是否会使[y：受x影响的功能]的人变得更糟？

例如：

• CAD软件是否会使较差的工程师受益？
• 高中时期的计算器会使学生的数学成绩变差吗？
• 社交软件是否会阻碍人们的亲身社交技能？
• 会计软件会产生较差的会计结果吗？

从记忆中，无处不在的答案几乎总是这样：不是真的。您总会在[y]方面有好有坏的人，但现在他们在技能的另一个方面都很烂。

无论您做什么工作，对任何工作的基础知识都有更深入的了解都会有所帮助，即使是被认为是“补救性”的工作。知识总是有帮助的。

抽象是计算机编程的关键概念，框架可帮助程序员实现这一目标。这是一件好事。我怀疑我们许多人想用汇编语言开发复杂的系统！我认为，当程序员对抽象层掩盖的内容一无所知时，问题就来了。换句话说，即使您不直接与之交互或交互，也需要对幕后情况有所了解。

我记得在90年代中期，使用C和CGI（当时大多数网站仍然是静态HTML）开发了一些第一个动态网站。实际上并没有成熟的服务器端脚本语言（如PHP或ASP），并且几乎没有库，因此您必须将每个页面的整个HTTP响应流写出到服务器。解析GET和POST参数需要编写自己的库。这是乏味的，缓慢的，努力的并且非常容易出错。我一点也不会错过！

但是，我也感到像ASP.NET Web窗体之类的框架使Web的整个无状态本质抽象化了，以至于许多新的Web开发人员几乎不了解引擎盖下的实际情况。这会导致效率低下，methodology肿的代码，导致性能降低，因为开发人员使用“拖放”方法将组件组合在一起，而没有意识到HTTP级别正在发生什么。

因此，我认为框架对于开发高级软件是必不可少的，但是它们并不能免除开发人员对抽象内容的理解。是的，框架会使您愚蠢，但前提是您不了解框架。

自动变速箱或可感应雨水的雨刷器会使我们成为更差的驾驶员吗？

我认为没有框架的编码不一定意味着对底层系统有更好的理解。雇主必须在面试中问一些简单的编码问题，以确保应聘者能够采用一种连贯的方法来证明这一点。

最终，这取决于开发人员来学习。好人做，坏人不做。

同样，仅仅因为没有实际分析其功能和优点/缺点而选择框架，这也是开发实践不佳的标志。

我认为问题在于，新程序员从越来越高的抽象水平开始，因此不会暴露于“幕后”事物的点点滴滴。因此，他们没有学习一些真正的基本编码基础知识，而这是过去几年中首先学到的东西。

每当一个明显的新程序员问有关存储数据的问题时，我每次都会摇头，每个人都立即告诉他们使用ORM工具。 不，不，不，不，不...他们需要先自己学习如何做。

也许“笨拙”的分布并没有真正改变，我们只是向开发人员提供更大，更复杂的方式来射击自己？

不是让程序员感到沮丧的框架。愚蠢的程序员无论是否使用框架都将变得愚蠢。

确实，了解工具或框架可以帮助您简化的低级工作可以使您更好地使用工具和框架。您还可以更轻松地调试问题，并解决工具不可避免的功能缺陷。

例如，我在大学的Compiler Design上了一堂课，在学习使用lex和yacc之类的解析器生成器之前，我们用C从头开始编写了LR解析器。这非常有教育意义，从那时起，我对所使用的所有编程语言有了更好的理解和赞赏。

但是我并不是说每个程序员都需要花很多年的时间才能为宫城先生的汽车打蜡，然后才能允许他们进行高水平的工作。很多编程工作都是明智的，决定了软件需要做什么而不是用特定语言或工具进行编码的机械工作，而是由。

在智力工作中，聪明与愚蠢之间的关系更为重要。

引用詹姆斯·拉鲁斯（James Larus）出色的“支出摩尔的红利”（强调）：

30年前，比尔·盖茨将Altair Basic中的提示从“就绪”更改为“确定”，以节省5个字节的内存。如今，令人难以置信的是，开发人员会意识到他们程序的这一详细级别，更不用说担心它了，正确的是，因为今天如此大的变化是不明显的... 不可能我们可以生产目前的系统使用具有4K内存的机器上可能（必要）的手工制作技术。

我认为说框架会让您避免解决棘手问题所必需的技能，或者让您避免深入理解可能会误导您。相反，我们之所以能够构建当今复杂的系统（其复杂性可能会产生困难的问题并无法深入理解）的唯一原因是因为我们拥有框架（以及高级OO垃圾收集语言以及具有上下文相关帮助和功能的IDE。动态语法检查，以及所有其他软件开发的进步，这些进步有时被批评为愚蠢的程序员）。

框架很棒。但是您必须知道幕后情况。因此，问题在于程序员在没有足够的底层系统知识的情况下过于依赖框架。

MFC是一个过时的示例：程序员可以使用MFC而不是Windows API来节省大量时间，但是如果不了解API（这意味着具有使用原始API的实际工作背景），他们通常会被困。几乎从来没有发生过，因为典型的MFC程序员具有Windows API知识。

然而，Windows窗体上的.NET，多亏了更好的封装和更好的对象模型，程序员可以忽略差不多，他只用另一个Windows API的包装。因此，卡住的可能性较小，但是一旦发生，可能会造成伤害。

不幸的是，上市时间总是很短，项目也越来越复杂，因此程序员没有时间去深入研究。那是软件业的悲哀状态。

它可以将智能放置在需要的地方。人们不需要了解量子力学和牛顿物理学就可以建立一种将球从建筑物顶部掉落的机制。软件中的每个新层都应建立在最后一层之上，并从有用的应用程序构造中删除样板。

那些需要或想知道框架背后的“东西”的人将通过钩子或骗子进行研究和调查。

不，绝对不是。框架的核心是子例程库和模板以及两个久经考验的程序员工具的组合。``可怜的工人责怪他的工具...

...而且有很多贫穷的工人在使用和指责框架。

在构建软件时，框架可以节省时间。在学习构建软件时，框架会妨碍理解。

我认为问题主要出在功能过于强大的计算机之一上。对于大多数程序员来说，没有明智的理由“扎根基础”。做相同的事情只需要花费更多时间，而在运行时则没有任何有意义的区别。解决该问题的唯一方法是引入人为的限制，就像js1k这样的竞争。

也许学校应该有一个专门的主题“优化设计”，您必须在有限的时间和空间限制下建立程序？

不，学习框架可以提高程序员的技能。框架是编程语言的扩展。一些语言已经基于框架。我同时使用PHP和Java。PHP需要一个类似模板引擎的框架（有时）。Java不需要框架（大多数时候），它已经具有许多方法和库。

大多数框架将具有程序员反复使用的功能。

为了看似在这里扮演魔鬼的拥护者，我认为框架（无论如何都是“好”框架）实际上可以大大促进程序员的学习。一个设计良好的框架将解决许多问题，并且通过使用该框架，程序员可以了解正在解决的问题以及如何解决这些问题。在我看来，框架是（应该是）编程最佳实践的结晶，并且可以通过示例来教程序员。