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 篇必定要看哦）：