【編者按】感謝@lenville對(duì)《A Baseline for Front-End [JS] Developers: 2015》的翻譯，該文章全面而系統(tǒng)地介紹了前端開發(fā)者所應(yīng)掌握的關(guān)鍵技術(shù)及最流行、實(shí)用的工具，尤其對(duì)于JS開發(fā)者大有裨益。
大約三年前，我寫了一篇《 前端開發(fā)者的基本技能》，嗯，那大概是我最出名的一篇文章。三年后，仍然有人在Twitter上@我詢問如何開始學(xué)習(xí)前端知識(shí)。
在某種程度上，我曾經(jīng)寫下的文字歷經(jīng)了時(shí)間的考驗(yàn)：令我感到震驚的是，2012年我寫的那篇文章并沒給我?guī)黼y堪的問題。盡管如此，3年之久，很多事情都變得與眾不同。2012年我鼓勵(lì)人們學(xué)習(xí)瀏覽器開發(fā)工具，緊跟模塊化開發(fā)大潮；那時(shí)候人們還不太接受CSS預(yù)處理和客戶端模板這類新事物，它們?nèi)匀恢档靡惶?；相比于JSLint錙銖必較的精確（甚至讓人感到厭煩），JSHint非常受歡迎，它使我們徹底解放。
現(xiàn)在時(shí)間來到了2015年，我想寫一個(gè)升級(jí)版的前端指南，但是當(dāng)我坐下動(dòng)筆開始寫的時(shí)候，我突然意識(shí)到兩件事情：
相對(duì)來說，稱這篇文章為基本技能是不公平的，如果你回憶起以前的文章，你會(huì)發(fā)現(xiàn)這篇文章仿佛偏離了基礎(chǔ)。人們可能會(huì)爭(zhēng)辯說，我們應(yīng)該考慮那些能讓我們找到工作的技能來作為基本技能。但是事實(shí)上，市場(chǎng)上有很多前端的工作可以選擇，為了得到一份工作你并不需要太多的基礎(chǔ)。于我而言，我并不想簡(jiǎn)單找一份工作了事，我希望參與到一份絕妙的工作中去；我不想簡(jiǎn)單工作就度過一整天，我希望能夠與有才能的人一起工作；我不想從事那些已經(jīng)被大眾所熟知的，坐在這里稍作思考，預(yù)計(jì)差不多明天之前就可以完成的那種工作，我希望從事那些，因?yàn)槲抑廊绾稳スぷ?，我能在明天之前鉆研出一個(gè)成果，所以我明天可以順利完成任務(wù)的工作，對(duì)，就是有挑戰(zhàn)的那種！
我的世界正在變得徹底以JavaScript為中心：除了一些必要的性能優(yōu)化，我的日常工作接觸到的CSS知識(shí)越來越少。我知道有許多非常聰明的前端開發(fā)者，他們的JS和CSS技能都很厲害，但是根據(jù)我的觀察，專注研究JavaScript和專注研究CSS的人們正在逐漸分離。我大概可以寫另外一篇博文來闡述這個(gè)話題，但在這里我只想說：我沒有做過多有關(guān)CSS的準(zhǔn)備，所以不要對(duì)這一點(diǎn)抱有過多的期許。
簡(jiǎn)而言之：當(dāng)你以你的前端世界的視角來閱讀這篇文章，不一定能找到你需要的內(nèi)容。但請(qǐng)謹(jǐn)記，我們都是很棒的開發(fā)者！
JavaScript
記憶回到2009年，如果你在文章里讀到類似“HTML5將會(huì)在2014年定稿使用”的預(yù)言，是否看起來那一天還很遙遠(yuǎn)？如果當(dāng)時(shí)你這樣想，你將要準(zhǔn)備好迎接緩慢更新但是穩(wěn)步向前的ES6（現(xiàn)在被稱為 ES2015，這個(gè)名稱已經(jīng)隨處可見），也就是下一個(gè)版本的JavaScript。準(zhǔn)備與ES6——啊不對(duì)，ES2015——接軌吧，毫無疑問，這是接下來在JavaScript領(lǐng)域中最重要的事情。ES6 classes、真正的隱私、更好的函數(shù)和參數(shù)、可引入（import）的模塊以及許多其它特性，一定會(huì)徹底改變游戲規(guī)則。那些能力十足并且十分高產(chǎn)的新語(yǔ)法無疑將會(huì)徹底從JS社區(qū)中孕育出來。為此，你需要閱讀：
新的語(yǔ)言特性先暫且不談，你應(yīng)該能夠流利地說出JavaScript的異步模式，并且使用回調(diào)和promise來管理它。關(guān)于在瀏覽器中加載應(yīng)用并在每個(gè)應(yīng)用之間通信的策略，你應(yīng)該擁有足夠完備的見解。你也許應(yīng)該掌握一個(gè)你非常喜歡的應(yīng)用開發(fā)框架，同時(shí)也應(yīng)該對(duì)其它的框架是如何運(yùn)行的有一個(gè)概覽，你需要稍作權(quán)衡選擇你喜歡的那一個(gè)。
模塊和構(gòu)建工具
毫無疑問，模塊應(yīng)當(dāng)是客戶端Web應(yīng)用的構(gòu)建元素。回到2012年，關(guān)于使用什么類型的模塊來構(gòu)建瀏覽器應(yīng)用的討論此起彼伏，不過基本圍繞著 AMD和 CommonJS展開。還有一個(gè)略顯粗俗的 UMD包裝器嘗試融合二者來方便大家重用代碼——他們認(rèn)為，既然長(zhǎng)得差不多，不如多寫點(diǎn)兒代碼來同時(shí)支持二者。
我認(rèn)為這場(chǎng)爭(zhēng)論沒有一個(gè)統(tǒng)一的結(jié)論，但是我感覺這是自2012年我寫文章之后，這個(gè)領(lǐng)域中最大的轉(zhuǎn)變，當(dāng)然這也可能只是我個(gè)人的心路歷程。我沒有徹底搞定AMD，但是我被它的實(shí)用性征服了，你可以使用CommonJS開發(fā)并部署Web應(yīng)用，使用npm引入模塊。
RequireJS為模塊通信做了很大的貢獻(xiàn)，出于對(duì)它的厚愛，我現(xiàn)在有點(diǎn)兒迷戀 Webpack了。webpack的功能——例如容易理解的構(gòu)建參數(shù)（譯者注：build flag，命令行中形如-p的參數(shù)）——相比于RequireJS來說更容易理解。通過它的內(nèi)建開發(fā)服務(wù)器實(shí)現(xiàn)的熱交換構(gòu)建打造了一個(gè)快速且令人愉悅的開發(fā)傳奇。它并不強(qiáng)制你使用AMD或者CommonJS，因?yàn)樗瑫r(shí)支持兩者。還有非常多的加載器，使得完成許多相同工作對(duì)它來說簡(jiǎn)直是小意思。你也可以去了解一下 Browserify，但在我看來，一定要在熟悉了Webpack之后再去搞它，我信任的聰明人兒告訴我， systemjs在這個(gè)領(lǐng)域也是一個(gè)的認(rèn)真的競(jìng)爭(zhēng)者，但是我還沒用它呢，它的文檔讓我很想拜讀。它的包管理器 jspm很迷人，允許你從包括npm在內(nèi)的不同的源拉取所需的模塊，但是我有點(diǎn)兒擔(dān)心這倆貨結(jié)合起來會(huì)有些問題。我不得不重復(fù)，我從沒想過我會(huì)與AMD分開，但是看起來我不得不放棄它了，我們終將會(huì)看到這事情的發(fā)生。
我仍然渴望有一天我可以停止喋喋不休地爭(zhēng)論有關(guān)模塊和構(gòu)建工具的話題，那時(shí)候全世界只有一個(gè)模塊系統(tǒng)，這樣就可以在所有項(xiàng)目里共享使用代碼，同時(shí)還能免去使用UMD的開銷。理想情況下，那一天將會(huì)因?yàn)镋S6模塊而變?yōu)楝F(xiàn)實(shí)——在這一天到來前你可以使用轉(zhuǎn)譯器（Transpiler）來填補(bǔ)空缺——但我發(fā)現(xiàn)很有可能我們會(huì)持續(xù)不斷地找一些方法讓它變得愈發(fā)復(fù)雜。
與此同時(shí)，前端開發(fā)者需要了解至少一對(duì)構(gòu)建工具和相關(guān)的模塊系統(tǒng)，這需要在實(shí)踐中不斷積累經(jīng)驗(yàn)。不管怎樣，就目前JavaScript的發(fā)展情況來說，你仍然需要選擇一個(gè)模塊系統(tǒng)，它將支撐你的每一個(gè)項(xiàng)目。
測(cè)試
一些新的測(cè)試框架，例如 Karma和 Intern，已經(jīng)讓客戶端代碼的測(cè)試變的輕而易舉。我發(fā)現(xiàn)Intern基于promise來進(jìn)行異步測(cè)試的方法特別（作者拼錯(cuò)了particulary）爽，我不得不承認(rèn)，大多數(shù)時(shí)候我依然用Mocha來寫測(cè)試——有時(shí)我還真就是屈于習(xí)慣的生物啊。
測(cè)試過程中的主要阻礙是前端開發(fā)者傾向于寫的代碼，關(guān)于這個(gè)問題，我在2012年末公開談?wù)摿擞嘘P(guān) 編寫可測(cè)試的JavaScript的話題，幾個(gè)月后隨即寫了一篇有關(guān)這個(gè)話題的 文章。
測(cè)試過程中第二個(gè)大的阻礙是工具化，Web驅(qū)動(dòng)仍然是你需要處理的巨大傷痛。一個(gè)復(fù)雜UI在所有支持平臺(tái)上的持續(xù)自動(dòng)化測(cè)試依然不可行，即使可行開銷也非常巨大，以致于那看起來根本不可能實(shí)現(xiàn)——更別提移動(dòng)端了。很大程度上我們?nèi)匀痪窒抻谠跒g覽器、設(shè)備、操作系統(tǒng)結(jié)合的支持平臺(tái)的很小的一個(gè)子集上做一些輕量級(jí)自動(dòng)化功能測(cè)試，并且越來越難以依賴可以快速、便宜地運(yùn)行的底層測(cè)試。有時(shí)候想想這個(gè)問題就覺得自己弱爆了。
如果你對(duì)改進(jìn)未經(jīng)檢驗(yàn)（不可測(cè)試）的代碼問題感興趣，有一本書非常值得一讀： Working Effectively with Legacy Code，作者M(jìn)ichael Feathers將“遺留代碼”定義為任何沒有測(cè)試的代碼，在測(cè)試的話題上，唯一的底線是接受這一說法的真實(shí)性，即使其它約束會(huì)阻止你解決它。
過程自動(dòng)化
你很有可能認(rèn)為 Grunt是任務(wù)自動(dòng)化工具的不二選擇， Gulp和 Broccoli提供了一個(gè)不同的方法來進(jìn)行自動(dòng)構(gòu)建。我沒用過Broccoli，并且我只淺嘗了一下Gulp，即使Grunt有一定的局限性，但我絕對(duì)要感謝它依靠其它服務(wù)幫助我把復(fù)雜任務(wù)自動(dòng)化——尤其每天要運(yùn)行上千次任務(wù)的時(shí)候。
Yeoman在我2012年寫文章之后的45天就發(fā)布了。我承認(rèn)它剛一出來時(shí)我并沒有用它，但最近我（用不熟悉的技術(shù)從紙上草稿開始一個(gè)項(xiàng)目）嘗試找出如何標(biāo)準(zhǔn)化我們?cè)贐azaarvoice平臺(tái)上開發(fā)第三方JS應(yīng)用的方法，Yeoman的確在這些案例中閃閃發(fā)光。在命令行中輸入一個(gè)簡(jiǎn)單的yo react-webpack就可以為你創(chuàng)建一整個(gè)新項(xiàng)目，項(xiàng)目里的你想要的應(yīng)有盡有——測(cè)試、開發(fā)服務(wù)器、一個(gè)Hello World應(yīng)用，以及更多。如果React和Webpack不是你的菜，可能一個(gè)生成器就可以滿足你的需求，同樣，你可以很輕松地打造自己的生成器。
考慮到Y(jié)eoman是一個(gè)你通常只在項(xiàng)目開始的時(shí)候使用的工具。并且考慮到你不總會(huì)開始新的項(xiàng)目，它只是一個(gè)值得了解的工具。當(dāng)然了，如果你正在跨越項(xiàng)目嘗試標(biāo)準(zhǔn)化實(shí)踐，那么它或許還有那么一些價(jià)值的。
Broccoli作為ember-cli的核心被委以重任，我信任的人們說這一對(duì)兒將來會(huì)有大作為，還會(huì)改一個(gè)新的名字，在未來會(huì)逐步替代Grunt/Yeoman組合。使用Grunt和Yeoman組合進(jìn)行開發(fā)的確會(huì)漸漸淡出人們的視野，所以我們一起看看未來能帶來什么有趣的東西。
代碼質(zhì)量
如果你像我一樣，當(dāng)你只要看到代碼違反了項(xiàng)目良好的文檔風(fēng)格指南時(shí)就情不自禁開始抽搐，那么像 JSCS和 ESLint這樣的工具簡(jiǎn)直是天賜之物。2012年的時(shí)候他們都還沒有出現(xiàn)呢，他們都提供了一個(gè)格式化你的樣式指導(dǎo)規(guī)則的方法，然后在你創(chuàng)建一個(gè)pull request之前自動(dòng)地按照規(guī)則校驗(yàn)?zāi)愕拇a，說到這兒我們就不得不提Git了。
Git
我認(rèn)為自從2012年以來，世界范圍內(nèi)的Git工作流沒有太大的變化，話說回來，Github pull request頁(yè)面上仍然沒有給分支名加上鏈接，誰(shuí)知道是因?yàn)槭裁刺鞖⒌脑颉?/p>
很顯然，在特性分支下工作你應(yīng)該感到非常舒適，將你與他人的工作成果進(jìn)行衍合（rebase），借助交互式衍合工具來改寫（squash）提交，而且在小的單元里工作不太可能導(dǎo)致隨時(shí)可能產(chǎn)生的沖突。另一個(gè)必備的Git工具的是鉤子（hooks）——你尤其需要預(yù)推送和預(yù)提交鉤子來運(yùn)行你的測(cè)試案例并執(zhí)行所有代碼的質(zhì)量檢查。你可以自己寫這些鉤子，但類似于 ghooks這樣的工具可以幫你完成這些繁雜的過程，你沒有理由不將他們集成到你的工作流中去。
客戶端模板
對(duì)于一些“錯(cuò)誤”的定義可能是我在以前的文章中犯下的最大的錯(cuò)誤。客戶端模板仍然很有價(jià)值，毫無疑問——它的價(jià)值高到它將會(huì)內(nèi)建到ES2015中去——但過度濫用依然會(huì)有不好的后果。許多團(tuán)隊(duì)將所有的渲染工作轉(zhuǎn)移到瀏覽器中，極大的性能開銷使得這種“客戶端生成所有HTML”的方法逐漸失寵，這是來之不易的教訓(xùn)。成熟的項(xiàng)目現(xiàn)在都在服務(wù)器端生成HTML——甚至還預(yù)生成它，將它存儲(chǔ)為靜態(tài)文件可以快速響應(yīng)提供服務(wù)——然后在客戶端逐步補(bǔ)充這個(gè)HTML，當(dāng)事件觸發(fā)的時(shí)候用客戶端模板更新它。
我希望無論對(duì)于你還是我自己，在考慮到自己的決策對(duì)于性能的影響時(shí)，不僅局限于瀏覽器領(lǐng)域，這也就是我接下來要談到的……
Node
你說你很了解JavaScript，所以接下來的時(shí)間我期待你能夠深入研究Node，如果你知之甚少，那你起碼需要投入一點(diǎn)精力去了解它。的確，Node世界里有一些有關(guān)文件系統(tǒng)、流、服務(wù)器的知識(shí)，甚至還有一些完全與前端開發(fā)不一樣的范式，但作為前端開發(fā)者，如果你把這些寶貴的財(cái)富拒之門外將會(huì)極大地限制你的潛力。
即使你實(shí)際開發(fā)的產(chǎn)品沒有使用Node作為項(xiàng)目的后端，你仍然可以利用它來模擬后端服務(wù)的狀態(tài)來盡快完成前端開發(fā)。最起碼的，你應(yīng)該熟悉如何 初始化一個(gè)Node項(xiàng)目，如何配置一個(gè) Express服務(wù)器和路由，以及如何使用 request模塊來代理請(qǐng)求。
聯(lián)系客服
