翻譯自谷歌工程師PHILIP WALTON的一篇舊文，原文地址：How to Become a Great Front-End Engineer
我最近收到一封來自我部落格讀者的Email，不管是什麼原因，這封郵件讓我思考。這是郵件的上寫的：
Hi, Philip, 我可否問一下，你是怎麼成為前端大牛的？
對此，你能給我一些建議嗎？
我有點驚訝，因為我從沒覺得自己是前端「大牛」，事實上，在我進入這個行業的前幾年，我一點都不認為我能夠勝任我所在的工作崗位。我申請到這份工作，第一是因為我無知無畏，第二是因為面試我的人不知道問我什麼問題。
儘管如此，我最終憑藉出色的表現而成為團隊中有價值的一員。當我離開團隊時（為了下一個挑戰，雖然我還不具備能力）我經常被分配去招聘替補。當我回顧我如何完成這些面試時，令我感到驚訝的是，我非常強調知識——儘管我剛來的時候很缺乏知識。我目前的自己可能不會僱傭我以前的自己，即使從個人經驗上來說，我是有希望的。
隨著我做web開發的時間越長，我越覺得區分「好」與「優秀」，不在於你知道多少，而是在於你怎麼去思考。顯然，知識是重要的——在某些情況下非常重要——但是，在一個變化如此快速的領域，在任何時候，你如何獲得知識總是比（至少從長遠來看）你所知來得重要。總之，最重要的就是：你運用所學知識解決日常的問題的能力。
關於獲得工作需要知道的語言、框架、工具之類的文章已經多不勝數了，我想另闢蹊徑，從另一個角度來談談。在這篇文章，我將會討論一個前端工程師應有的思維模式，並希望給出更多經得起時間考驗的答案，來回答：如何成為大牛？
知其然，更要知其所以然
很多人寫CSS和JavaScripit補丁，僅僅止於，程式執行起來沒問題就好了。我知道有這回事，因為我經常在程式碼審查的時候看到。
我經常問一些人，「你為什麼在這裡加 float:left 呢？」，又或者問：「這個 overflow: hidden 是必要的嗎？」他們會回答：「我也不知道，但我把它去掉，程式就不能正常工作了。」
JavaScript的情況也是一樣。我會看到 setTimeout 被用來阻止一個競爭條件，又或者有人停止了事件冒泡，全然不顧它會對另一個頁面的事件處理產生影響。
我知道有時任務緊迫，你需要馬上實現某些功能，你沒時間深入理解其中的原理。但是，如果你從不花時間來理解問題的本質，你會發現，你一次又一次地被同樣的問題纏住。
花時間來想明白程式背後的原理似乎很費力，但我保證你以後會節省時間的。全面理解你所使用的系統，這樣就不用花很多時間在猜測和驗證上了。
考慮瀏覽器的向前相容
前端和後端一個主要的不同是，後端程式碼執行在一個可控的環境，而前端卻恰恰相反，完全超出你的控制。使用者的平臺或者裝置在任何時候都可能完全改變，你的程式碼需要完美地處理這些問題。
我記得在2011年的時候，我閱讀一個流行的JavaScript框架原始碼，我看到以下程式碼（程式碼已簡化）：
var isIE6 = !isIE7 && !isIE8 && !isIE9;
在這個例子中，IE6是所有版本的一個全部捕獲（譯註：非IE7且非IE8且非IE9時，isIE6==true），大概能處理比IE6更老的版本。但只要IE10出來，我們程式的大部分都要壞掉。
我理解，在現實情況中，我們不可能一直涵蓋所有情況，有時你可以依賴錯誤處理機制或者白名單中的瀏覽器，但任何時候考慮向前相容都是至關重要的。
對於大多數我們來說，我們今天寫的程式碼會比我們保有當前工作的時間還長。我 8 年前寫的一些程式碼仍然在大型生產環境下執行著呢！
閱讀文件
經常會有瀏覽器的bug，當相同的程式碼在兩種瀏覽器渲染出不同效果時，人們經常不假思索地斷定，「好」瀏覽器是正確的，「壞」瀏覽器是錯誤的。但真實情況卻常常相反，當你作出了錯誤的判斷，不管你選擇什麼解決方案，都很可能在未來產生錯誤。
一個現成的例子是flex元素的預設大小，根據文件，flex元素的初始最小寬度和最小高度是auto而不是0，這意味著默地，它會縮得比它的內容的最小大小還小。在過去的8個月，Firefox是唯一正確實現該特性的瀏覽器。
如果你遇到了這個跨瀏覽器的相容問題，並且注意到你的網站在 Chrome，IE,，Opera 和 Safari渲染正常，但在Firefox卻不一樣，你很可能會想：Firefox錯了。事實上，我經常遇到像這樣的情況。
有很多關於這個不相容的問題報告提交在這個專案上，並提出瞭解決方案。如果這些方案在兩週前Chrome 44 出來時實現了，這些問題就不能再重現了。
因為這些方案依照文件。
當有兩個或兩個以上瀏覽器以不同的方式渲染同樣的程式碼，你得想明白哪個是正確的，並且想出你的解決方。
此外，所謂的前端大牛，是這樣一些人，他們在新技術成為主流之前擁抱新技術，甚至參與改進這些技術。如果你培養你看文件和想像一個技術是如何實現的能力，你可能會成為精英團隊的一員，並且能夠討論和改進文件開發。
閱讀他人的程式碼
閱讀他人的程式碼，僅僅因為有趣，可能不是度過趣味星期六夜晚的好主意，但毫無疑問是成為優秀開發者的最好方法。
自己獨立解決問題是很好的學習方法，但如果你一直這樣做，你會很快達到你的瓶頸。閱讀他人的程式碼讓你開拓思維。另外，閱讀和理解他人的程式碼對於團隊協作和開源貢獻也是非常重要的。
我想一個公司招聘一個工程師時，所做的最大的錯誤是隻讓工程師們從零開始寫程式碼。面試時，我從沒有遇到過這樣的情況：讓我閱讀已有的程式碼，發現程式碼中的問題，然後將其修復。這真的很糟糕，因為你的程式設計師生涯中，很多時間只是在新增程式碼或者修改已新增的程式碼而已。你罕有時間是從一份已有的程式碼構建新的程式。
與比你聰明的人共事
在我的印象中，前端開發者比後端開發者更喜歡自由職業。這也許是因為前端開發者更傾向於自學，而後端開發者大多是科班出身。
自學和獨自工作都無益於從比你聰明的人那裡學習。你沒有人可以探討你的想法，沒有人檢查你的程式碼。
我強烈建議，至少在你的職業生涯的開始階段，你跟一個團隊一起工作，特別是成員比你更聰明，更有經驗的團隊。
如果你最終在你職業生涯的某個階段選擇獨自工作，你得重視參與開源專案。積極為開源專案做貢獻和與團隊協作一樣有益於你的成長，甚至更佳。
重新造輪子
重新造輪子無益於商業運作，但對於學習卻大有用處。我確信有些人可能會反對我的這個觀點。不要誤解我的意思。我不是說我們永遠不要用第三方程式碼。使用經過良好測試的第三方庫通常都是明智之舉。
但這篇文章談論的是如何從「好」到 「優秀」。很多我認為在這個行業優秀的人，通常是我經常使用的開源專案的建立者或者維護者。
你很可能沒有建立過自己的JavaScript庫也能有成功的職業生涯，但你永遠只是隔岸觀火。
從業者經常提的一個問題是：我下一步該構建什麼？如果你提了這個問題，而不是嘗試去學新的工具或者建立新的app，為什麼不重新創造你所喜歡的JavaScript庫或者CSS框架呢。這樣做有一大好處就是你不會被難題所困住，因為所有的答案都在現有的庫裡面。
記錄你所學
不是最後的最後一點，你必須把你所學的寫下來。這樣做有很多好的理由，但可能最好的理由是它強迫你更好地理解你所學的主題。對於一些問題，你百思不得其解，但經常你把它寫下來，你就理解了。
從我的經驗來看，寫作、演講、做展示一直是驅使我深入理解某些原理的最好方法。即使從沒有人閱讀你所寫的，但寫的本身就是有價值的。