2019 前端年度总结

前言

从未写过年度总结，恰逢今年是变化较大的一年，因此须要有一个总结仪式。同时但愿在将来的每年都能有一次年度总结，看看当前走过的路，也回望以往的不足。毕竟，前端一世，草木一秋。javascript

关于个人年度总结，这里主要分为如下几个模块（文章篇幅很长，你们能够按需阅读）：css

技术
学习
杂七杂八
招聘
掘金

「技术」模块主要讲解这一年来自我技术方面的创新以及实践。「学习」模块会讲解 2019 的一些学习内容以及前端新认知，而且也会讲解自个人学习方法，但愿对在校以及刚入职前端工做的同窗有所帮助（鉴于不少掘友高频询问如何学习前端）。「招聘」是今年最有感触的一块，会重点讲解本身在阿里的招聘感觉，但愿对想入职阿里工做的同窗有所启迪。前端

抱歉说明：这里对掘友们说一声抱歉，在回复问题时因为工做忙碌而不够耐心（问相同问题的人太多），接下来的文章会重点针对高频问题在「学习」和「招聘」模块作一些阐述。vue

技术

今年是技术成长最多的一年，也是自我转变最快的一年。如下是本身总结的一张技术结构图，其中标红的部分是今年有所接触或深刻的部分：java

对我而言，今年技术创新的关键词是「UI 框架 / 脚手架」和「低代码（Low Code）」，技术实践的关键词是「桌面端」。node

UI 框架 / 脚手架设计

今年年初的主要工做是对基础组件库进行框架重构以及对业务组件库进行框架设计，这是自我感受最快乐的时光，由于一直不停的须要解决一些棘手的问题（每每困难是自我成长的机会点）。接下来将从如下四个方面讲解 UI 框架 / 脚手架设计的过程：react

UI 框架重构前提
基础组件库的框架重构
业务组件库的框架设计
UI 脚手架的设计

UI 框架重构前提

公司现有的基础组件库 1.x 基于 Element UI 框架进行设计，在开发的过程当中发现 Element UI 框架带来了如下一些问题（相对我司而言）：jquery

UI 源码编译的 Webpack 配置复杂
Demo 演示的 Webpack 配置复杂，且对于 UI 开发者的开发体验不够友好
Demo 演示的线上体验不够友好
Demo 演示没有 CI 自动部署能力
UI 框架的 Scripts 脚本繁多（多数是由于须要编译各类输出规范以及按需引入的能力）

友情提示：若是 UI 框架的一些能力（例如 utils、commonjs2 版本的各个组件按需引入、umd 版本）根据公司自身的状况并不须要，那么彻底能够砍掉从而大幅度简化 Webpack 配置（除非将来想要开源）。git

为了解决上述问题，对公司现有的基础组件库 1.x 版本进行了框架重构。es6

基础组件库的框架重构

首先重点研究了 Element UI 框架的设计，其次在此基础上对组件库进行了框架的重构设计，重构成 2.x 版本后的框架大体以下图所示：

从图中能够发现， 2.x 版本的 UI 组件库特性以下：

采用 Vue CLI 3.x 的库构建能力，极大简化了 UI 的 Webpack 配置（大部分配置交由 Vue CLI 官方维护）
采用 Vue CLI Plugin 设计 UI 工具插件，提供更多工具的通用性和灵活性（Vue CLI 3.x 标红的部分是自定义 UI 插件）
采用 Vuepress 1.x 进行 Demo 演示设计，极大下降了 Demo 演示的 Webpack 配置复杂性。可以使用 Vue 设计各类通用的 Demo 演示视图组件，除此以外还能够享受 Vuepress 1.x 带来的各类新特性（主题以及插件等）
UI 框架的构建能力更强，例如对浏览器的兼容性处理
UI 组件的开发统一采用 Vue 官方推荐的风格指南做为标准（ ESLint 做为标准执行的检验工具）
Webpack / Babel 编译器可跟随 Vue CLI 3.x 进行灵活升级
支持 TypeScript （UI 组件声明文件）

额外吐槽：这个过程当中遇到了贼多的坑，深刻解读了一些 Vue CLI 3.x 的源码，顺便给 Vue CLI 3.x 提出了一些 Issue。除此以外，全量接入 Vuepress 0.x / 1.x 也是一个很是辛酸的过程（连主管都去解读 Vuepress 源码了，你还有什么理由不努力）。

业务组件库的框架设计

通用业务组件库是在基础组件库的基础上，为了知足各个 BU 通用业务场景的诉求而衍生出来的组件库。各个 BU 能够单首创建本身的业务组件库，可是可能形成如下问题：

构建组件库须要成本
组件质量良莠不齐
重复造轮子且不能被其余 BU 复用
没有统一的规范约束（UED、需求、开发、构建和发布规范等）

所以构建一个跨 BU 的通用业务组件库是有必要的，但同时这个业务组件库须要符合如下特性：

基于基础组件库
有统一的收口维护人员（基础组件库核心开发团队进行整体维护）
统一的 UED、需求、开发、构建和发布规范（业务团队核心开发人员独立负责，基础组件库核心开发团队评审）
侧重提供按需加载的能力（各个 BU 反哺的通用业务组件会愈来愈多，使用时不但愿引入无关的业务组件），可提供 CLI 方式按需引入
各个业务组件的开发和维护交由业务团队独立进行，不只能够快速响应 Bug，并且构建和发布后不会影响其余业务组件，整个组件库能保持灵活性和稳定性

基于以上一些特性需求，采用了 Lerna + Vue CLI 3.x + Webpack + Babel 进行了业务组件库的框架设计：

该业务组件库在基础组件库 2.x 特性的基础上，还存在以下特性：

Webpack 配置相对基础组件库更简单（不须要针对全部的组件统一收口特殊 Loader 和 Plugin 的 Webpack 配置），各个组件库在通用配置的基础上定制化 Webpack 配置的能力便可（Babel 同理）
各个业务组件在 Lerna 的统一规范约束下有独立的开发、构建和发布流程，可以快速响应 Bug
换肤、utils、i18n 等自然成为了业务基础组件，被各个业务组件复用的同时也可被业务复用
全部业务组件的版本受到了 Lerna 总体版本的约束（不会随着响应 Bug 的修复版本越跑越乱）
通用业务组件可编译可不编译（针对使用 Webpack 的工程项目，没有特殊 Loader 理论上不建议编译）
不提供全量引入的能力、不提供 umd 能力

额外吐槽：这种按需加载的模式最好是和 Vue CLI 3.x 创建配套体系，例如业务项目的脚手架是基于 Vue CLI 3.x 设计的，那么自然能够进行无缝适配。

UI 脚手架的设计

因为 Vue CLI 3.x 提供了插件化的开发方式，因而基于业务组件库的框架设计抽离了一套 UI 脚手架，从而能够快速构建一个新的组件库。该脚手架在业务组件库的特性基础上，还存在以下特性：

一键生成：只需一个命令便可快速生成新的 UI 组件库
插件体系：除了脚手架中提供的 UI 插件之外，还能够扩展自定义插件
统一规范：在 Lerna 的约束下能够造成统一的开发、测试、构建和发布规范
响应特色：组件库的版本迭代能够更快，不须要进行总体构建，能够快速响应 Bug

固然这个 UI 脚手架的设计也存在一些缺陷：

业务开发成本提高（按需引入）
不提供 UMD 模块（针对 Webpack 工程项目）
业务项目基于 Vue CLI 3.x （可在此基础上自定义项目工程的脚手架）

经过一键命令生成的 UI 组件库结构大体以下：

.
├── packages                 		# workspaces
│   ├── alert                		# 警告（不进行 Webpack 构建）
│   │     ├── alert.vue      		# 组件源码
│   │     ├── index.js       		# npm包入口文件
│   │     └── package.json   		# npm包描述文件
│   ├── btn                  		# 按钮（进行 Webpack 构建）
│   │     ├── lib      	     		# 目标文件
│   │     │    └── lib.common.js	# npm包入口文件
│   │     ├── btn.vue        		# 组件源码
│   │     ├── index.js       		# 构建入口文件
│   │     ├── package.json   		# npm包描述文件(须要vue cli的开发态依赖)
│   │     └── vue.config.js  		# 构建配置文件
│   ├── locale               		# 国际化
│   │     ├── lang      	     	# 语言包
│   │     │    ├── enjs   		# 英文
│   │     │    └── zh_CN.js		# 中文
│   │     ├── mixins       		# 各个组件调用的国际化API
│   │     ├── src       		# 源码
│   │     ├── index.js       		# npm包入口文件
│   │     └── package.json   		# npm包描述文件
│   ├── theme                		# 样式
│   │     ├── lib      	     		# 目标文件
│   │     │    ├── alert.css   		# 警告样式
│   │     │    ├── btn.css   		# 按钮样式
│   │     │    ├── index.css   		# 整体样式
│   │     │    └── select.css		# 选择器样式
│   │     ├── src      	     		# 源文件
│   │     │    ├── utils   		# 通用方法和变量
│   │     │    ├── alert.less		# 警告样式
│   │     │    ├── btn.less   		# 按钮样式
│   │     │    ├── index.less   	# 整体样式
│   │     │    └── select.less		# 选择器样式
│   │     ├── gulpfile.js      	    	# 构建配置文件
│   │     └── package.json   		# npm包描述文件
│   └── utils                		# 工具方法
│         ├── lib       		# 目标文件（这里也能够采用lodash的方式，去掉lib文件夹这一层）
│         ├── src       		# 源文件
│         ├── babel.config.js		# 构建配置文件
│         └── package.json   		# npm包描述文件
├── public                   		# 公共资源目录
├── src                      		# 开发态目录
├── .browserslistrc                   	# UI框架目标浏览器配置
├── .cz-config.js                      	# cz定制化提交说明配置
├── .gitignore                      	# git忽略配置
├── .lintstagedrc			# lint-staged配置
├── babel.config.js			# vue cli的babel配置
├── lerna.json				# lerna配置
├── package.json			# vue cli容器描述文件（容器不是npm包）
├── postcss.config.js			# postcss配置
├── README.md				# 说明
└── vue.common.js			# 通用的组件构建配置文件
复制代码

友情延伸：专门写了一篇关于 UI 脚手架设计的文章，重点讲解了 Element UI 框架的设计原理以及 UI 脚手架的总体框架设计方案，感兴趣的同窗具体可查看 Vue CLI 3 结合 Lerna 进行 UI 框架设计。

低代码（Low Code）设计

低代码解决方案是年中的时候设计的，主要源于业务的诉求（须要注意技术都是源于业务的诉求，不要凭白造轮子）。低代码的设计主要经历了如下几个阶段（加粗的部分由其余同事实现或者和其余同事一块儿协做实现）：

动态表单可动态校验（根据 JSON 信息动态渲染表单项）
动态表单可动态发请求（表单项可动态发送请求渲染信息）
动态表单可动态级联（根据表单项的变化进行表单项的动态渲染等）
业务组件库基于 UED 规范设计通用的页面布局组件
基于页面布局组件沉淀通用页面模板能力（UED 规范以及业务反哺）
制做可一键将通用页面、依赖、菜单处理集入业务工程项目（基于通用项目脚手架）的服务工具，从而提高业务的开发效率
基于通用页面模板实现简单的动态页面渲染能力（此时的渲染 JSON 没有造成规范）
制做动态渲染的 JSON 规范（相似于 JSON Schema 规范）
制做视图渲染器，可根据规范的 JSON Schema 动态渲染页面（包括路由的跳转）

额外补充：当时视图渲染器在逻辑设计以及数据处理上没有彻底想清楚，固然后续还须要设计视图拖拽引擎，最终实现可视化低代码的设计。

除了本身参与的低代码设计，也深入学习了阿里的低代码中台产品，这个体会就深了，因为没有开源这里再也不赘述。

桌面端开发

桌面端是年底才接触的，对于桌面端的开发主要经历了如下几个阶段：

了解现有 PC 桌面端的开发框架（科普可跳过）
优化现有 PC 桌面端 CEF 的开发框架
约束 APP 开发规范

现有 PC 桌面端的开发框架

我的认知的现有 PC 桌面端的开发类型主要分为如下几种类型：

桌面客户端类型	比喻	特性
纯 Native 开发（C++、Objective-C、C#、duilib）	汽车	性能好、安装包小、XP兼容性好、开发周期长、难以实现快速迭代、跨平台开发困难
纯 Web 开发（Node.js、JavaScript）	电动车	跨平台、性能相对较差、内存占用高
Hybrid 混合开发（C++、JavaScript）	油电混合动力车	安装包大、性能相对 Native 较差，相对纯 Web 较好、复杂界面和动画效果、跨平台、可实现快速迭代、框架开源且升级快

其中涉及到 Web 前端的桌面端应用开发框架以下（这里只是作简单调研）：

客户端开发框架	类型	特性	应用
Nw.js	纯 Web 开发	内存占用高、支持XP 系统、启动速度、性能较差	DingTalk、Mongo Management Studio、Soundnode
Electron	纯 Web 开发	不支持 XP 系统（定制低版本能够）、最低支持 Win 7（2B/2G 有必定的量）、与 Native UI 框架融合难度高	Atom、Visual Studio Code、Skype
Chromium Embedded Framework(CEF)	Hybrid 混合开发	基于 Google Chromium 项目开源（兼容性好）、支持 XP 系统、可方便定制和融合 Native UI 框架、内存占用等性能良好	DingTalk、有道、网易云音乐、Github

开发纯 Native 应用的成本较高，通常对性能要求极高的产品才会选择此类开发方式。一般而言，从开发成本、操做系统兼容性、跨平台能力、UI 效果以及产品的迭代速度等方面而言，采用纯 Web 的开发方式是大部分公司都会选择的高性价比开发方式。固然像 DingTalk 这样的产品在考虑总体性价比时选择 Hybrid 混合开发是一种很是高效的迁移方案（不只能够提高产品的性能，实现部分高性能需求的 UI Native 化，还能够从 Nw.js 进行部分应用的平稳迁移）。

优化现有 PC 桌面端的 CEF 开发框架

公司现有的桌面端应用采用 CEF 多容器隔离的框架进行设计，大体的框架图以下所示：

从图中能够发现，经过 CEF 多容器隔离，每个应用均可以被理解为一个独立的 SPA 应用（多容器隔离能够简单理解为多页应用）。那么这个框架所产生的问题以下：

Webpack 多入口配置复杂（单个工程项目结构）
开发须要额外的配置（例如开发启动应用过滤等）
受到总体框架的约束，新增的应用很难升级语言新特性（例如 React）
应用愈来愈多，工程项目愈来愈臃肿，总体愈来愈难以维护
应用没有本身的开发规范，不利于协做维护
总体构建速度慢，且容易致使构建的不稳定性（单个应用更新每每也须要进行总体构建）

为了解决以上问题，构思了新的框架设计进行桌面端开发：

Webpack 单入口配置（各个应用由通用脚手架生成新的工程项目，新增的应用不须要额外进行 Webpack 多入口配置）
新增脚手架且对应用进行规范约束（脚手架是同事作的）
新增应用可随着脚手架升级语言新特性
解耦公共服务，造成 npm 包独立维护体系，并造成开发文档提高开发体验（未完成）
解耦业务组件库，造成 npm 包独立维护体系，并造成开发文档提高开发体验（未完成）
应用单独构建且构建速度快，构建总体应用包时稳定性高，可造成局部构建能力（测试期间可进行局部构建测试）
一键 CLI 整合总体应用包（未完成）

友情提示：这里的公共服务不少，例如还包括 Native API、本地存储、TypeScript 公共类型定义等。

约束应用的开发规范

脚手架只是约束了应用的技术栈（包括开发、校验、构建和测试流程等），除此以外还须要约束工程项目内部更加细致的开发规范，后续更利于多人协做和维护。这里对每一个应用的开发作出了以下的规范约束（2 个月的 React 开发经验提出的规范，若是不够完善请你们多多补充）：

友情提示：若是是 React Hooks 开发（React Hooks Redux），能够去除应用视图 / 容器。应用视图 / 业务是按照业务模块进行划分（能造成必定的通用性更优）。应用视图 / 容器和应用视图 / 业务造成一一对应关系，除了担任控制器的做用，还能够起到跨业务模块通讯的能力。应用视图 / 布局可快速适应应用视图 / 业务模块的需求变化，造成新的布局能力。若是是 TypeScript 开发，那么应用视图层级建议平铺，不然会形成Props 多层级传递的声明冗余（固然 TypeScript 声明应该按照应用视图 / 容器进行继承划分，传递 Props 的时候声明会变的更加清晰简洁）。

学习（针对新人，大佬跳过）

2019 学习

对我而言，今年学习实践的关键词是「Vue 2.x 以及 Vue CLI 3.x 源码解读」、「算法学习」和「重拾 React 」。学习认知的关键词是「Graphql & BFF」、「中台」、「微前端」和「Serverless」。

源码解读

不少人可能对于源码解读会产生必定的误解，他们的认知每每是这样的：

源码这么难根本读不懂
看了源码也没什么卵用
反正我不是大佬学不学也无所谓
框架嘛只要能用就行，学那么多干吗，除非须要面试造火箭

可是当他们遇到稍微难以解决的问题时每每是这样的：

为何这样写不对呀
为何个人代码写出来性能有问题
这个功能应该怎么作呢
为何我连一个像样的 UI 组件都写很差
页面上报了一堆的黄色真香警告但却读不懂是什么操做太秀了致使的

源码解读固然是为了让你更了解你所使用的框架，从而让你能够快速定位技术 / 业务问题从而高效的解决问题，快速设计解决业务的可行方案以及设计一些通用的技术方案等等。可是源码解决每每确实是复杂困难的，通常个人作法以下：

根据错误堆栈信息进行源码跟踪，造成单点理解源码的能力（不要动不动一遇到错误就慌了，能够根据错误的堆栈信息比别人多走几步，静下心来调试进去看看，里面究竟是什么花）。这样在解决技术或业务问题的同时就造成了源码的解读能力，并且每每能够聚沙成塔。同时若是这个问题刚好是源码的问题，你还能够给官网提 Issue 或 Pull Request，对框架进行一波反哺
若是额外有时间，能够了解一些源码的框架（好比源码是由几大模块组成的），而后本身尝试理解框架的流程
根据框架进行模块拆分（例如从 Vue 的角度出发，包括数据劫持、视图解析、Diff 更新等），尝试一个模块一个模块去理解框架源码（此时本身能够进行手动调试代码或者本身模拟一下如何实现，或者若是确实不知道怎么解读也能够尝试查看一些优秀的源码分析博客）
造成总体的框架源码理解（若是有条件能够尝试写一个简化的框架）

友情提示：这里附上个人 Vue 源码解读实践文章基于Vue实现一个简易MVVM 以及 JQuery 源码分析（JQuery 源码分析是我实习的时候参考《锋利的jQuery》/《jQuery技术内幕》/《JavaScript高级程序设计》/《JavaScript权威指南》一行行代码调试而且一行行注释解读出来的，加了不少对于 JavaScript 基础知识的理解。那个时候时间较多，纯粹是一件既笨又无聊还低效且须要耐心坚持的事情，大概花了几个月的时间，若是是技术小白仍是建议能够看看的）。

算法学习

算法学习是从面试中萌发出来的念头。当时参加有赞面试被算法题按在了地上摩擦，决定好好从新学习一下算法。 I-Algorithms 是参考了《算法导论》/ javascript-algorithm / CLRS 打造的一个简单易懂的 JavaScript 算法学习教程文档。固然这一块中途被放下了，由于从新入职后根本没时间......不事后面等我适应了阿里的工做，我仍是会重拾这一块的，感兴趣的同窗能够查看一下，目前学习的内容以下：

第一章：算法基础

插入排序
插入排序习题
分析算法
分析算法习题
归并排序
归并排序习题

第二章：函数的增加

渐进标记
渐进标记习题
经常使用函数
经常使用函数习题

友情提示：感兴趣的同窗能够查看 Github 仓库的算法学习介绍 I-Algorithms（自己这个项目也有值得小白学习的地方哦），也能够查看文档的线上学习地址 I-Algorithms。

重拾 React

这个就没多少能够说的余地了，2016年实习的时候正好搞过 React SSR （那时候连一行 JQuery 都不会写。因为以前是作嵌入式开发，相对于转学 React 不算是什么困难的事情，把官网过了一遍从新回忆了一下 React，简单基于 Create React App ( Vue CLI 3.x 的插件系统真香)写了一个 React 教程了解一下 React 周边，主要包括了（也是半途而废）：

建立应用程序
设置编辑器
集成开发工具
样式设置
组件引入
React Redux（配合 Rxjs、 immutability-helper、简易实现带中间件的 React Hook Redux 等）
React 调试工具

如下是半途而废的部分

路由解决方案（搞了一半）
React 语法
React Static
React Next

那这里遇到一些从 Vue 转 React 或者二者都会的面试者时，我每每会问他们对于这两个框架的见解，其实这种问题每每只是想听听他们的理解而已。那对于我而言，React 和 Vue 相比：

汽车手动挡和自动挡的区别（手动挡开车更危险，自动挡开车更耗油）
React 相对于 Vue （2.x 版本）对 TypeScript 的支持确实更友好
React 确实更考验开发者的编码功底
React 框架自己的学习成本确实更低且框架的语法更稳定（若是不算周边生态）

友情提示：若是是 Vue 开发者想尝尝 React 的鲜，能够看看我写的这个仓库 React-Tutorial（半途而废系列）。

我是如何学习前端的

鉴于不少加个人掘友都高频询问前端应该如何学习，我这里额外将之前学习前端的方法列举一下，供掘友们参考。个人学习方法大体分为如下几个过程：

书籍
笔记
文档（英文）
博客

友情提示：笨鸟先飞。

书籍

若是想要系统的学习一个专业，那么确定是须要静下心来花时间系统的学习跟这个专业相关的任何基础知识，书籍固然是最好的途径。我这里将以前学习的书籍列举一下，大概以下图所示：

友情提示：读书是很花时间的，若是你以为本身静不下心来读书，我以为看看视频也是不错的。若是你静的下心来读书，那就好好读几本本身欠缺的书籍。固然除了一些技术书籍，日常也应该注意阅读一些可以改善思惟的书籍（辛亏小时候养成了阅读文学做品的好习惯）。

笔记

好记性固然不如烂笔头，有些书你读着读着就变得难以理解，或者你读着读着就忘记了。这个时候最笨但最有效的方法是边读边实践边记录。记录和实践的过程一方面能够帮助你理解书中的阐述，另一方面固然也能够帮助你往后快速回忆书本的大体内容（尤为是面试前特别管用），达到抛开书本提取精华的目的。这里我将我以前的笔记整理出来供你们参考：

jquery2.0.3源码分析笔记 - 参考《锋利的jQuery》/《jQuery技术内幕》/《JavaScript高级程序设计》/《JavaScript权威指南》
ES6学习笔记 - 参考《ES6标准入门》
设计模式 - 参考两本《JavaScript设计模式》
JS类和继承 - 参考《ES6标准入门》/ 《JavaScript高级程序设计》/《JavaScript权威指南》
如何使JS提升运行性能 - 参考《高性能JavaScript》
算法导论与javascript实现 - 参考《算法导论》/《数据结构与算法JavaScript描述》/ javascript-algorithms / CLRS - 【进行中】
数据结构和算法 - 参考《数据结构与算法JavaScript描述》
CSS权威指南 - 参考《CSS权威指南》
CSS世界 - 参考《CSS世界》/《CSS权威指南》
精通CSS - 参考《精通CSS：高级WEB标签解决方案》
HTTP协议分析 - 参考《图解HTTP》
正则表达式 - 参考《精通正则表达式》- 【进行中】

如下是早期的笔记（很 Low 的 Word 文档），可是有好几百页几万字的那种（如今本身看看都蛮佩服本身的），那时候还不知道用 MD 格式：

JavaScript高级程序设计 - 参考《JavaScript高级程序设计》
JavaScript权威指南 - 参考《JavaScript权威指南》

友情延伸：ziyi2/awesome-front-end 是本身整理的一个前端大杂烩，除了笔记、书籍和博客以外，还有我珍藏多年的书签（不定时更新）。

文档（英文）

文档部分主要强调的是阅读能力和书写能力：

阅读能力：这里须要强调的是培养本身阅读英文文档的能力（尽可能阅读官方文档，除非你很难看懂文档到底说了什么）。若是你以为阅读比较吃力能够配套一些 Chrome 翻译插件（例如 Google 翻译）。一般在研究一些新技术的时候须要阅读一些官方文档（这些文档大比例都是英文文档，并且通常状况下英文文档的更新会比中文文档更新的更快），因此阅读英文文档是一个很是重要的能力。 书写能力：书写文档能力是一种很是很是很是重要的能力，它能够很大程度上减小设计和沟通成本（防遗忘 / 防重复说明等）。固然书写规范也是很重要的，你能够参考一些开源做品的官方文档书写风格，也能够参考一些特定的书写规范（例如阮一峰的中文技术文档的写做规范）。固然写文档也须要养成实时更新的好习惯，不然过期的内容反而会致使设计和沟通成本的提高。

友情延伸：若是公司可以使用语雀，推荐语雀做为技术文档产品是一个不错的选择。若是不能使用外部产品，能够自行创建文档预览站点，例如使用 VuePress / React Static 等。

博客

写技术博文是今年开始才真正养成的习惯，虽然本身曾经有一个博客站点 www.ziyi2.cn，但其实更多的是记录一些学习笔记或者生活。今年开始在 Github 上使用 Issue 书写技术博客（之前总以为要有一个本身的域名站点且网页要酷炫，如今是真的以为要好用且实在，不搞花里胡哨的东西）：

使用 Github 记录博客的好处是你能够关联给三方库提的 Issue，也能够博文之间互相关联，还能够去实时评论和关闭 Issue。固然玩法只会更多（例如基于 Issues 生成静态站点等），对于我来讲这些功能就够了（以前看到一篇写的很是好的 Github Issue 博客教程，暂时找不到了）。

差很少上面截图的文章是我今年产出的全部博客文章（下半年换公司后只在公司的内部站点发表了一篇文章），若是对其中某些博文感兴趣的同窗能够查看 Ziyi2 Github Issues。

杂七杂八

跳槽

其实今年原本没有想过跳槽，只是以为到明年年中就工做三年了（三年经验比较好换工做，且确实本身想换个离家近一点的公司，阿里固然成了首要目标），今年能够先出来试试水，看看是否是从物联网公司往互联网公司跳槽会比较难。结果一不当心就面上了，最终走的也很匆忙。固然从年初到年底升了两次工资也是蛮爽的，或许之后不再会有这么大的工资涨幅了，啊哈哈。

PPT

之前对于写代码的不如写 PPT 的没有多少体感，由于前公司真的不须要作什么 PPT，惟一作的几回 PPT 也不是为了向上级进行述职，而是对其余 BU 进行技术分享，哪怕是晋升也不须要作 PPT。来了阿里以后发现写好一个 PPT 确实须要技术含量，固然讲 PPT 更须要技术含量（如何在有限的时间内最大化体现你的工做成果）。

运动

今年上半年4月开始到8月半基本上不下雨的话天天坚持从住的地方跑步去公司上班，可是来了阿里之后就打破了两年的做息习惯，再也没法7点半起床，再也没法早到公司多学习一个小时了（读书的时间都是挤出来的）！但愿后续本身可以慢慢调整回来！

招聘

来了阿里以后，不少地方和原来的公司仍是有很大的差别。好比更加自由（上下班不用打卡，若是加班很晚次日能够中午到公司......）、更加忙碌（各类评审会、周会、双周会以及月会等）、更加独立自主（不少业务有人催但没人管，你须要本身为你的业务买单，是一种自下而上的模式而非自上而下的模式）、更加多面（跨部门协做、移动办公、技术培训、文化培训等等）。我以为挺好，由于我不仅仅只是在写代码。除此以外，同事都很厉害，若是你遇到解决不了的问题几乎只要一脑暴，立马就有了解决方案。

说了那么多固然是但愿你们能来应聘，由于真的缺人。固然为了让你们可以更加熟悉咱们这边的招聘流程，这里会从如下三个方面简单说说我当面试官的一些感觉：

简历评估
面试过程
后续流程

简历评估

评估简历是招聘流程中的第一步，若是简历评估不过关那么将不会有接下来的面试流程。不少加个人掘友都会让我帮忙看看简历作的是否合理（每每这些掘友对本身都不够自信），其实简历大多数是由各位的学习和工做经历决定的，没有合理不合理的说法，只有合适或者不合适应聘岗位的状况。固然对于众多投递的简历仍是会先作第一步筛选（这不是我自认为的简历评估方法）：

3 年以上工做经验
技术栈符合 BU 的业务场景
技术栈很丰富且有深度
技术创新 / 普惠能力
业务复杂且能体现本身的负责性 / 主动性
带领团队的能力
开源项目经验

以上是我做为一面面试官的评估方法，这是一个很现实的问题（有些评估方面怕引发众多掘友不良反应，这里就不一一列举了），由于很难从一堆简历中去精准的挑选出一个合适的简历（事实上大部分简历都千篇一概，由于你们写简历的形式真的都差很少），因此得有一套基本的评估方法。固然若是没有筛选出以上信息，我还会从如下信息进行二次筛选：

2 年工做经验技术栈有深度
技术普惠能力
业务能体现本身的主动性 / 思考性
业务上有性能优化经验

除此以外固然也会有一些硬性过滤的指标：

频繁跳槽（会被定位成没有业务 / 技术沉淀）
简历作的极不认真（排版不清晰 / 错别字）
专业技能都是基础技能（擅长 DIV + CSS 布局、擅长 HTML / CSS / JAVASCRIPT、了解闭包 / 原型链 / ...）

友情延伸：千万要留神专业技能，切忌写一些面试官一看就没兴趣的技能（你感受会不少基础技能，写的越多越好，却不知你们都会，甚至稍稍一深刻询问你就怀疑本身是否是真的会了，还不如不写），不少技能信息你能够在项目经历中间接的透露出来。若是想了解更多如何写简历的技巧，可查看个人另一篇文章面试分享：两年工做经验成功面试阿里P6总结 / 简历。

面试过程

目前国内的面试环境确实比较恶劣，记得以前看到有人在某社区评论说 Redux 做者若是来面试国内的三四线公司，可能连一面二面都过不了。这里我谈谈我本身对于面试的见解，我想说面试不是为了为难你们，也不是为了体现面试官多么牛逼之类的，面试是为了挖掘你们的能力和潜力。固然，每个面试官的面试风格都不同，你们不要再问我下一面是否是会问 XXX 问题，下一面是否是会有在线笔试等等，我不是下一个面试官。必须每个人，每个 BU、每个公司、每个国家、每个行星、每个星系面试的风格都不同（啊哈哈哈，别再问我相似的问题啦，不要让你本身显得很...）。总之一句话，作好本身，作那个不能被替代的本身，不要让本身过于被动，好好准备，应付可能发生的一切。

因为刚进公司，我通常会承接一面的面试官，那个人面试风格是这样的：

提早根据简历准备面试问题，通常 8 个左右（问题通常都和简历息息相关）
8 个问题至少涉及 CSS / JavaScript / 业务
纵向会问一些相对深刻的基础技术知识
纵向可能会问一些宏观层面的技术知识（根据面试者回答的满意度酌情考虑是否加问）
横向主要考察对于业务的思考
若是有问题面试者不会可能会追加问题（根据面试者当时面试时长而定）
若是答的能够最后会出一个笔试题（尽管我我的比较反感出笔试题）

友情提示：我喜欢根据简历作一些深度面试，但事实上一面更多的应该是作一些广度面试，不只仅是根据简历已有的内容进行面试。

这里给出面试过程的几点建议：

心态放平稳，假设第一题你答不上来很正常，面试官不会由于第一题你不会就 PASS 你
不会的题目必定不要瞎猜，每每面试官给你挖的坑就是但愿你往火坑里跳，必定要答不知道
不要说太多跟当前面试题无关的内容，问你什么问题尽可能就答什么问题
若是没有听懂面试题能够试着询问面试官，您要问的是关于 XXX 的问题么
对于某些问题必定要本身先提早精炼一下（例如做用域链、继承以及原型链等问题，固然我是几乎不会问这样的问题的）
若是面试官问的某项技术本身在某些场景使用过或在别的场景有看到使用，可结合这些场景进行讲解（让面试官知道你不只仅理解它，你还会很好的使用它）
若是是 Vue 技术栈但愿能够深刻了解源码
面试以前必定要好好准备这样一个问题：你以为你最擅长什么（由于颇有多是面试官以为这次面试让他很纠结过于不过，想经过此类问题对你进行二次挖掘，此类问题每每是救场问题）
面试必定要真诚，切勿投机取巧
面试态度必定要谦虚
千万不要长篇大论，千万不要长篇大论，千万不要长篇大论（这个问题是我面试以来遇到最频繁的问题，面试者生怕面试官以为他什么都不会问题答不上来。可是若是面试官打断了你的聊天，那么这个问题比你答不知道后果还要严重，很大多是面试官没有获得他想要的答案且极大的消耗了他的耐心）

对于我而言影响面试过于不过的因素大体有如下几点：

你能够答上一半以上的面试题，其中有两三个问题答的比较符合预期，其中有一个问题答的比较出彩
你大部分问题都能答上一些信息，虽然答的不是很符合预期
你的回答效率很高
你的回答让我感受你的主观能动性很强
你的回答让我感觉到你本身很难受，但你却能答出个因此然
你的回答让我很舒服（什么叫舒服呢，别问为何，我不会剖析我本身，就跟找女友同样吧）
笔试题只是作一个简单的参考，它不是影响你过于不过的决定性因素
你确实擅长一些我不擅长的技术方面，可是你确实在我这一面答的不是很好，我会转交给下一面继续深挖

后续流程

若是你过了一面，那么后面基本上还有一轮基础面，一轮 Leader 面，一轮大 Leader 面，一轮 HR 面。因此整体而言，应该是 5 面左右。

掘金

我是一个惰社交人员，今年 1 月份加入掘金的初衷是但愿本身多和社区保持信息同步，不会被面试信息淘汰。但加入掘金以后发现个人初衷慢慢被改变，掘金对我产生了一些意想不到的影响（无论是生活上仍是工做上）：

会常常看热门文章
会常常刷热门沸点，而且看到有趣的或者息息相关的信息就会主动占坑
会常常搜索科普文章
会收藏文章并进行归类

额外发现：天天早上醒来的第一件事情多是刷沸点，也多是直接起床。坐在马桶上的第一件事情多是刷沸点，也多是刷今日头条。出行地铁的时候多是看热门文章，也多是纯听歌。中午吃饭的时候确定是先刷沸点。晚上睡觉前多是刷沸点多是刷抖音也多是刷朋友圈。

因而憋了很久鼓足勇气在掘金发了第一篇技术文章 Vue CLI 3 结合 Lerna 进行 UI 框架设计，收获了一些赞，可是并无想象中的那么好。不过万事开头难嘛，只要本身坚持，总能慢慢使本身的文章带来更多的普惠。

今年在掘金陆续发了 4 篇技术类文章，1 篇面试类文章，其中自认为写的最好的文章基于 Vue 实现一个简易 MVVM 点赞数最少，相反本身没那么用心的面试文章面试分享：两年工做经验成功面试阿里 P6 总结反而点赞数很高。从中猜想你们可能不喜欢既啰嗦又消耗脑力的文章，你们喜欢既精简又科普还不消耗耐性的文章（有点故事会的感受）。

我我的喜欢写那种既啰嗦又长还不会分（一）、（二）、（三）的文章（真的须要耐心阅读的那种），事实上我老是想把我知道的事情说的既仔细又具体，哪怕它能够说的更精简。固然，写任何的文章都要认真仔细，要对读者的阅读时间负责（我会反复修订反复修订反复修订，直到满意为止）。

在掘金的第一年收获了不少粉丝，有不少掘友加我交流，可是可能个人沟通能力和社交能力真的有所欠缺，有些时候由于工做忙或者被相同问题困扰会致使我没有耐心回答掘友们的问题，但愿在这篇又臭又长的文章中给你们带来一些些收获。

额外连接

这里推荐阅读以前写的文章（前面 2 篇实用型，后面 3 篇对面试应该会有帮助，尤为是后面 3 篇必定要看哦）：