在线公开课 | 前端工程师如何突破瓶颈更好地变现自己

课程概要

0 1

前端工程师所应具备的能力

前端相关技术

在搜索大厂对前端工程师的职位要求时，其中以下几点几乎是所有前端岗位都要求的。包括：

1. HTML/CSS及 Javascript 要熟练使用

2. 前端的三大框架 Angular/Vue/React 的熟练运用和理解

3. 一些 移动端的适配要求

其实对于一些刚毕业或者工作1、2年的同学，往往为了急于求成忽略了前端的一些基础知识，这种学习路线其实并不提倡，因为这会让你慢慢陷入为 API 工程师。

下面这张图里的两段 JS 代码，这个是在给别人做面试的时候经常会问到的一道题：这两段代码在执行流程有什么区别？

这道题可以考察 JavaScript 的很多知识点，其实代码的执行结果都是相同的，大家可以想一下。

我们知道 JavaScript 是词法作用域，所以函数的作用域在函数定义的时候就已经决定了。在 JS 中最常见的作用域有全局作用域、函数作用域，并且 JavaScript 会通过一个叫 ECS 的栈结构去管理这些上下文，我们知道栈的数据结构特点是 FILO。

当然，这道题还可以更进一步的深挖，比如关于执行上下文中包含的 变量对象(Variable object，VO)、作用域链及 this。

所以我们可以看到一段普通的 JS 代码所涉及到的知识点，你如果能把这些点去连成线，再将这些线去连成一个网，建立自己的知识体系。比你去调用框架的 API 来的有意义得多。

接下来再来看下 框架方面 。在最早之前接触前端的时候，我们用的是 AngularJS ，当时也只是调用 API 去完成任务，并不了解框架的实现原理，比如双向绑定的原理，脏检查的机制，依赖注入等等。但是，当真实代码量（ 这里说的真实代码指的不是那种一段代码经过很多次复制粘贴的那种，而是经过你思考写出来的 ）或者阅读量上来以后，对这些框架也就会有更深层次的认识。

拿 React 为例， React V16 版本推出的新的 Fiber 架构，是为了解决之前可能存在的性能问题。我们知道 React 在渲染、更新组件的时候是分两个阶段的，一个叫调度阶段 Reconciler、一个是渲染阶段。React 管之前的 Reconciler 称之为 Stack Reconciler。 Stack Reconciler 采用类似函数调用栈的策略，通过 DFS，递归遍历所有 VDOM 节点，进行 Diff。这种情况一旦开始就无法中断，要等到整颗组件树都计算完成后，才会释放主线程。那这就会出现一个问题，在极端情况下，由于组件树比较复杂，导致 React 一直占用着 JavaScript 主线程，而且我们知道 JavaScript 主线程与渲染线程是互斥的，所以这期间就会造成页面的卡顿，从而影响用户体验。

那React 团队是如何解决的？或者换做大家，可以想一想解决方案。

React 团队实际上的思路是通过将整个 Reconciler 流程拆分为好几块，每执行完一块，都会去看有没有更高优先级的任务，例如用户的操作及动画优先级就会比视图窗口外的渲染任务优先级要高。如果有高优先级的任务，则 React 会暂停渲染将控制权交还给主线程，等待有机会再继续渲染。

在浏览器上是需要 API 的支持，React 则通过重构了浏览器的RequestIdleCallback API 来兼容所有平台。这个API会使得浏览器能够在空闲时间去执行一些低优先级的任务，从而不会阻塞像动画、交互这类操作。

同时 React 在原来的 VDOM 的基础之上新加了一层数据结构。名叫 Fiber Tree，其中每节点都和 VDOM 节点对应。当然这个 Fiber 节点中包含了三个比较重要的属性， return, child, sibling ，分别指向了父节点，子节点及兄弟节点。从而形成了一个单向链表树。这使得 React 无论从哪里被打断，都可以重新回溯到整棵树。

所以，我们可以看到， 无论是框架还是什么，实现的原理，也逃不开 JS、浏览器、数据结构、算法这些基础。

计算机相关知识

前端工程师首先是工程师。前面的“前端”修饰词意味着你是偏向前端领域的工程师，用通用计算机基础知识和工程师思维解决前端行业领域内的问题。这里面尤其是网络、数据结构、算法这方面，对前端工程师的要求越来越高。

网络这方面，比如面试时经常会遇到的，常见的HTTP Code码及对应的意义、常见的 Header头、TCP三次握手四次挥手的流程，包括Https这方面。你至少能做到在Http调试的时候毫无障碍，能够轻松地看明白捕获回来的请求。推荐大家回头可以看下《图解HTTP》、《图解 TCP/IP》这两本书。

如果有一天你在面试的时候，被问到一道经典的面试题，从浏览器输入 URL 到页面加载期间发生了什么。如果你能把这些知识点答上来的话， 那肯定是加分项，况且很多面试官也未必知道。

包括算法和数据结构现在也变成重点考察的目标，因为随着前端能做的事情越来越多，一些工程化思维、逻辑思维也都是考察的一项。

多刷算法题会培养你的逻辑思维能力，同时在你写代码或者重构代码的时候，自然而然的就会想到最优解的方案。

业务拓展能力

其实大多数前端还是更偏向于业务，时间长了之后，难免会觉得枯燥，尤其是即便如此也还是需要满足一些千奇百怪的需求。如果你不能从业务中拓展相关的一些知识点，你可能仅仅只是个做需求的，就类似你已经工作了5、6年，但实际的工作经验和技能却只有1、2年······

举例来说，让你做一个单点登录的页面。并不是说你写个登录表单，发几个请求就完事儿了。其中的一些知识点，例如 SSO，SSO只是一类解决方案的统称，具体的实现可以是 OAuth、SAML 等方案，其中关于认证、授权的区别 ( Authentication/Authorisation  ) 是相对重要的概念，认证的作用在于认可你能够访问系统，用于鉴别访问者是否是合法用户；而授权用于决定你有访问哪些资源的权限。

大多数人不会区分这两者的区别，因为站在用户的立场上。而作为系统的设计者来说，这两者是有差别的，这是不同的两个工作职责。我们可以只需要认证功能，而不需要授权功能，甚至不需要自己实现认证功能。 OAuth 的本意更加倾向于授权而非认证，只不过授权用户信息也就间接实现了认证。

还有经常搞混的 Session 和 Token 的区别。因为 HTTP 是无状态的，所以要保持登录态的话，常见的做法就是 Session 或 Token ( JWT )，Session 主要是保存在服务器端，常见的是存在内存或者 Redis 中。同时会通过 Response 的 Set-Cookie 给浏览器种一个 SessionID。之后的接口请求，都会携带 Cookie ，服务器从中获取 SessionID，并去内存中查找是否有相应的合法用户。

而Token则更多的存放在客户端，通过Http的Header发送给服务端。例如现在常见的JWT，JWT的目的不是为了隐藏或者保密数据，而是为了确保数据确实来自被授权的人创建的，以防止中途篡改。服务端获取到Token后通过计算能力来验证用户的合法性。

所以Token更多的是通过服务器的计算能力去换取Session服务的存储能力，两者并没有谁对谁错。

可以看到，由一个需求能延伸出许多知识点作为你的经验。将这些知识点都融会贯通，这样你就可以通过工作时间与别人进一步的拉开距离。

非技术层面

除了写代码，作为前端工程师平常更多的是与人沟通，无论是和产品经理还是和后端研发，都需要良好的沟通能力。

而关于情商，并不是说“见什么人说什么话”，在这里情商更多的是指能够控制自己的情绪，并能够感知别人的情绪。

Emm······港真，这个问题真的是有点难呢。

比如就有同学在后台问小编：

02

前端工程师的定位

再来看下关于现代前端工程师在企业或部门中的定位。

现在的前端已经不像以前的前端，只是切个页面，写个 Web 页面，而是更多的转换成了 Web APP 。在这个过程中，一些原来需要在后端来实现的功能就可以放到前端来做。最典型的是 SPA 单页面，包括其中的路由的管理，数据状态的管理现在社区中都有相应的解决方案。所以前端能做的也越来越多。

现在有很多人都把前端定位为一个承上启下的角色，这样的定位其实还挺形象的。

向前的话可以和UED或者视觉设计师去连接，比如你们公司主要做一些中后台的项目，这些项目的特点是CRUD，比如表单、列表、详情页，这些页面往往可以抽象出一些公共的元件。这时候你可以和 UED 去共同制定一份规范和标准，这个标准可以是 字体、布局、样式及交互方式，这样慢慢的抽象出自己的公共组件、组件库甚至是业务组件库，因为基础组件应该是和业务无关的。但往往会出现一些操作是业务相关的，但又是通用的，这时候你可能通过业务组件将其封装，从而提高前端的开发效率。

向后连接的话，更多的是指与后端研发的连接。由于现在开发模式基本都是前后端分离，所以更多是通过接口、数据模型之间的交互，再由于后端目前微服务的流行，导致接口变的更加细粒度化。之前的接口可能更多的是面向视图或者页面，但现在接口更加偏向于数据模型本身，这就给前端带来了一定的复杂度。这时你可以通过在Client端及 Server中间加一层服务，来专门对数据做整合或拆分，甚至是一些业务的鉴权等。

目前最流行的方案就是通过加一层 BFF ( Backend for FrontEnd ) 去解决这些问题，当然目前是 NodeJS 最适合做这个工作，因为 BFF 消费者就是前端工程师，这一层交由前端用同一种语言来实现，会相对比较高效。同时也可以让后端更加向后关注于自己的领域。

然后是前端自身的连接，除了本身的业务，我们可以再开发流程、 工具 化、自动化等这些方面作深入探索，而且现在社区也有许多成熟的方案。比如，如果是一个团队，我们可以通过统一的编码规范，例如通过 Eslint 或者自定义一个符合你们规范的 Eslint Plugin 或者通过 GitFlow 去统一开发流程，统一规范的 Commit 及 Review 流程。

关于工具化这方面，可以通过脚手架来快速初始化一个项目，也可以将一些公共业务封装成插件。比如一些项目需要支持国际化，但这些需求往往项目开发到一定程度时才提出来的，我们知道国际化更多的是一个体力活。这时候可以通过脚本去实现自动替换，例如将 Vue 文件通过 vue-loader 解析后，通过 AST 匹配出中文提取出来形成一个 Excel 。之后也可以将翻译过后的 Excel 表格中的英文替换回来。

我们可以发现直到 NodeJS 兴起了之后，前端的工程化才算是真正开启了大门。最典型的就是构建工具这块儿，从 Grunt、Gulp 开始基于 node 环境的流程化工具的兴起，直到现在的 Webpack 和 Rollup。

关于监控，你甚至可以配合“运维大人”去搭建一套前端的监控系统，像错误监控，最简单的实现是通过监听 window.onerror 去监听 javascript 的错误栈，而且像这些框架也往往都提供了组件的错误边界，例如 Vue 对应的是 errorHandler ，React 对应的是 componentDidCatch  ，甚至是 Ajax 请求的错误也都是可以拦截的，当然这只是最简单的实现。

还有像一些性能监控，可以通过 Performance API 暴露的属性做整合。

03

京东云前端公共服务的演进

京东云前端最早的技术栈是 JQuery ，由于当时还没有形成组件化这个概念，也没有统一的规范，所以导致页面的产出效率不高。后来技术栈切换为 Vue 以后，慢慢形成了组件化的概念，与 UED 同学制定了一些统一的交互规范，包括我之前说的样式、字体、图标、交互规范等等。根据这些规范慢慢形成了符合京东云自己风格的组件。

我们通过以组件库为基础，向上衍生出了业务组件库，甚至可视化拖拽的实现。因为我们不仅是一些中后台的项目，还会有一些活动页面。这类的页面有个特点，就是上线时间紧，但往往只用一次。所以像这类的页面无需再通过 SPA 再单独搭建，而是尽可能的通过拖拽的方式快速生成页面的整体架构。从而提高效率。

这是向上的一些产出，向下我们还有自己的 BFF 层，去做数据的聚合等等。其中我们可以通过在一些内部系统，去实现一些比较新的技术栈。 比如京东云的 Open API 是标准的 REST API， 而这类 API 在前端调用的时候往往会有一些数据的冗余 ，比如我一个接口往往只需其中的一小部分数据。或者我一个页面可 能需要调用多个接口才能拿到我所需要的数据，这时候我们可以通过 Apollo 这个 GraphQL 的实现来 解决这类问题，因为我们可以通过前端去声明式地获取数据 。甚至我们通过 Apollo Link State 去替代掉现有的数据状态管理方案。 再往下，我们还有自己的一些工程化方案，例如脚手架、工具链这些。包括我们的搭建的 Sentry 监控系统，去与京东云的发布、构建系统对接。

我们计划通过以组件库为核心，能将整个前端公共服务打造成一个生态。这个也是身为一个前端所值得做的~

参考文档：