如何成為一個偉大的前端工程師
最近，我的一個博客讀者給我發了一封電子郵件。內容是：
你好，請問如何才能成為一個偉大的前端工程師？
</blockquote>
你有什么好的建議嗎？這讓我不由得陷入思考中。我不得不承認看到這個問題的時候我很驚訝，因為我從未真正覺得自己是一個“偉大”的前端工程師。事實上，在這個行業開頭幾 年時間里，對于我的每一份工作，我甚至可以說我都是不合格的。我申請了這些職位——我沒有意識到自己懂得其實并不多，然后又因為面試官不知道該問什么問 題，又讓我通過了面試得到了工作。
話雖這么說，但最后每一份工作我都完成得很好，并成為了團隊中的重要成員。甚至于當我要辭職的時候（奔赴下一個工作挑戰），我通常還會被要求負責找 到合適的人來頂替。回想我當初的面試——只將重點放在知識點上——我簡直要被自己蠢哭了。現在的我根本不會聘請以前的自己來擔任這個職位，即使從我個人的 經驗來看——我依然勝任了這個職位。
在網絡上工作的時間越長，我就越發意識到，能將優秀人才和真正優秀人才區分出來的不是他們知道什么，而是他們是如何思考的。顯然，知識很重要——在 有些情況下甚至是關鍵的——但在一個變化迅速的領域，如何去獲取知識更重要（至少從長遠來看）。也許最重要的是：你如何利用這些知識來解決日常問題。
現在有很多的文章大談特談找工作需要什么語言、什么框架和什么工具。我不愿意走這條已經走爛了的道路。所以在這篇文章中，我會談談前端工程師的思維模式，希望能夠解決一個永恒的問題：如何成為一個偉大的前端工程師？
不要只解決問題，要弄清楚到底發生了什么
很多用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作為適用于未來的跨瀏覽器解決方案。
譯文鏈接： http://www.codeceo.com/article/how-to-be-great-front-end-engineer.html
英文原文： How to Become a Great Front-End Engineer
翻譯作者： 碼農網 – 小峰本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！