摘要：轉(zhuǎn)自前端外刊評(píng)論非常感謝，翻譯的很好，受益很多，轉(zhuǎn)到此處讓前端小伙伴們也驚呆下上次我寫(xiě)前端工程師必知必會(huì)已經(jīng)是三年前了，那是我寫(xiě)過(guò)最火的文章了。測(cè)試的第二大障礙是工具。

  
轉(zhuǎn)自：前端外刊評(píng)論

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

上次我寫(xiě)《前端工程師必知必會(huì)》已經(jīng)是三年前了，那是我寫(xiě)過(guò)最火的文章了。三年了，我仍然會(huì)在Twitter上收到關(guān)于這篇文章的消息。

從2012年到現(xiàn)在，一篇文章都沒(méi)發(fā)過(guò)讓我覺(jué)得有點(diǎn)羞羞噠。三年是一段很長(zhǎng)的時(shí)間，很多東西都發(fā)生了改變。2012年，我鼓勵(lì)同學(xué)們?nèi)W(xué)習(xí)瀏覽器開(kāi)發(fā)者工具和模塊化；雖然有很多同學(xué)會(huì)覺(jué)得CSS預(yù)編譯和客戶端模板引擎并不靠譜，但我仍然想要說(shuō)一說(shuō)它們；還有JSHint，雖然有#getoffmylawn（滾出我的地盤(pán)）的警告，但依然無(wú)法阻止JSHint成為一個(gè)受歡迎的理念（準(zhǔn)確的說(shuō)，JSLint真的（只是）存在過(guò)）。

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

第二，我現(xiàn)在已經(jīng)完全把Javascript作為我的核心了：CSS知識(shí)只有在必須關(guān)注性能問(wèn)題時(shí)才會(huì)用到，其他場(chǎng)景已經(jīng)用的越來(lái)越少。我知道有很多牛逼的前端同學(xué)并不是這樣的，但我也意識(shí)到，關(guān)注JS的同學(xué)和關(guān)注CSS的同學(xué)之間的距離也越來(lái)越遠(yuǎn)。這可能需要在另起一篇文章來(lái)討論，不過(guò)我想說(shuō)的是，這篇文章中不會(huì)有介紹CSS技能標(biāo)準(zhǔn)的內(nèi)容，因?yàn)槲疫€遠(yuǎn)遠(yuǎn)沒(méi)有達(dá)到能那么做的水平。

總之，就算這個(gè)技能列表并不適合你的前端工作，沒(méi)關(guān)系，不要有壓力，地球也不會(huì)爆炸。

回想2009年，那時(shí)候當(dāng)你知道 HTML5 在2014年才能用的時(shí)候，你是不是覺(jué)得這輩子基本上都用不到它了？如果是，那么你需要準(zhǔn)備好接受進(jìn)展緩慢但是已經(jīng)趨于穩(wěn)定的ES6了，它也是下一代的Javascript（現(xiàn)在叫 ES2015 了，嗯，這名字至少表示今年就能用了）。就我而言，ES6，額，ES2015 無(wú)疑是我個(gè)人現(xiàn)在最關(guān)注的 Javascript 內(nèi)容。在 ES6 中將會(huì)出現(xiàn)一些比較大的變化：類，真正的私有，經(jīng)過(guò)改進(jìn)更易用的函數(shù)和參數(shù)設(shè)定，可導(dǎo)入的模塊，等等等等。那些掌握和理解新的語(yǔ)法的同學(xué)以后將會(huì)在 JS 社區(qū)牛逼閃閃。相關(guān)閱讀：

Understanding ES6，Nicholas Zakas 正在寫(xiě)的書(shū)。

BabelJS，一個(gè)可以把你寫(xiě)的 ES6 的代碼編譯成 ES5 并在現(xiàn)代瀏覽器中運(yùn)行的工具。他們也有一個(gè)不錯(cuò)的介紹 ES6 的文檔。

ES6 Rocks，里面有大量的文章探索 ES6 的特性，語(yǔ)義和缺陷。

你也許會(huì)問(wèn)：那我需要成為一個(gè) ES6 專家么？也許現(xiàn)在不需要，但至少你得和你的同事懂的一樣多吧？或者比他們稍微多一點(diǎn)？當(dāng)然，如果能在你的下一個(gè)新項(xiàng)目中作為一個(gè)娛樂(lè)性的技術(shù)嘗試也是不錯(cuò)的，做好準(zhǔn)備肯定沒(méi)錯(cuò)的，因?yàn)槲覀冇肋h(yuǎn)不知道下一刻會(huì)發(fā)生什么。

先不說(shuō)新的語(yǔ)言特性，使用回調(diào)和 promises 管理異步 Javascript 至少得背的滾瓜爛熟吧。瀏覽器端應(yīng)用加載，以及應(yīng)用間通信策略得形成一套自己的觀點(diǎn)吧。而且你應(yīng)該知道哪種框架最適合你，而不是現(xiàn)在還把時(shí)間花在理解各種框架的實(shí)現(xiàn)原理和該選擇哪種框架上。

毫無(wú)疑問(wèn)，模塊化是構(gòu)建 Web 客戶端應(yīng)用的基石。回到2012年，關(guān)于使用哪種模塊化（AMD/CommonJS）方案構(gòu)建瀏覽器端應(yīng)用還存在很多爭(zhēng)論。而最近慢慢火起來(lái)的 UMD 則在保證代碼可復(fù)用的前提下嘗試避免這樣的問(wèn)題。 其實(shí)也沒(méi)什么好爭(zhēng)得，畢竟這倆玩意兒之間也就差幾個(gè)字符吧？

我覺(jué)得類似這樣的爭(zhēng)論其實(shí)并不都需要有一個(gè)答案，這也是我覺(jué)得從2012年到現(xiàn)在我們發(fā)生的最大的轉(zhuǎn)變，當(dāng)然，也許只是我自己這么認(rèn)為。因?yàn)槲矣X(jué)得與其說(shuō)“我再也不用 AMD 了”之類的話，倒不如多去討論 “在開(kāi)發(fā)和打包過(guò)程中使用 CommonJS 和 npm 遇到的各種難題” 來(lái)的更有價(jià)值。

雖然很感激 RequireJS 曾經(jīng)對(duì)模塊化做出的貢獻(xiàn)，不過(guò)現(xiàn)在我開(kāi)始有點(diǎn)迷戀 webpack 了。 webpack 的構(gòu)建配置比 RequireJS 更加易于理解，也更具訪問(wèn)性。通過(guò)它的熱插拔特性和內(nèi)置的本地靜態(tài)服務(wù)器可以讓發(fā)布更加便捷。它并不強(qiáng)制要求使用 AMD 或者 CommonJS – 兩個(gè)它都支持。它還實(shí)現(xiàn)了一大堆加載器，用來(lái)完成常見(jiàn)的繁瑣工作。 Browserify 也值得去了解一下，不過(guò)我個(gè)人認(rèn)為它比 Webpack 落后很多。一些靠譜的朋友告訴我說(shuō) systemjs 也是這個(gè)領(lǐng)域的競(jìng)爭(zhēng)者，不過(guò)我還沒(méi)有用過(guò)，而且它的文檔爛的我連看都不想看。不過(guò)我覺(jué)得它的好基友 jspm (包管理器)比較有趣，jspm 可以讓你從各種包管理服務(wù)器加載你需要的各種組件，(組件必須是符合 ES6, AMD, CommonJS and globals 規(guī)范的)，包括 npm, github 等，但是我對(duì)于這兩個(gè)玩意的合體還是有點(diǎn)不太理解。啊，還有，雖然我說(shuō)了這么多關(guān)于模塊化之外的內(nèi)容，但我從來(lái)沒(méi)想過(guò)放棄 AMD，我們邊走邊看吧。

我覺(jué)得如果要停止對(duì)模塊化和構(gòu)建工具的爭(zhēng)論，形成統(tǒng)一的模塊化系統(tǒng)，并且在這個(gè)系統(tǒng)里面，任何項(xiàng)目的代碼都可以共享，而且還不需要 UMD 這樣額外的補(bǔ)丁工具，我們還有很長(zhǎng)的路要走。理想狀況下，ES6 modules 的到來(lái)會(huì)解決這些問(wèn)題，不過(guò)在這一天到來(lái)之前，類似 UMD 之類的轉(zhuǎn)換器會(huì)填補(bǔ)這些空缺，不過(guò)貌似這樣做我們又把事情變得復(fù)雜了，好像我們也總喜歡把事情弄得復(fù)雜。

與此同時(shí)，前端開(kāi)發(fā)人員也需要對(duì)構(gòu)建工具，各種模塊化系統(tǒng)有自己的見(jiàn)解和知識(shí)儲(chǔ)備。不管是好是壞，根據(jù) Javascript 現(xiàn)在的進(jìn)度，你的模塊化策略會(huì)對(duì)你的項(xiàng)目有比較大的影響。

客戶端的代碼測(cè)試變得越來(lái)越普遍，最近也誕生了一些新的測(cè)試框架： Karma，Intern 。我發(fā)現(xiàn)基于 promise 的 Intern 的異步測(cè)試方法相當(dāng)優(yōu)雅。不過(guò)可能是因?yàn)榱?xí)慣，我大多數(shù)情況下還是用 Mocha 寫(xiě)測(cè)試用例。

測(cè)試的主要障礙其實(shí)是前端開(kāi)發(fā)者的代碼編寫(xiě)方式。我在2012年發(fā)表過(guò)一個(gè)關(guān)于《編寫(xiě)可測(cè)試的Javascript》下載地址的演講，緊接著幾個(gè)月后又發(fā)表了一篇相關(guān)的文章。

測(cè)試的第二大障礙是工具。Webdriver 是一個(gè)艱難而巨大的工作。目前在各個(gè)瀏覽器端做持續(xù)集成的 UI 自動(dòng)化測(cè)試基本上是不可能的，更不用說(shuō)移動(dòng)端了。我們?nèi)匀煌Ａ粼诰窒抻谀骋恍〔糠譃g覽器和設(shè)備上做輕量級(jí)的自動(dòng)化功能測(cè)試，盡我們所能去研究怎樣快速，低成本的進(jìn)行這種測(cè)試的階段。

如果你對(duì)如何改進(jìn)代碼的可測(cè)試性感興趣的話，那么唯一一本最值得看的書(shū)是 Working Effectively with Legacy Code （中譯版：《修改代碼的藝術(shù)》。作者 Michael Feathers 定義了“遺留代碼”的概念：任何未經(jīng)測(cè)試的代碼都是遺留代碼。在測(cè)試領(lǐng)域，最基本的要素就是上面這句話，盡管你可能不這么認(rèn)為。

你首先會(huì)想到 Grunt，這也是理所當(dāng)然的。而 Gulp 和 Broccoli 的自動(dòng)化構(gòu)建方式也別具匠心。我沒(méi)用過(guò)Broccoli，只玩過(guò)Gulp，我也開(kāi)始意識(shí)到Grunt對(duì)于依賴其他服務(wù)的復(fù)雜任務(wù)的自動(dòng)化工作存在局限性，尤其是當(dāng)這種任務(wù)每天需要運(yùn)行上千次的時(shí)候。

Yeoman是在我寫(xiě)完2012年的那篇文章僅僅45天之后發(fā)布的，我承認(rèn)當(dāng)時(shí)我并沒(méi)有及時(shí)去嘗試一下。不過(guò)最近我開(kāi)始啟動(dòng)一些新項(xiàng)目，這些新項(xiàng)目有兩個(gè)特點(diǎn)
a) 這些項(xiàng)目都是從零開(kāi)始
b) 嘗試用一些不同的技術(shù)方案，試圖通過(guò)這種方式找到 Bazaarvoice（提供第三方點(diǎn)評(píng)服務(wù)）上第三方 JS 應(yīng)用的規(guī)范化的開(kāi)發(fā)方式。
Yeoman 在這兩方面做的都很好。一個(gè)簡(jiǎn)單的 yo react-webpack 命令就可以為你初始化好你的項(xiàng)目，然后各種你想要的玩具也都應(yīng)有盡有：生成測(cè)試用例，本地靜態(tài)服務(wù)器，hello world 入門(mén)程序，等等等等。如果 React 和 webpack 不是你想要的，也許你會(huì)在 Yeoman 的 generators（項(xiàng)目生成器）里面找到一個(gè)你想要的，當(dāng)然，自己自定義一個(gè)這樣的構(gòu)建包也是比較容易的。

鑒于 Yeoman 只是一個(gè)在項(xiàng)目開(kāi)始時(shí)才會(huì)用到的構(gòu)建工具，并且鑒于我們并不是總是做新項(xiàng)目，所以大多情況下了解一下就夠了。除非，你也想去規(guī)范整個(gè)項(xiàng)目開(kāi)發(fā)過(guò)程，那么它可能會(huì)更有價(jià)值一點(diǎn)。

Broccoli 已經(jīng)得到了 ember-cli 的采納，我覺(jué)得他們的配對(duì)可能會(huì)有一個(gè)新名字，這樣在未來(lái)才比較方便和 Grunt /Yeoman 對(duì)抗。而 Grunt 和 Yeoman 的開(kāi)發(fā)進(jìn)度也放緩了，所以未來(lái)會(huì)發(fā)生什么，我們還是靜觀其變吧。

如果你像我一樣，一看見(jiàn)違反代碼規(guī)范的代碼時(shí)就開(kāi)始抓狂，那么 JSCS 和
ESLint 就是老天賜給你的禮物，而2012壓根就沒(méi)這些玩意。他們都提供了自定義代碼規(guī)范的方式，并且可以在代碼提交前對(duì)你的代碼做自動(dòng)化校驗(yàn)。這讓我想起了…

從2012年到現(xiàn)在，github 的使用流程并沒(méi)有發(fā)生很大的變化，比如在 pull request 頁(yè)面連個(gè)分支名都沒(méi)有（只是惡搞一下）。

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

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

這里會(huì)有一些新的展望，不僅是對(duì)我自己，也是對(duì)所有人，當(dāng)你在考慮性能問(wèn)題時(shí)，也許沒(méi)必要把自己完全限定在瀏覽器范圍內(nèi)。所以，這又讓我想起了……

聽(tīng)說(shuō)你懂 Javascript，那么我覺(jué)得你也應(yīng)該懂 Node，至少在遇到 Node 問(wèn)題是能幫得上忙的，如果連忙都幫不上，那也至少深入研究一下吧：Node 的文件系統(tǒng)，流，服務(wù)器，完全不同于前端的一些開(kāi)發(fā)模式等等。對(duì)后端敬而遠(yuǎn)之只會(huì)限制我們前端的發(fā)展?jié)摿Α?/p>

即使你的真實(shí)生產(chǎn)環(huán)境中后端不用 Node，當(dāng)你的工作被后端限制或阻礙的時(shí)候，Node 也是一個(gè)非常有用的工具。最起碼，你也應(yīng)該熟悉怎么去初始化一個(gè) Node 項(xiàng)目，怎么用 Express 搭建服務(wù)器設(shè)置路由，怎么使用請(qǐng)求模塊代理請(qǐng)求。

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

就這樣，祝你好運(yùn)。也許，三年之后我們會(huì)再見(jiàn)。

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