本文記錄了兩位工程師為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的人，他們 “只求找到能夠執行的程式碼，然後就繼續下一步工作了。”很多時候，開發者並不瞭解某段程式碼執行的機制。（web前端學習交流群：328058344 禁止閒聊，非喜勿進！）

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，這些方法能夠迫使我對知識點進行充分的挖掘，並做到從內到外的完全理解。哪怕你寫的東西完全沒人看，但寫作的過程本身就已經值得你付出的努力了。”