來自Google的前端工程師-Philip Walton 分享了自己關於如何成為優秀的工程師的一些觀點。個人感覺很有價值，所以翻譯成中文，方便大家閱讀。水平有限，如翻譯不妥之處請在評論中指出。
最近，我收到了讀者的郵件，引發了我的一些思考。這是他在郵件中問我的問題：
Hi Philip, is it okay to ask how you become a great front-end engineer? Any advice?
我不得不承認，我感到非常的驚訝，居然會被問到這樣的問題，因為我從來沒有想過自己是一個優秀的前端工程師。實際上，我在這個行業工作的前幾年裡，我真的不覺得我能夠勝任我的工作。我接受了這些工作只是因為我以前沒有意識到我知道得東西太少了，我能夠得到這些工作只是因為以前面試我的人不知道問我什麼問題。
話雖這麼說，我最後還是把我自己的角色做得非常好，而且成為了團隊裡有價值的一員。當我最後離職的時候（下一個職位我還是無法勝任）我通常也會應試那些將要應聘我的職位的人。現在回想那些我面試過的應聘者，讓我明白，看待知識的重要性。儘管我一開始在這個領域很薄弱。我現在的自己可能也不會僱傭以前的那個自己，儘管我知道隨著工作經驗的積累，成功也是可能的。
在Web領域，我工作的越久，越讓我意識到不錯的人和真正優秀的人的區別在於不是他們知道什麼，而是他們如何思考。 很明顯，知識是很重要的--特別是在某些情況下--但是，在一個快速變化的領域並非如此。你獲取知識的方式比你知道那些知識更為重要。而且也許最重要的是：你如何利用你的知識去解決日常生活中的問題。
你可以找到大量談論知識點、框架和工具的文章，這是知識都是獲得一份工作所需要知道的。我想說一些不一樣的。在這篇文章中，我會說一說前端工程師應有的心態，希望能夠回答最開始的問題：怎樣才能做到優秀？
不要只是解決問題，找到問題的根源所在
很多的人只是不斷地寫一些 CSS 和 Javascript 補丁直到他們發現這些東西可以正常的工作了，然後他們就不管了。我在程式碼審查的過程中看到了很多這樣的做法。
我會經常問別人：“為什麼你要在這裡加一個 float: left ？” 或者 “這個 overflow:hidden 真的需要嗎？”，然後他們會回答：“我不知道，但是如果我刪掉他們，就出問題了”。
Javascript 也一樣。我看到一些人用 setTimeout 來防止執行順序上的問題，或者是一些人濫用 stopPropagation() 而沒有考慮到它也許會影響頁面中的其他事件處理函式。
我遇到過很多相同或類似的問題，如果你從來不花時間去了解問題的根源所在，你會發現你會一遍一遍的遭遇同樣的困境。
花時間去深入的研究你的解決方案為什麼可行看起來需要耗費很多的精力，但是我發誓它會在將來給你節約很多時間。對你現在工作的系統有一個全面的理解可以減少你將來的猜測和檢查工作。
學會預測瀏覽器領域將來的變化
前端跟後端主要的不同是：後端的執行環境在你的控制之下。但是對於前端而言，相比於後端，它完全不在你的控制範圍。你的使用者所使用的平臺或者裝置隨時都有可能改變，你的程式碼需要能夠優雅地處理這種情況。
我記得早在2011年的時候，我在一個非常著名的 javascript 框架看到下面這樣一段原始碼（大致如此）：
var isIE6 = !isIE7 && !isIE8 && !isIE9;
我知道在現實生活中， feature detaction 並不能100%的有效，有些時候我們不得不採用這種不好的方式或者瀏覽器白名單的方式，但是任何時候你這樣做的時候，你應該預測未來可能會發生什麼，即使發生，你的程式碼也不應該出現bug。
對於我們大多數人而言，我們在現在的工作崗位上寫的程式碼會比我們的任期更長。我8年前寫的一些程式碼現在還會經常用到，這想起來既讓人滿足又讓讓感到可怕。
閱讀官方文件
瀏覽器 bug 總是存在的，但是，當兩個瀏覽器執行相同的程式碼表現卻不一致時，人們經常假設，而不是親自去檢查，只是把他們認為的表現好的叫做“正常”瀏覽器，表現異常的叫“不正常”瀏覽器。但並非總是這樣，當你做出了錯誤的假設時，任何你選擇的解決方法在未來也許會失效。
一個現實的例子就是 flex items 的預設最小尺寸。根據官方文件， flex items 的 min-width 和 min-height 是 auto (而不是 0)，這意味著，它們的尺寸不會比它們的內容還要小。 但是在過去的8個月裡，只有 Firefox 是唯一一個正確的實現這一標準的瀏覽器。
如果你遇到過這類跨瀏覽器的相容性問題，而且你注意到你的頁面在 Chrome，IE，Opera，和 Safari 上表現一致，唯獨 Firefox 上表現不同時，你肯定會猜測這是 Firefox 自己的問題。
當兩個或多個瀏覽器在渲染相同的程式碼表現不一致時， 你應該花一些時間去研究到底哪個瀏覽器才是正確的，然後用正確的方式寫下你的程式碼。你的作品才會是面向未來的。
另外，優秀的前端工程師經常都是站在變化的最前列的，他們會在這些技術成為主流之前就採用這些技術，甚至為這些技術作出貢獻。如果你憑藉你自己的實力去查詢官方文件，而且能夠想象一個技術在你能夠在瀏覽器中用它的之前將會是如何工作的，你將成為能夠談論這個官方標準會對開發造成什麼影響的人。
閱讀其他人的程式碼
閱讀其他人的程式碼，無疑是成為一個更好的開發者的最好方式。
自己解決問題是學習的最好方式，但是如果這些問題都是你以前解決過的，你很快就會進入平穩期（很難有上升的空間）。閱讀其他人的程式碼可以為你開啟處理問題的新的思路。而且閱讀和理解別人寫的程式碼的能力也是在跟團隊合作或者參與開源專案時至關重要的能力。
實際上，我認為在面試一個應聘者是隻讓他們寫程式碼--新的程式碼，是最大的錯誤。我應聘的時候，從來沒有被叫過去閱讀一些已經存在的程式碼，在這些程式碼中找出問題，然後解決它。這是非常不好的，因為作為一個工程師，很多時候我們是在別人的程式碼上新增和改變一些程式碼。很少從頭寫一些新的。
跟比你聰明的人一起工作
在我印象你，比起後端開發者，更多的前端開發者希望成為一個自由職業者（全棧）。也許是前端工程師更趨向於自學，而後端工程師更趨向於學術。
自學併為你自己工作的問題是無法從比你聰明的人身上得到好處。沒有人來跟你討論觀點或者幫你審查程式碼。
我強烈的建議，至少在你職業生涯初期，在一個團隊中工作，特別是跟一群比你更聰明更有經驗的人工作。
如果你已經結束你的職業生涯，現在只是為你自己工作，那麼參與到開源中來。 貢獻開源專案會給你很多與團隊合作的機會。
重複造輪子
在商業上，重複造輪子是不好的，但是對於學習來說並非如此。你也許嘗試從 npm 上獲取預輸入控制元件或者事件委託庫，但是想象一下如果你自己嘗試創造這些東西的話會學到更多。
我確定一些正在閱讀這篇文章的人對此感到強烈反對。不要誤會我的意思。我不是說你永遠也不應該使用第三方庫。使用優秀的庫是非常明智的事情。
但是，在這篇文章中，我要說的是如何從一個不錯的工程師成為一個優秀的工程師。大部分我認為的這個領域中優秀的工程師都是這些優秀的第三方庫的維護者。
你也許從來沒有構建夠自己的 javascript 庫，但是你依然能夠在你的職業生涯中獲得成功，但是，可能你從來沒有理解到解決問題的核心。
在這個行業中，人們經常問起的一個問題是：我接下來應該做什麼？ 如果你問了這個問題，為什麼不去嘗試重新創造一個你喜歡的 javascript 庫或者 CSS 框架，而不是嘗試一些新的工具或者寫一個新的 app。 這樣做的好處是，及時你遇到了困難，你也可以從目前已有的庫中的原始碼找到答案。
把你學到的東西寫下來
最後， 你應該把你學到的東西寫下來。有太多的理由這樣做了，但是，也許最重要的原因是這樣可以強迫你更好地理解你所學的東西。如果你無法解釋其原理，這是一個很好的機會說明你並沒有完全搞懂它。很多時候你沒有意識到你不懂，直到你把它寫下來。
在我的經驗中，書寫、做一個演講、以及寫一些 demos 是強迫我自己完全弄懂一個東西的最好方式，從裡到外。即使沒有一個人會看你寫的東西，但是做這件事的過程更有價值。
檢視完整組圖 上一頁 下一頁