[ 學習路線 ] 2015 前端(JS)工程師必知必會 (2)

轉自：前端外刊評論
很是感謝，翻譯的很好，受益不少，轉到此處讓前端小夥伴們也驚呆下........

上次我寫《前端工程師必知必會》已是三年前了，那是我寫過最火的文章了。三年了，我仍然會在Twitter上收到關於這篇文章的消息。

從2012年到如今，一篇文章都沒發過讓我以爲有點羞羞噠。三年是一段很長的時間，不少東西都發生了改變。2012年，我鼓勵同窗們去學習瀏覽器開發者工具和模塊化；雖然有不少同窗會以爲CSS預編譯和客戶端模板引擎並不靠譜，但我仍然想要說一說它們；還有JSHint，雖然有#getoffmylawn（滾出個人地盤）的警告，但依然沒法阻止JSHint成爲一個受歡迎的理念（準確的說，JSLint真的（只是）存在過）。

已是2015年了，我想寫一篇新的，可是當我坐下來開始動筆的時候，想到了兩個事情。一，這些東西被稱做「必知必會」可能有人會以爲不太公平——若是你已經以爲2012年的那篇文章如此，那本文也是同樣的了。也許有同窗會說，咱們應該把 「足夠應付業務需求的技能」 做爲 「前端必須掌握的知識」，但考慮到前端行業裏也有各類各樣的工做可供選擇，這麼作也只能獲得一個並不適合全部人的 「前端基礎知識」。對於我來講，我須要的不是工做，我想要的是被邀請去作一份牛逼的工做。我想要的不僅是去幹活而已，而是想和一羣牛逼的人一塊兒作牛逼的事。我不想僅僅知足於用已有的知識來完成如今的工做，而是但願掌握更多的知識來解決將來將會面對的問題。

第二，我如今已經徹底把Javascript做爲個人核心了：CSS知識只有在必須關注性能問題時纔會用到，其餘場景已經用的愈來愈少。我知道有不少牛逼的前端同窗並非這樣的，但我也意識到，關注JS的同窗和關注CSS的同窗之間的距離也愈來愈遠。這可能須要在另起一篇文章來討論，不過我想說的是，這篇文章中不會有介紹CSS技能標準的內容，由於我還遠遠沒有達到能那麼作的水平。

總之，就算這個技能列表並不適合你的前端工做，不要緊，不要有壓力，地球也不會爆炸。

Javascript

回想2009年，那時候當你知道 HTML5 在2014年才能用的時候，你是否是以爲這輩子基本上都用不到它了？若是是，那麼你須要準備好接受進展緩慢可是已經趨於穩定的ES6了，它也是下一代的Javascript（如今叫 ES2015 了，嗯，這名字至少表示今年就能用了）。就我而言，ES6，額，ES2015 無疑是我我的如今最關注的 Javascript 內容。在 ES6 中將會出現一些比較大的變化：類，真正的私有，通過改進更易用的函數和參數設定，可導入的模塊，等等等等。那些掌握和理解新的語法的同窗之後將會在 JS 社區牛逼閃閃。相關閱讀：

• Understanding ES6，Nicholas Zakas 正在寫的書。
• BabelJS，一個能夠把你寫的 ES6 的代碼編譯成 ES5 並在現代瀏覽器中運行的工具。他們也有一個不錯的介紹 ES6 的文檔。
• ES6 Rocks，裏面有大量的文章探索 ES6 的特性，語義和缺陷。

你也許會問：那我須要成爲一個 ES6 專家麼？也許如今不須要，但至少你得和你的同事懂的同樣多吧？或者比他們稍微多一點？固然，若是能在你的下一個新項目中做爲一個娛樂性的技術嘗試也是不錯的，作好準備確定沒錯的，由於咱們永遠不知道下一刻會發生什麼。

先不說新的語言特性，使用回調和 promises 管理異步 Javascript 至少得背的倒背如流吧。瀏覽器端應用加載，以及應用間通訊策略得造成一套本身的觀點吧。並且你應該知道哪一種框架最適合你，而不是如今還把時間花在理解各類框架的實現原理和該選擇哪一種框架上。

模塊化和構建工具

毫無疑問，模塊化是構建 Web 客戶端應用的基石。回到2012年，關於使用哪一種模塊化（AMD/CommonJS）方案構建瀏覽器端應用還存在不少爭論。而最近慢慢火起來的 UMD 則在保證代碼可複用的前提下嘗試避免這樣的問題。 其實也沒什麼好爭得，畢竟這倆玩意兒之間也就差幾個字符吧？

我以爲相似這樣的爭論其實並不都須要有一個答案，這也是我以爲從2012年到如今咱們發生的最大的轉變，固然，也許只是我本身這麼認爲。由於我以爲與其說「我不再用 AMD 了」之類的話，倒不如多去討論 「在開發和打包過程當中使用 CommonJS 和 npm 遇到的各類難題」 來的更有價值。

雖然很感激 RequireJS 曾經對模塊化作出的貢獻，不過如今我開始有點迷戀 webpack 了。 webpack 的構建配置比 RequireJS 更加易於理解，也更具訪問性。經過它的熱插拔特性和內置的本地靜態服務器可讓發佈更加便捷。它並不強制要求使用 AMD 或者 CommonJS – 兩個它都支持。它還實現了一大堆加載器，用來完成常見的繁瑣工做。 Browserify 也值得去了解一下，不過我我的認爲它比 Webpack 落後不少。一些靠譜的朋友告訴我說 systemjs 也是這個領域的競爭者，不過我尚未用過，並且它的文檔爛的我連看都不想看。不過我以爲它的好基友 jspm (包管理器)比較有趣，jspm 可讓你從各類包管理服務器加載你須要的各類組件，(組件必須是符合 ES6, AMD, CommonJS and globals 規範的)，包括 npm, github 等，可是我對於這兩個玩意的合體仍是有點不太理解。啊，還有，雖然我說了這麼多關於模塊化以外的內容，但我歷來沒想過放棄 AMD，咱們邊走邊看吧。

我以爲若是要中止對模塊化和構建工具的爭論，造成統一的模塊化系統，而且在這個系統裏面，任何項目的代碼均可以共享，並且還不須要 UMD 這樣額外的補丁工具，咱們還有很長的路要走。理想情況下，ES6 modules 的到來會解決這些問題，不過在這一天到來以前，相似 UMD 之類的轉換器會填補這些空缺，不過貌似這樣作咱們又把事情變得複雜了，好像咱們也總喜歡把事情弄得複雜。

與此同時，前端開發人員也須要對構建工具，各類模塊化系統有本身的看法和知識儲備。無論是好是壞，根據 Javascript 如今的進度，你的模塊化策略會對你的項目有比較大的影響。

測試

客戶端的代碼測試變得愈來愈廣泛，最近也誕生了一些新的測試框架： Karma，Intern 。我發現基於 promise 的 Intern 的異步測試方法至關優雅。不過多是由於習慣，我大多數狀況下仍是用 Mocha 寫測試用例。

測試的主要障礙實際上是前端開發者的代碼編寫方式。我在2012年發表過一個關於《編寫可測試的Javascript》下載地址的演講，緊接着幾個月後又發表了一篇相關的文章。

測試的第二大障礙是工具。Webdriver 是一個艱難而巨大的工做。目前在各個瀏覽器端作持續集成的 UI 自動化測試基本上是不可能的，更不用說移動端了。咱們仍然停留在侷限於某一小部分瀏覽器和設備上作輕量級的自動化功能測試，盡咱們所能去研究怎樣快速，低成本的進行這種測試的階段。

若是你對如何改進代碼的可測試性感興趣的話，那麼惟一一本最值得看的書是 Working Effectively with Legacy Code （中譯版：《修改代碼的藝術》。做者 Michael Feathers 定義了「遺留代碼」的概念：任何未經測試的代碼都是遺留代碼。在測試領域，最基本的要素就是上面這句話，儘管你可能不這麼認爲。

流程自動化

你首先會想到 Grunt，這也是理所固然的。而 Gulp 和 Broccoli 的自動化構建方式也別具匠心。我沒用過Broccoli，只玩過Gulp，我也開始意識到Grunt對於依賴其餘服務的複雜任務的自動化工做存在侷限性，尤爲是當這種任務天天須要運行上千次的時候。

Yeoman是在我寫完2012年的那篇文章僅僅45天以後發佈的，我認可當時我並無及時去嘗試一下。不過最近我開始啓動一些新項目，這些新項目有兩個特色
a) 這些項目都是從零開始
b) 嘗試用一些不一樣的技術方案，試圖經過這種方式找到 Bazaarvoice（提供第三方點評服務）上第三方 JS 應用的規範化的開發方式。
Yeoman 在這兩方面作的都很好。一個簡單的 yo react-webpack 命令就能夠爲你初始化好你的項目，而後各類你想要的玩具也都應有盡有：生成測試用例，本地靜態服務器，hello world 入門程序，等等等等。若是 React 和 webpack 不是你想要的，也許你會在 Yeoman 的 generators（項目生成器）裏面找到一個你想要的，固然，本身自定義一個這樣的構建包也是比較容易的。

鑑於 Yeoman 只是一個在項目開始時纔會用到的構建工具，而且鑑於咱們並非老是作新項目，因此大多狀況下了解一下就夠了。除非，你也想去規範整個項目開發過程，那麼它可能會更有價值一點。

Broccoli 已經獲得了 ember-cli 的採納，我以爲他們的配對可能會有一個新名字，這樣在將來才比較方便和 Grunt /Yeoman 對抗。而 Grunt 和 Yeoman 的開發進度也放緩了，因此將來會發生什麼，咱們仍是靜觀其變吧。

代碼質量

若是你像我同樣，一看見違反代碼規範的代碼時就開始抓狂，那麼 JSCS 和
ESLint 就是老天賜給你的禮物，而2012壓根就沒這些玩意。他們都提供了自定義代碼規範的方式，而且能夠在代碼提交前對你的代碼作自動化校驗。這讓我想起了…

Git

從2012年到如今，github 的使用流程並無發生很大的變化，好比在 pull request 頁面連個分支名都沒有（只是惡搞一下）。

你應該很是清楚和流暢地使用功能分支（feature branches）, 使用 rebase 合併別人的代碼幹活，使用交互式 rebase 命令和 squash 合併提交記錄，或者儘量細顆粒度的劃分項目內容，避免引發代碼衝突。另外一個可用的 Git 工具是鉤子，具體而言，就是你能夠在 push 前，commit 前，執行你的各類測試用例，檢查代碼質量。你能夠本身寫鉤子，也可使用 ghooks ，因爲 ghooks 使鉤子工做變得很是簡單，因此你簡直沒有理由不用它。

客戶端模板

這多是我在2012年的那篇文章中寫的最爛的內容了，某種意義上的「爛」。客戶端模板仍是頗有價值的，並且它已經被內置到 ES2015 裏面了，這不只僅只是一件好事而已。這些年也有一些慘重的教訓，很多團隊把全部的渲染工做所有丟到瀏覽器端去作，結果產生了嚴重的性能問題，因此 「在瀏覽器端渲染生成全部 HTML」 的作法理所固然的被摒棄了。 而更爲聰明的作法則是，把 HTML 生成放在服務器端，或者經過預編譯的方式，先將模板作爲靜態資源儲存起來，在須要時快速的編譯成 HTML，須要更新時也能夠直接在客戶端更新模板。

這裏會有一些新的展望，不只是對我本身，也是對全部人，當你在考慮性能問題時，也許不必把本身徹底限定在瀏覽器範圍內。因此，這又讓我想起了……

Node

據說你懂 Javascript，那麼我以爲你也應該懂 Node，至少在遇到 Node 問題是能幫得上忙的，若是連忙都幫不上，那也至少深刻研究一下吧：Node 的文件系統，流，服務器，徹底不一樣於前端的一些開發模式等等。對後端敬而遠之只會限制咱們前端的發展潛力。

即便你的真實生產環境中後端不用 Node，當你的工做被後端限制或阻礙的時候，Node 也是一個很是有用的工具。最起碼，你也應該熟悉怎麼去初始化一個 Node 項目，怎麼用 Express 搭建服務器設置路由，怎麼使用請求模塊代理請求。

最後

感謝 Paul, Alex, Adam, Ralph 對本文的 Review，感謝他們絕不吝嗇的指出個人不足之處，並給我提了很好的意見。

就這樣，祝你好運。也許，三年以後咱們會再見。

原文連接: A Baseline for Front-End ‘JS’ Developers: 2015