在線公開課 | 前端工程師如何突破瓶頸更好地變現本身

在線公開課 | 前端工程師如何突破瓶頸更好地變現本身

原創： 京小云 京東雲開發者社區  3天前

課程概要!

這次課程的分享主題是"前端工程師如何突破瓶頸更好地變現提高本身"。課程從如下三個方面入手，爲你們詳解一個前端工程師是如何一步步完善並提高本身的的。

• 前端工程師所應具有的能力;

• 現代前端工程師在企業或者部門的定位;

• 介紹下京東雲前端，在公共服務這塊兒的一些演進和沉澱心得。

這次課程的講師是苗宇，是京東雲產研部門的前端工程師，目前主要負責產研部門前端公共服務的搭建和維護。面對這樣一個可能有些寬泛的主題，苗宇把所講的內容對應配合着前端的具體實例或者知識點進行了詳解。

前端工程師如何突破瓶頸更好地變現本身

— 京東雲   苗宇—

01前端工程師所應具有的能力

****

前端相關技術

在搜索大廠對前端工程師的職位要求時，其中如下幾點幾乎是全部前端崗位都要求的。包括：

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

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

3. 一些移動端的適配要求

其實對於一些剛畢業或者工做一、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 到頁面加載期間發生了什麼。若是你能把這些知識點答上來的話，那確定是加分項，何況不少面試官也未必知道。

包括算法和數據結構如今也變成重點考察的目標，由於隨着前端能作的事情愈來愈多，一些工程化思惟、邏輯思惟也都是考察的一項。

多刷算法題會培養你的邏輯思惟能力，同時在你寫代碼或者重構代碼的時候，天然而然的就會想到最優解的方案。

業務拓展能力

其實大多數前端仍是更偏向於業務，時間長了以後，不免會以爲枯燥，尤爲是即使如此也仍是須要知足一些千奇百怪的需求。若是你不能從業務中拓展相關的一些知識點，你可能僅僅只是個作需求的，就相似你已經工做了五、6年，但實際的工做經驗和技能卻只有一、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······港真，這個問題真的是有點難呢。

好比就有同窗在後臺問小編：

Q:老師，您怎麼保養頭髮的?

-向左滑動查看答案-

A: 三分天註定，七分靠飄柔🤣

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 監控系統，去與京東雲的發佈、構建系統對接。

咱們計劃經過以組件庫爲核心，能將整個前端公共服務打形成一個生態。這個也是身爲一個前端所值得作的~

---

以上爲公開課的全部內容

做爲前端工程師的基本技能，網頁的設計與搭建技能怎麼能沒有呢？

京東雲域名特價搶注！

點擊左下方「閱讀原文」，便可9元註冊專屬於你本身的域名哦！

Q&A

課程問答

Q

前端工程師的職業發展，是作一個大前端，仍是作一個全棧？

A

主要仍是根據公司或者部門對前端的具體定位。好比前端技術棧有像 BFF 這層，可能你會有機會接觸到 Server，這種你能夠適當橫向擴展，瞭解下服務端的相關知識，作一個 T 字型人才。但其實本質仍是須要把基礎知識打牢，不少東西是須要時間、經驗積累的。

Q 前端技術層出不窮，各個技術框架一波又一波，Vue、React

版本一個又一個。面對新技術，學不動了怎麼辦？ A

關於新技術學習，個人建議是：

一、不必定迅速上手實踐，花一點時間去了解技術機制和應用場景；

二、關注新技術在前端社區的動向，提高本身的技術視野，拓展並完善知識體系；

三、試錯方向沒有那麼可怕，不少技術都是相互關聯，彼此之間容易過渡

最最重要的是不知足現狀，不斷去學習和積累。

Q前端的將來是什麼？如今學的技術未來會不會被淘汰？A

前端的發展能夠關注社區的動向，像現在比較新的技術例如GraphQL、PWA、Web Components，WebAssembly 及跨端方向如 Flutter ，都是爲了解決某一類或者某些類問題的產生的。隨着技術的發展，前端能作的事情愈來愈多，須要解決的問題也會愈來愈多。相應的新技術、新框架也會層出不窮。對你我的而言，你更多的是須要時刻保持學習能力，不斷的提升本身。

若是你只是 API 工程師的話，那確定是會被淘汰的。但若是你能從掌握這些庫、框架的原理，這些知識是不會隨着框架淘汰而淘汰的。

·END·

參考文檔：

• 漫談前端體系建設： https://zhuanlan.zhihu.com/p/28299873

-淺談SAML, OAuth, OpenID和SSO, JWT和Session：http://www.javashuo.com/article/p-hpniygfb-eo.html

閱讀原文