成爲一名優秀的Web前端開發者

Rebecca Murphey是來自於Bazaarvoice的一位軟件工程師。今年早些時候，她發佈了一篇博客文章「前端（JS）開發者的基本素質之2015版」，爲JavaScript開發者在進行客戶端web開發時使用的工具與開發方式提出了一些建議。她在文章的總結中寫道：

學習ECMAScript 2015，推薦的參考資料有：《Understanding ES6》、ES6 Rocks以及BabelJS。咱們在此還要加上一條，即Axel Rauschmayer的著做《探索ES6》。考慮到在當前這個時間點上彷佛尚未必要了解ECMAScript 2015的全部細節，Murphey建議開發者更深刻地瞭解如何使用異步調用、回調以及promise。

使用模塊。Murphey相信，模塊毫無疑問應看成爲客戶端web應用程序的構建塊。她最近在使用webpack以實現模塊化的效果，但她但願讓每一個人都可以使用ECMAScript標準模塊的那一天可以早日到來。

測試你的代碼。在Murphey看來，爲你的代碼編寫測試，而且保證代碼的可測試性是相當重要的。雖然她對於Intern「很是中意」，但出於習慣，她仍是堅持使用Mocha。關於這一方面，她也強烈推薦Michael Feathers的著做《修改代碼的藝術》。

實現流程自動化。Murphey曾經嘗試使用Grunt與Gulp，但她最終仍是選擇了Yeoman。由於在「使用不熟悉的技術開始一個全新的項目」，或是對第三方JavaScript應用的開發進行標準化時，Yeoman的表現「很是出色」。Murphey也提到了Broccoli，認爲它未來或許可以取代Grunt和Yeoman。

編寫高質量的代碼。她的建議是，對「違反了項目中通過良好定義的風格指南」的代碼進行重構，還應當使用lint工具，例如JSCS或ESLint。

使用Git。Murphey建議在Git中使用特性分支，所以得以「經過交互式rebase，在與他人分享提交時對提交進行清理，而且儘量地在較小的單元上進行工做，以減小衝突的發生機率」。此外還應當經過ghooks在push操做與commit操做前運行鉤子操做。

在服務端生成HTML。出於性能方面的考慮，Murphey推薦在大型項目中儘量在服務端生成HTML。「預先生成這些文件，將其做爲靜態文件保存，以加快處理請求的速度。隨後在客戶端的相應事件中可經過客戶端代碼操做這些HTML文件，並在客戶端模板中修改。」

擁抱Node。Murphey建議web開發者熟練掌握Node.js的相關知識，至少要了解如何初始化一個Node項目、如何搭建一臺Express服務器、以及如何使用request模塊轉發請求。

Philip Walton是來自Google的一位軟件工程師，他最近撰寫了一篇博客文章「如何成爲一名優秀的前端工程師」。這篇文章的觀點另闢蹊徑，他並無向讀者推薦任何工具或框架，而是專一於如何處理這一領域中的某些挑戰。在他看來，優秀員工與真正傑出的人才的差異不在於他們的知識量，而在於他們的思考方式。他是這樣描述開發者的智慧的：

真正理解背後的過程。對於Walton來講，僅僅編寫出能夠運行的代碼算不得優秀。他見過許多編寫CSS與JavaScript的人，他們 「只求找到可以運行的代碼，而後就繼續下一步工做了。」不少時候，開發者並不瞭解某段代碼運行的機制。Walton建議開發者進行深刻鑽研：

要充分理解代碼的工做原理或許會很耗時間，但我向你保證，從長遠來講，這種方式最終將節省你大量的時間。一旦你充分理解你所參與的系統是如何運做的，你就無需不斷地進行猜想與檢驗這些費時的工做了。

預先了解瀏覽器將產生的改動。Web開發者應當持續瞭解有哪些瀏覽器的改動會破壞現有的代碼。如下代碼在IE10中必然會致使整個JavaScript框架的方法出錯：

var isIE6 = !isIE7 && !isIE8 && !isIE9;

仔細閱讀規範。Walton指出，雖然閱讀規範是一項艱辛的任務，但一旦出現瀏覽器對某個頁面的渲染不一樣的狀況，這一任務就是不可避免的了。他爲此特別舉例說明：

最近我遇到這樣一個例子，與可伸縮（flex）元素的默認最小尺寸有關。根據規範所說，可伸縮元素的min-width與min-height的初始值是auto，而不是0，這就意味着在默認狀況下，這些元素不可能收縮到比其中的內容尺寸還小。而在過去8個月中，Firefox是惟一一個正確地實現了這一特性的瀏覽器。

若是你遇到了這個跨瀏覽器的不一致性問題，而且注意到你的網站在Chrome、IE、Opera和Safari上的展示徹底相同，只在Firefox上有所差異，那你極可能會認爲是Firefox的問題。實際上，我曾屢次發現這一狀況，在個人Flexbugs項目中，有許多由用戶報告的bug其實都是由這種不一致性所致使的。而若是我按照用戶所提議的那些臨時方案來改變實現方式，那麼在兩週前所發佈的Chrome 44中又會產生問題。因爲這些臨時方案選擇了違背規範的方式，它們在無形中起到了提倡不正確行爲的負面做用。

代碼審查。Walton表示，從閱讀他人的代碼中能夠學到不少知識，它能夠拓寬你的思路，瞭解「新的工做方法」，同時也有助於你在團隊中的工做。實際上，這一點確實至關必要，由於「做爲一位工程師來講，你的時間大部分都是在一個現有的代碼庫中添加或修改代碼」，而不是從頭開始編寫全新的代碼。

與更聰明的人一塊兒工做。Walton「強烈」建議你至少在職業生涯的初期階段要儘可能在某個團隊中進行工做，向更有經驗的團隊成員學習，並讓他們審查你的代碼。若是以後選擇了自由職業者這條職業路線，那麼Walton建議你參與開源項目，這一樣能夠感覺到在團隊中工做的益處。

重複發明輪子。Walton相信，雖然「重複發明輪子對於業務來講是有害的」，但它對於學習頗有好處。在有些狀況下，他建議你本身編寫代碼，而不是依賴於第三方的代碼，由於這一過程將讓你學到許多東西。固然這也要看狀況而定。

將你的經驗記錄下來。Walton的最後一條建議是將你所學到的東西用文字記錄下來：「按個人經驗來看，寫做、演講以及開發demo，這些方法可以迫使我對知識點進行充分的挖掘，並作到從內到外的徹底理解。哪怕你寫的東西徹底沒人看，但寫做的過程自己就已經值得你付出的努力了。」

查看英文原文：Becoming a Great Web Front-end Developer