停止学习框架
这是一篇译文，原文在 Hacker News 上获得接近 500 个点赞。
每过几年都有类似的文章出现，然而程序员却依然疲于学习新的框架，看完此文希望对你有所启示。
那么，译文开始。
我们是程序员，每天都在了解最新的技术，每天都在学习编程语言、框架和库。
因为我们知道的现代编程工具越多越好，对吧？
不停地追随 Angular、React、Vue、Riot、Ember、Knockout 的脚步还真是一件有意思的事情呢。（译注：反话）
但这其实是在浪费时间！
时间是人类最宝贵的资源。时间是有限的、不可再生的，你可以用钱买任何东西，却买不了时间。
技术，就像时尚，在以光速在变化着。为了赶上它，我们需要跑的非常快。
但是这个跑道上没有终点，所以没有赢家。
华尔街之狼
我的导师曾经这样教我：
导师：艾德，你在做什么？
我（自豪地说）：我在读一本关于如何使用 GWT 构建现代 Java 应用的书呢。
导师：你读它做什么？
我：作为一名 Java 开发者，我需要跟上潮流。GWT 就是现在的潮流。
导师：你在读这本书之前还读过什么书？
我：我读了一本关于 Apache Tapestry 的书，那本书有 500 页。Apache Tapestry 是之前的潮流。
导师：Apache Tapestry 现在还是潮流吗？
我：不是了，GWT 才是。
导师：你之前从 Tapestry 学到的技能现在还能用吗？
我：不能用了呀。
导师：Tapestry 能帮助你更好地理解 GWT 吗？
我：不能。不过两者都用到了一些设计模式。
导师：那就是设计模式了，设计模式能帮你解决你遇到的问题吗？
我：可以，而且帮助很大。
导师：新事物来了又走，其实有很多共同点。你应该学你该学的。你应该把你 80% 的学习时间用在学习基础上，剩下 20% 的时间才是用来学习框架、库和工具的。
我：哦……只留 20% 的时间学习框架、库和工具？
导师：是的。你在工作中解决问题时自然就会学会框架、库和工具。
我：谢谢指导。
导师：你之后还会谢我的。
导师的建议改变了我的生活。我把书架上关于框架的书全部都扔了，五十本书一本不剩，扔得我很开心。
我买了一些不会过时的书，并用 80% 的学习时间来读这些书：
- 程序员修炼之道 The Pragmatic Programmer
- 代码整洁之道 Clean Code
- 程序员的职业素养 The Clean Code
- 领域驱动设计和实践 Domain-Driven Design
- 测试驱动的面向对象软件开发 Growing Object-Oriented Software, Guided by Tests
- 持续交付 Continuous Delivery
我只买了一本关于最新技术的书，是关于 Spring 的。因为根据林迪效应，学习 Spring 是一项不错的投资。
林迪效应认为，对于不会自然消亡的事物，如一项技术或一个想法，其预期寿命与其当前的生命成正比；即，只要这一事物多存活一天，就意味着其预期生寿命会更长一些。
一项技术在市场上存活得越久，就越值得我们投资（学习）它。
不要急着学习新技术，因为这些技术很可能会死。
时间会告诉你答案，你要学会等待。
十年来，我参与开发过 50 个不同的软件项目。得益于我导师的建议，我学的所有东西都适用于不同的公司、团队和领域。我的知识今天仍然有用。我没有浪费我的时间。
如果你看得更深入些，你会发现所有的软件项目都是类似的：
- 用的编程语言虽然不一样，但是设计方法是类似的。
- 用的框架虽然是不一样的，但是设计模式是类似的。
- 参与的开发者是不一样的，但是如何和这些人打交道是不变的。
记住，框架、库和工具来了又走。时间才是珍贵的。
© In Time (2011) by Andrew Niccol
将你的黄金时间用于学习通用技能，那些不会过时的技能。
- 不要学习微服务框架，学习演进式架构（Evolutionary Architecture）。
- 不要学习新的编程语言，学习代码整洁之道、设计模式、领域驱动设计（DDD）。
- 不要学习 LeSS 和规模化敏捷框架（SAFe），学习精益生产原则（Lean manufacturing principles）。
- 不要学习 Hystrix，学习容错模式（Fault Tolerance Patterns）。
- 不要学习 Docker，学成持续交付。
- 不要学习 Angular、React 和 Vue，学习 Web、HTTP 和 REST。
热门评论：
我同意你的大部分观点，但是我觉得你不用这么坚决地不学习一些东西。
「学习工具」与「学习它所蕴含的设计模式」并不互斥。
2007 年的时候我曾经试图搞清楚到底什么是「数据层」以及怎么使用它，这是当时流行的 ORM 概念。我向别人问了一堆关于 NHibernate（译注：一个面向.NET框架的对象关系映射解决方案。主要用来把对象模型表示的对象映射到基于SQL的关系模型数据结构中去）的问题，很多人都回复我说「你应该先搞清楚原理，而不是学习这个工具」。但我心里想的是，shit，不行啊，因为我需要通过大量的实践才能理解这些原理啊。这是我学习的重要途径。
所以我觉得学习这些蕴含了丰富原理的工具其实是非常有用的。
同样的道理对很多工具都适用。比如 React，如果没有 React 谁能理解虚拟 DOM 呢？
不过我基本同意你的论点，但是过分强调不要学习工具就有一点何不食肉糜的意味了。
另外，Docker 也不仅仅是持续交付，「学习新的编程语言」和「学习设计模式和 DDD」也不是互斥的，Angular 最难的部分也不是 Web 和 HTTP，最难的是学习 Angular 提供的这些傻傻的工具和工作流（我不是很喜欢这些玩意）。
作者的回复：
看来我们达成了共识——学习基础常常意味着深挖某个框架、库或者工具。框架和基础都要学习，但是优先级必须是基础高于框架。
我的观点：
假设你面前有两个应聘者，一个对框架特别熟，但是对基础知识一点都不懂；另一个对框架一点都不熟，但是基础知识特别懂。你会雇佣谁？
小公司雇佣前者，能用就行。大公司雇佣后者，能堪重任。
------------------------------------------------------------------------------------------------------------------
知乎网友热评:
当初刚从Android转前端的时候，一点基础也不会，什么html什么css，完全不懂，上手就是angular1.0，学的很痛苦，很难受，后续半年先后接触了vue和react，emmm没错，我就是框架仔。后来跳槽，我的上司告诉我，不要用框架，全部使用原生，这才让我真正感觉踏入了前端的领域。给我的实际经验就是，你从框架中学习基础，效率非常之低，当你脱离了双向绑定，脱离了全家桶，你会发现，离开框架你什么也不会。
所以就像题主说的一样，框架只是工具，我们只需要拿来用，但是真正需要学习的，是底层的原理，以及脱离框架后类似功能的实现方法。
我觉得可能从框架（或类似东西）的代码中学习基础也很有效（我很难静下心来读理论书，因为我在不使用这些基础知识的时候根本不知道他们有什么用，很枯燥）。而通过读前人的代码先了解了大多数基础知识（这往往很不全面），这时再看基础的书，就能找到共鸣了。
匿名
"把你 80% 的学习时间用在学习基础上，剩下 20% 的时间才是用来学习框架、库和工具的。" 这句是重点。换句话说可以理解为20%的时间来写业务代码，80%的时间来思考其深层的原理。
我司连续走了三名前端 都是只会用vue的 react上手上不上去 最后走的俩个前端 总会问我一些抛开框架的基础问题 而实际他们使用框架非常糟糕 我想说 我也就看了半个月react 相关的一些文档去面试 俩天看了公司使用的脚手架及其相关工具 一共八个文档 。用的时候，根本不需要太熟练，不会就看文档，基础好，学得就是快，有些人确实会用，但是真的会用吗？基础差的，一旦某些脚手架出现一些涉及看封装源码的，就懵逼了。最后jrg牛逼。
学习框架，并不是达到能用就行了，我觉得吧，框架的存在就是对主流技术的一个封装，还是有很多思想值得去学习。
就拿前端三大主流框架来说，每个框架都代表着一种开发思想，都有自己的一套技术方案，他们基本上囊括你所能想到和用到的技术，难道就不好奇他们怎么实现的吗。
要学就深入去学。
