摘要：轉自前端外刊評論非常感謝，翻譯的很好，受益很多，轉到此處讓前端小伙伴們也驚呆下上次我寫前端工程師必知必會已經是三年前了，那是我寫過最火的文章了。測試的第二大障礙是工具。

  
轉自：前端外刊評論

  非常感謝，翻譯的很好，受益很多，轉到此處讓前端小伙伴們也驚呆下........

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

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

已經是2015年了，我想寫一篇新的，但是當我坐下來開始動筆的時候，想到了兩個事情。一，這些東西被稱作“必知必會”可能有人會覺得不太公平——如果你已經覺得2012年的那篇文章如此，那本文也是一樣的了。也許有同學會說，我們應該把 “足夠應付業務需求的技能” 作為 “前端必須掌握的知識”，但考慮到前端行業里也有各種各樣的工作可供選擇，這么做也只能得到一個并不適合所有人的 “前端基礎知識”。對于我來說，我需要的不是工作，我想要的是被邀請去做一份牛逼的工作。我想要的不只是去干活而已，而是想和一群牛逼的人一起做牛逼的事。我不想僅僅滿足于用已有的知識來完成現在的工作，而是希望掌握更多的知識來解決未來將會面對的問題。

第二，我現在已經完全把Javascript作為我的核心了：CSS知識只有在必須關注性能問題時才會用到，其他場景已經用的越來越少。我知道有很多牛逼的前端同學并不是這樣的，但我也意識到，關注JS的同學和關注CSS的同學之間的距離也越來越遠。這可能需要在另起一篇文章來討論，不過我想說的是，這篇文章中不會有介紹CSS技能標準的內容，因為我還遠遠沒有達到能那么做的水平。

總之，就算這個技能列表并不適合你的前端工作，沒關系，不要有壓力，地球也不會爆炸。

回想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壓根就沒這些玩意。他們都提供了自定義代碼規范的方式，并且可以在代碼提交前對你的代碼做自動化校驗。這讓我想起了…

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

你應該非常清楚和流暢地使用功能分支（feature branches）, 使用 rebase 合并別人的代碼干活，使用交互式 rebase 命令和 squash 合并提交記錄，或者盡可能細顆粒度的劃分項目內容，避免引起代碼沖突。另一個可用的 Git 工具是鉤子，具體而言，就是你可以在 push 前，commit 前，執行你的各種測試用例，檢查代碼質量。你可以自己寫鉤子，也可以使用 ghooks ，由于 ghooks 使鉤子工作變得非常簡單，所以你簡直沒有理由不用它。

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

這里會有一些新的展望，不僅是對我自己，也是對所有人，當你在考慮性能問題時，也許沒必要把自己完全限定在瀏覽器范圍內。所以，這又讓我想起了……

聽說你懂 Javascript，那么我覺得你也應該懂 Node，至少在遇到 Node 問題是能幫得上忙的，如果連忙都幫不上，那也至少深入研究一下吧：Node 的文件系統，流，服務器，完全不同于前端的一些開發模式等等。對后端敬而遠之只會限制我們前端的發展潛力。

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

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

就這樣，祝你好運。也許，三年之后我們會再見。

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