工作好几年了，这些前端用法你真的知道吗？

最新推荐文章于 2024-04-16 02:06:31 发布

傲娇的koala

最新推荐文章于 2024-04-16 02:06:31 发布

阅读量401

点赞数

原文链接：https://u.geekbang.org/subject/fe/1000447?utm_source=wechat\x26amp;utm_medium=chengxuyuanchengzhangzhibei0514\x26amp;utm_term=wechatchengxuyuanchengzh

版权

对于大多数前端工程师来说，一直面临的问题，是从未进行过前端技术的系统学习。

我见到有一些具有多年从业经验的工程师，仍然会在看到一些用法时惊呼：“还可以这样！”

在我看来，这些用法都是一些基础的不能再基础的知识点，但是他们却浑然不知。如果深入进去了解，你会发现，表面上看他们可能是一时忘记了，或者之前没注意，但实际上是他们对于前端的知识体系和底层原理没有真正系统地理解。

那么，前端究竟怎么学？今天，跟大家聊一聊我的前端学习路线和方法。

学习路径与学习方法

首先是 0 基础入门的同学，你可以读几本经典的前端教材，比如《JavaScript 高级程序设计》、《精通 CSS》等书籍，去阅读一些参考性质的网站也是不错的选项，比如 MDN 。

如果你至少已经有了一年以上的工作经验，希望在技术上有一定突破，我想和你谈两个前端学习方法。

方法一：建立知识架构

建立自己的知识架构，并且在这个架构上，不断地进行优化。

什么叫做知识架构？我们可以把它理解为知识的“目录”或者索引，它能够帮助我们把零散的知识组织起来，也能够帮助我们发现一些知识上的盲区。当然，知识的架构是有优劣之分的，最重要的就是逻辑性和完备性。

我们来思考一个问题，如果我们要给 JavaScript 知识做一个顶层目录，该怎么做呢？

如果我们把一些特别流行的术语和问题，拼凑起来，可能会变成这样：

类型转换；
this 指针；
闭包；
作用域链；
原型链；
……

这其实不是我们想要的结果，因为这些知识点之间，没有任何逻辑关系。它们既不是并列关系，又不是递进关系，合在一起，也就没有任何意义。这样的知识架构，无法帮助我们去发现问题和理解问题。

如果让我来做，我会这样划分：

文法；
语义；
运行时。

为什么这样分呢，因为对于任何计算机语言来说，必定是“用规定的文法，去表达特定语义，最终操作运行时的”一个过程。这样，JavaScript 的任何知识都不会出现在这个范围之外，这是知识架构的完备性。

我们再往下细分一个层级，就变成了这个样子：

文法
词法
语法
语义
运行时
类型
执行过程

我来解释一下这个划分。

文法可以分成词法和语法，这来自编译原理的划分，同样是完备的。语义则跟语法具有一一对应关系，这里暂时不区分。

对于运行时部分，这个划分保持了完备性，我们都知道：程序 = 算法 + 数据结构，那么，对运行时来说，类型就是数据结构，执行过程就是算法。

当我们再往下细分的时候，就会看到熟悉的概念了，词法中有各种直接量、关键字、运算符，语法和语义则是表达式、语句、函数、对象、模块，类型则包含了对象、数字、字符串等。

这样逐层向下细分，知识框架就初见端倪了。在顶层和大结构上，我们通过逻辑来保持完备性。

如果继续往下，就需要一些技巧了，我们可以寻找一些线索。

比如在 JavaScript 标准中，有完整的文法定义，它是具有完备性的，所以我们可以根据它来完成，我们还可以根据语法去建立语义的知识架构。实际上，因为 JavaScript 有一份统一的标准，所以相对来说不太困难。

如果是浏览器中的 API，那就困难了，它们分布在 w3c 的各种标准当中，非常难找。但是我们要想找到一些具有完备性的线索，也不是没有办法。我喜欢的一个办法，就是用实际的代码去找：for in 遍历 window 的属性，再去找它的内容。

我想，学习的过程，实际上就是知识架构不断进化的过程，通过知识架构的自然延伸，我们可以更轻松地记忆一些原本难以记住的点，还可以发现被忽视的知识盲点。

方法二：追本溯源

有一些知识，背后有一个很大的体系，例如，我们对比一下 CSS 里面的两个属性：

opacity；
display。

虽然都是“属性”，但是它们背后的知识量完全不同，opacity 是个非常单纯的数值，表达的意思也很清楚，而 display 的每一个取值背后都是一个不同的布局体系。我们要讲清楚 display，就必须关注正常流（Normal Flow）、关注弹性布局系统以及 grid 这些内容。

还有一些知识，涉及的概念本身经历了各种变迁，变得非常复杂和有争议性，比如 MVC，从 1979 年至今，概念变化非常大，MVC 的定义几乎已经成了一段公案，我曾经截取了 MVC 原始论文、MVP 原始论文、微软 MSDN、Apple 开发者文档，这些内容里面，MVC 画的图、箭头和解释都完全不同。

这种时候，就是我们做一些考古工作的时候了。追本溯源，其实就是关注技术提出的背景，关注原始的论文或者文章，关注作者说的话。

操作起来也非常简单：翻翻资料（一般 wiki 上就有）找找历史上的文章和人物，再顺藤摸瓜翻出来历史资料就可以了，如果翻出来的是历史人物（幸亏互联网的历史不算悠久），你也可以试着发封邮件问问。

这个过程，可以帮助我们理解一些看上去不合理的东西，有时候还可以收获一些趣闻，比如 JavaScript 之父 Brendan Eich 曾经在 Wikipedia 的讨论页上解释 JavaScript 最初想设计一个带有 prototype 的 scheme，结果受到管理层命令把它弄成像 Java 的样子（如果你再挖的深一点，甚至能找到他对某位“尖头老板”的吐槽）。

根据这么一句话，我们再去看看 scheme，看看 Java，再看看一些别的基于原型的语言，我们就可以理解为什么 JavaScript 是现在这个样子了：函数是一等公民，却提供了 new this instanceof 等特性，甚至抄来了 Java 的 getYear 这样的 Bug。

以上就是我的前端学习路径，我介绍了两个学习方法：你要试着建立自己的知识架构，除此之外，还要学会追本溯源，找到知识的源头。

当然，学习这件事还是比较困难的，尤其是工作过一段时间以后，会遇到瓶颈而且很难坚持下来。如果你已经是一名前端工程师，并且渴望突破自己的瓶颈实现进阶，欢迎你来参加我在极客大学开设的「前端进阶训练营」。目前训练营已经开到第 2 期了，课程设计的思路是对标阿里 P6，我希望从我的经验出发，给你一些启发和帮助，并借由训练营帮你建立自己的前端知识体系，带你进阶资深前端工程师。