2019 前端之路
前言
從未寫過年度總結，恰逢今年是變化較大的一年，所以需要有一個總結儀式。同時希望在未來的每一年都能有一次年度總結，看看當前走過的路，也回望以往的不足。畢竟，前端一世，草木一秋。
關於我的年度總結，這裡主要分為以下幾個模塊（文章篇幅很長，大家可以按需閱讀）：
- 技術
- 學習
- 雜七雜八
- 招聘
- 掘金
「技術」模塊主要講解這一年來自我技術方面的創新以及實踐。 「學習」模塊會講解2019 的一些學習內容以及前端新認知，並且也會講解自我的學習方法，希望對在校以及剛入職前端工作的同學有所幫助（鑑於很多掘友高頻詢問如何學習前端）。 「招聘」是今年最有感觸的一塊，會重點講解自己在阿里的招聘感受，希望對想入職阿里工作的同學有所啟迪。
抱歉說明：這裡對掘友們說一聲抱歉，在回復問題時由於工作忙碌而不夠耐心（問相同問題的人太多），接下來的文章會重點針對高頻問題在「學習」和「招聘」模塊做一些闡述。
技術
今年是技術成長最多的一年，也是自我轉變最快的一年。以下是自己總結的一張技術結構圖，其中標紅的部分是今年有所接觸或深入的部分：
對我而言，今年技術創新的關鍵詞是「UI 框架/ 腳手架」和「低代碼（Low Code）」，技術實踐的關鍵詞是「桌面端」。
UI 框架/ 腳手架設計
今年年初的主要工作是對基礎組件庫進行框架重構以及對業務組件庫進行框架設計，這是自我感覺最快樂的時光，因為一直不停的需要解決一些棘手的問題（往往困難是自我成長的機會點）。接下來將從以下四個方面講解UI 框架/ 腳手架設計的過程：
- UI 框架重構前提
- 基礎組件庫的框架重構
- 業務組件庫的框架設計
- UI 腳手架的設計
UI 框架重構前提
公司現有的基礎組件庫1.x 基於Element UI 框架進行設計，在開發的過程中發現Element UI 框架帶來了以下一些問題（相對我司而言）：
- UI 源碼編譯的Webpack 配置複雜
- Demo 演示的Webpack 配置複雜，且對於UI 開發者的開發體驗不夠友好
- Demo 演示的線上體驗不夠友好
- Demo 演示沒有CI 自動部署能力
- UI 框架的Scripts 腳本繁多（多數是因為需要編譯各種輸出規範以及按需引入的能力）
友情提示：如果UI框架的一些能力（例如
utils、commonjs2 版本的各个组件按需引入、umd 版本）根據公司自身的情況並不需要，那麼完全可以砍掉從而大幅度簡化Webpack配置（除非未來想要開源）。
為了解決上述問題，對公司現有的基礎組件庫1.x 版本進行了框架重構。
基礎組件庫的框架重構
首先重點研究了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包描述文件(需要vuecli的開發態依賴)││└──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#vuecli的babel配置├──lerna.json#lerna配置├──package.json#vuecli容器描述文件（容器不是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 桌面端的開發類型主要分為以下幾種類型：
其中涉及到Web 前端的桌面端應用開發框架如下（這裡只是做簡單調研）：
開發純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 面左右。
關於我們
真香警告：寫了這麼多重點終於來了
大家好，我們是阿里巴巴新成立的BU，目前還有大量的Web 前端HC 空缺，希望正在找工作的同學們可以來試試：
- 目前Web 前端急缺P6 / P7（阿里的很多BU 都只招P7 了）
- 新的BU 你進來即是元老
- 前端技術體系大部分需要一起重新開拓，可以學習到更多的新內容
- 主要負責PC 端、客戶端、釘釘E 應用以及支付寶小程序的開發（本人完全不會小程序，不用擔心）
- 技術棧是React（如果你是Vue 技術棧完全不用擔心，因為我也是）
機會非常難得，如果想更多了解我們BU並找我內推的同學加我微信（加我時記得備註內推並自帶簡歷哦，當然如果是技術交流或者純粹交朋友也可以哦，不過我不一定能保證仔細認真的回答問題哦）： 18768107826
友情提示：已經有掘友通過我的推薦成功加入阿里巴巴了呦！
掘金
我是一個惰社交人員（不玩知乎，不玩微博，不玩...），今年1 月份加入掘金的初衷是希望自己多和社區保持訊息同步，不會被面試訊息淘汰。但加入掘金之後發現我的初衷慢慢被改變，掘金對我產生了一些意想不到的影響（不管是生活上還是工作上）：
- 會經常看熱門文章
- 會經常刷熱門沸點，並且看到有趣的或者息息相關的訊息就會主動佔坑
- 會經常搜索科普文章
- 會收藏文章並進行歸類
額外發現：每天早上醒來的第一件事情可能是刷沸點，也可能是直接起床。坐在馬桶上的第一件事情可能是刷沸點，也可能是刷今日頭條。出行地鐵的時候可能是看熱門文章，也可能是純聽歌。中午吃飯的時候肯定是先刷沸點。晚上睡覺前可能是刷沸點可能是刷抖音也可能是刷朋友圈。
於是憋了好久鼓足勇氣在掘金發了第一篇技術文章Vue CLI 3結合Lerna進行UI框架設計，收穫了一些贊，但是並沒有想像中的那麼好。不過萬事開頭難嘛，只要自己堅持，總能慢慢使自己的文章帶來更多的普惠。
今年在掘金陸續發了4篇技術類文章，1篇面試類文章，其中自認為寫的最好的文章基於Vue實現一個簡易MVVM點贊數最少，相反自己沒那麼用心的面試文章面試分享：兩年工作經驗成功面試阿里P6總結反而點贊數很高且被各種公眾號轉載。從中猜測大家可能不喜歡既囉嗦又消耗腦力的文章，大家喜歡既精簡又科普還不消耗耐性的文章（有點故事會的感覺）。
我個人喜歡寫那種既囉嗦又長還不會分（一）、（二）、（三）的文章（真的需要耐心閱讀的那種），事實上我總是想把我知道的事情說的既仔細又具體，哪怕它可以說的更精簡。當然，寫任何的文章都要認真仔細，要對讀者的閱讀時間負責（我會反復修訂反復修訂反復修訂，直到滿意為止）。
在掘金的第一年收穫了很多粉絲，有很多掘友加我交流，但是可能我的溝通能力和社交能力真的有所欠缺，有些時候因為工作忙或者被相同問題困擾會導致我沒有耐心回答掘友們的問題，希望在這篇又臭又長的文章中給大家帶來一些些收穫。
額外鏈接
這裡推薦閱讀之前寫的文章（前面2 篇實用型，後面3 篇對面試應該會有幫助，尤其是後面3 篇一定要看哦）：