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