如何成為一個偉大的前端工程師

最近，我的一個部落格讀者給我發了一封電子郵件。內容是：

你好，請問如何才能成為一個偉大的前端工程師？
你有什麼好的建議嗎？

這讓我不由得陷入思考中。我不得不承認看到這個問題的時候我很驚訝，因為我從未真正覺得自己是一個“偉大”的前端工程師。事實上，在這個行業開頭幾年時間裡，對於我的每一份工作，我甚至可以說我都是不合格的。我申請了這些職位——我沒有意識到自己懂得其實並不多，然後又因為面試官不知道該問什麼問題，又讓我透過了面試得到了工作。

話雖這麼說，但最後每一份工作我都完成得很好，併成為了團隊中的重要成員。甚至於當我要辭職的時候（奔赴下一個工作挑戰），我通常還會被要求負責找到合適的人來頂替。回想我當初的面試——只將重點放在知識點上——我簡直要被自己蠢哭了。現在的我根本不會聘請以前的自己來擔任這個職位，即使從我個人的經驗來看——我依然勝任了這個職位。

在網路上工作的時間越長，我就越發意識到，能將優秀人才和真正優秀人才區分出來的不是他們知道什麼，而是他們是如何思考的。顯然，知識很重要——在有些情況下甚至是關鍵的——但在一個變化迅速的領域，如何去獲取知識更重要（至少從長遠來看）。也許最重要的是：你如何利用這些知識來解決日常問題。

現在有很多的文章大談特談找工作需要什麼語言、什麼框架和什麼工具。我不願意走這條已經走爛了的道路。所以在這篇文章中，我會談談前端工程師的思維模式，希望能夠解決一個永恆的問題：如何成為一個偉大的前端工程師？

不要只解決問題，要弄清楚到底發生了什麼

很多用CSS和JavaScript的程式設計師碰到問題時，會一頭扎進去，但一旦發現某種解決方法有效，就立刻馬不停蹄地進入下一個環節。這在程式碼審查環節已經是司空見慣的情景。

我經常會問：“你為什麼要在這裡新增float: left？”或者“此處的overflow: hidden真的有必要嗎？”，對方回答：“我不知道，但如果我刪掉的話，它就不工作了。”

JavaScript中的情況也是如此。我們可以看到setTimeout被用來防止多執行緒之間的資源競爭，或者阻止傳播那些不考慮對頁面上其他事件處理程式產生影響的事件。

我意識到，當你需要完成某一個工作的時候，現在就解決出現的問題當然是ok的。但如果你不花時間去了解這個問題的根源，那麼你會發現自己將一次又一次地陷入同樣的問題中。

抽出點時間來弄清楚你的解決方案奏效的原因，這看似費時費力，但我保證將來它能節省你很多時間。更全面地理解你正在工作的系統，將意味著前進道路上更少的猜測和檢查工作。

學會預測未來瀏覽器的變化

前端和後端程式碼之間的主要區別就是後端程式碼通常執行在一個受控制的環境中。相反的，前端則完全在控制之外。使用者使用的平臺和裝置隨時可能徹底改變，所以你的程式碼得能夠優雅地處理這樣的情況。

我還記得2011年的時候我在一個流行的JavaScript框架的原始碼中，看到以下程式碼行（為了簡便起見已作修改）：

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

在當時的情況下，IE6的確涵蓋了所有的IE瀏覽器版本，能夠處理所有高於IE6的版本，但一旦IE10出來，應用程式大部分地方就會徹底不行。

我知道在現實世界中特徵檢測並不會100％時間工作，有時你不得不依靠bug行為或進入白名單的瀏覽器，讓它們來幫助檢測錯誤，但是你這麼做的時候，你得能預測到未來某個時候這些bug將不復存在，這個是絕對的關鍵。

對於許多人來說，今天寫的程式碼的存活時間會比我們就職於當前工作的時間要更久。我8年前一些程式碼，今天依然在一些大型的生產網站執行，固步自封的思想，既令人滿足，又讓人害怕。

閱讀規格說明

瀏覽器bug是不可避免的，但是當兩個瀏覽器對相同的程式碼有著不同呈現的時候，人們往往不檢查自己，就直接認為，那個所謂“好”的瀏覽器是正確的，“壞”的瀏覽器是錯誤的。但是，事實並不總是如此，當你被這個假設所誤導的時候，無論你選擇了什麼解決方案，將來幾乎都會肯定崩潰。

這方面的一個例子就是flex專案的預設最小尺寸。根據規格說明，flex專案的初始min-width和min-height為auto（不是0），這意味著在預設情況下，不能將其內容收縮到比最小尺寸更小。在過去8個月時間裡，Firefox是唯一正確實現這一目標的瀏覽器。[1]

如果你遇到跨瀏覽器不相容，發現你的網站呈現在Chrome、IE、Opera和Safari瀏覽器是相同的，但在Firefox上不一樣，你可能會認為火狐搞錯了。事實上，我親眼目睹過很多次這樣的情況。報告的許多Flexbug專案問題，實際上就是由於這種不相容性引起的，而提出的解決方法，如果實施的話，會在兩週前Chrome 44出來的時候失敗。不遵從規格說明的解決方法會在不知不覺中損害正確的行為。[2]

當兩個或多個瀏覽器對相同的程式碼卻有不同的呈現時，你應該花時間找出哪一個是正確的，然後謹記這一點來寫程式碼。這樣你的解決方法才不會在不久的將來成為過時的技術。

此外，所謂的“偉大”的前端工程師往往是那些敢於在主流之前先使用新技術，甚至促進新技術發展的人。如果你能培養自己閱讀規格說明和展望技術前景的能力，那麼你就會成為並影響規格說明發展的一份子。

閱讀他人的程式碼

閱讀他人的程式碼，可能並不有趣，但這毫無疑問是進階為一個更優秀的開發人員的最佳途徑之一。

依靠自己的本事來解決問題，是一個學習的好方法，但如果你只這麼做，那你很快就會到達你的瓶頸。閱讀他人的程式碼可以幫助你發現做事的新方法。閱讀和理解程式碼是團隊工作和合作開源專案時必不可少的能力。

其實，我覺得很多公司在聘用新的工程師時犯的最大的錯誤就是，只要求他們寫程式碼——從頭開始寫新的程式碼。我從未在任何一場面試中說要求我閱讀一些現有的程式碼，去找這些程式碼中的問題，然後解決這些問題。這真是太糟糕了，因為作為一個工程師你的大部分時間是花在增加或更改現有的程式碼庫上的。很少需要你從頭開始構建新的東西。

和比你聰明的人一起工作

前端開發人員比後端開發人員更想成為自由職業者。也有可能是因為前端人往往是自學成才的，而後端人往往來自於正規學校。

但是自學成才和為自己工作也是有缺陷的，那就是你通常不會明白從比你聰明的人那兒學習的好處。不會有人給你建議，也沒有人為你檢查程式碼。

我強烈建議至少在職業生涯的開始階段，一定要進入一個團隊工作，最好團隊人員比你聰明比你有經驗。

如果你在你職業生涯某個時間點，不想只為自己工作了，那麼不妨參與到開源專案中。積極推動開源專案能為你提供很多與團隊工作相同的好處，有的時候甚至好處更多。

重新發明輪子

“重新發明輪子”對企業是不利的，但卻是偉大的學習方式。比如說你想掌握來自於npm的預輸入控制元件或事件委託類庫，那麼不妨試想一下如果你自己來構建這些東西，能幫助你學到多少。

我敢肯定看到這裡一定有人想臭罵我一頓。別誤解我的意思。我不是說你不應該使用第三方程式碼。使用經過充分測試的庫——坐享多年測試案例和bug報告總是明智的行為。

但在這篇文章中，我要說的是如何從優秀進步到偉大。在這個行業中大多數我認為偉大的人，都是我們無時無刻不在使用的超級流行的庫的創造者或維護者。

可能你也有一個成功的職業生涯——但卻不曾構建自己的JavaScript庫，那麼你可能從未真正接近過它的本質。

很多人會問的有關於這個行業的一個常見問題是：接下來我該構建什麼？如果你問這個問題，是因為不想去學習新的工具或創造新的app，那麼給你個建議：為什麼不嘗試重建自己喜歡的JavaScript庫或CSS框架呢。這樣做的好處是，碰到問題的話，現有的庫的原始碼會明晃晃地告訴你所有的答案。

把你學到的東西寫下來

最後但並非最不重要的一點是，你應該把你學到的東西寫下來。這麼做的理由有很多，但最好的理由或許是這能迫使你更好地理解主題。如果你無法解釋它是如何工作的，那麼很有可能其實你還沒有真正地理解。通常只有當你嘗試將內容寫下來的時候，才能發現自己其實還沒搞明白。

根據我的經驗，寫作、發表演講、以及建立演示都是強迫自己從外到內挖掘和充分理解事物的最佳方式之一。即使不會有人來閱讀你寫的東西，但是寫的這個過程絕對物超所值。

腳註：

[1].2014年12月1日Firefox在版本34中實現了規格說明變化，Chrome於2015年7月21日新增到日曆在版本44中實施，這意味著Opera很快也會這麼做。Edge於2015年7月29號釋出實施，而Safari似乎正在實施醞釀中。

[2].對於這個問題可以參考Flexbug＃1作為適用於未來的跨瀏覽器解決方案。