如何成為一個偉大的前端工程師
最近，我的一個博客讀者給我發(fā)了一封電子郵件。內(nèi)容是：
你好，請問如何才能成為一個偉大的前端工程師？
你有什么好的建議嗎？
這讓我不由得陷入思考中。我不得不承認(rèn)看到這個問題的時候我很驚訝，因為我從未真正覺得自己是一個“偉大”的前端工程師。事實上，在這個行業(yè)開頭幾 年時間里，對于我的每一份工作，我甚至可以說我都是不合格的。我申請了這些職位——我沒有意識到自己懂得其實并不多，然后又因為面試官不知道該問什么問 題，又讓我通過了面試得到了工作。
話雖這么說，但***每一份工作我都完成得很好，并成為了團(tuán)隊中的重要成員。甚至于當(dāng)我要辭職的時候（奔赴下一個工作挑戰(zhàn)），我通常還會被要求負(fù)責(zé)找 到合適的人來頂替?；叵胛耶?dāng)初的面試——只將重點放在知識點上——我簡直要被自己蠢哭了?，F(xiàn)在的我根本不會聘請以前的自己來擔(dān)任這個職位，即使從我個人的 經(jīng)驗來看——我依然勝任了這個職位。
在網(wǎng)絡(luò)上工作的時間越長，我就越發(fā)意識到，能將優(yōu)秀人才和真正優(yōu)秀人才區(qū)分出來的不是他們知道什么，而是他們是如何思考的。顯然，知識很重要——在 有些情況下甚至是關(guān)鍵的——但在一個變化迅速的領(lǐng)域，如何去獲取知識更重要（至少從長遠(yuǎn)來看）。也許最重要的是：你如何利用這些知識來解決日常問題。
現(xiàn)在有很多的文章大談特談?wù)夜ぷ餍枰裁凑Z言、什么框架和什么工具。我不愿意走這條已經(jīng)走爛了的道路。所以在這篇文章中，我會談?wù)勄岸斯こ處煹乃季S模式，希望能夠解決一個永恒的問題：如何成為一個偉大的前端工程師？
不要只解決問題，要弄清楚到底發(fā)生了什么
很多用CSS和JavaScript的程序員碰到問題時，會一頭扎進(jìn)去，但一旦發(fā)現(xiàn)某種解決方法有效，就立刻馬不停蹄地進(jìn)入下一個環(huán)節(jié)。這在代碼審查環(huán)節(jié)已經(jīng)是司空見慣的情景。
我經(jīng)常會問：“你為什么要在這里添加float: left？”或者“此處的overflow: hidden真的有必要嗎？”，對方回答：“我不知道，但如果我刪掉的話，它就不工作了。”
JavaScript中的情況也是如此。我們可以看到setTimeout被用來防止多線程之間的資源競爭，或者阻止傳播那些不考慮對頁面上其他事件處理程序產(chǎn)生影響的事件。
我意識到，當(dāng)你需要完成某一個工作的時候，現(xiàn)在就解決出現(xiàn)的問題當(dāng)然是ok的。但如果你不花時間去了解這個問題的根源，那么你會發(fā)現(xiàn)自己將一次又一次地陷入同樣的問題中。
抽出點時間來弄清楚你的解決方案奏效的原因，這看似費時費力，但我保證將來它能節(jié)省你很多時間。更全面地理解你正在工作的系統(tǒng)，將意味著前進(jìn)道路上更少的猜測和檢查工作。
學(xué)會預(yù)測未來瀏覽器的變化
前端和后端代碼之間的主要區(qū)別就是后端代碼通常運行在一個受控制的環(huán)境中。相反的，前端則完全在控制之外。用戶使用的平臺和設(shè)備隨時可能徹底改變，所以你的代碼得能夠優(yōu)雅地處理這樣的情況。
我還記得2011年的時候我在一個流行的JavaScript框架的源代碼中，看到以下代碼行（為了簡便起見已作修改）：
var isIE6 = !isIE7 && !isIE8 && !isIE9;
在當(dāng)時的情況下，IE6的確涵蓋了所有的IE瀏覽器版本，能夠處理所有高于IE6的版本，但一旦IE10出來，應(yīng)用程序大部分地方就會徹底不行。
我知道在現(xiàn)實世界中特征檢測并不會100％時間工作，有時你不得不依靠bug行為或進(jìn)入白名單的瀏覽器，讓它們來幫助檢測錯誤，但是你這么做的時候，你得能預(yù)測到未來某個時候這些bug將不復(fù)存在，這個是絕對的關(guān)鍵。
對于許多人來說，今天寫的代碼的存活時間會比我們就職于當(dāng)前工作的時間要更久。我8年前一些代碼，今天依然在一些大型的生產(chǎn)網(wǎng)站運行，固步自封的思想，既令人滿足，又讓人害怕。
閱讀規(guī)格說明
瀏覽器bug是不可避免的，但是當(dāng)兩個瀏覽器對相同的代碼有著不同呈現(xiàn)的時候，人們往往不檢查自己，就直接認(rèn)為，那個所謂“好”的瀏覽器是正確的， “壞”的瀏覽器是錯誤的。但是，事實并不總是如此，當(dāng)你被這個假設(shè)所誤導(dǎo)的時候，無論你選擇了什么解決方案，將來幾乎都會肯定崩潰。
這方面的一個例子就是flex項目的默認(rèn)最小尺寸。根據(jù)規(guī)格說明，flex項目的初始min-width和min-height為auto（不是0），這意味著在默認(rèn)情況下，不能將其內(nèi)容收縮到比最小尺寸更小。在過去8個月時間里，F(xiàn)irefox是唯一正確實現(xiàn)這一目標(biāo)的瀏覽器。[1]
如果你遇到跨瀏覽器不兼容，發(fā)現(xiàn)你的網(wǎng)站呈現(xiàn)在Chrome、IE、Opera和Safari瀏覽器是相同的，但在Firefox上不一樣，你可能 會認(rèn)為火狐搞錯了。事實上，我親眼目睹過很多次這樣的情況。報告的許多Flexbug項目問題，實際上就是由于這種不兼容性引起的，而提出的解決方法，如 果實施的話，會在兩周前Chrome 44出來的時候失敗。不遵從規(guī)格說明的解決方法會在不知不覺中損害正確的行為。[2]
當(dāng)兩個或多個瀏覽器對相同的代碼卻有不同的呈現(xiàn)時，你應(yīng)該花時間找出哪一個是正確的，然后謹(jǐn)記這一點來寫代碼。這樣你的解決方法才不會在不久的將來成為過時的技術(shù)。
此外，所謂的“偉大”的前端工程師往往是那些敢于在主流之前先使用新技術(shù)，甚至促進(jìn)新技術(shù)發(fā)展的人。如果你能培養(yǎng)自己閱讀規(guī)格說明和展望技術(shù)前景的能力，那么你就會成為并影響規(guī)格說明發(fā)展的一份子。
閱讀他人的代碼
閱讀他人的代碼，可能并不有趣，但這毫無疑問是進(jìn)階為一個更優(yōu)秀的開發(fā)人員的***途徑之一。
依靠自己的本事來解決問題，是一個學(xué)習(xí)的好方法，但如果你只這么做，那你很快就會到達(dá)你的瓶頸。閱讀他人的代碼可以幫助你發(fā)現(xiàn)做事的新方法。閱讀和理解代碼是團(tuán)隊工作和合作開源項目時必不可少的能力。
其實，我覺得很多公司在聘用新的工程師時犯的***的錯誤就是，只要求他們寫代碼——從頭開始寫新的代碼。我從未在任何一場面試中說要求我閱讀一些現(xiàn) 有的代碼，去找這些代碼中的問題，然后解決這些問題。這真是太糟糕了，因為作為一個工程師你的大部分時間是花在增加或更改現(xiàn)有的代碼庫上的。很少需要你從 頭開始構(gòu)建新的東西。
和比你聰明的人一起工作
前端開發(fā)人員比后端開發(fā)人員更想成為自由職業(yè)者。也有可能是因為前端人往往是自學(xué)成才的，而后端人往往來自于正規(guī)學(xué)校。
但是自學(xué)成才和為自己工作也是有缺陷的，那就是你通常不會明白從比你聰明的人那兒學(xué)習(xí)的好處。不會有人給你建議，也沒有人為你檢查代碼。
我強烈建議至少在職業(yè)生涯的開始階段，一定要進(jìn)入一個團(tuán)隊工作，***團(tuán)隊人員比你聰明比你有經(jīng)驗。
如果你在你職業(yè)生涯某個時間點，不想只為自己工作了，那么不妨參與到開源項目中。積極推動開源項目能為你提供很多與團(tuán)隊工作相同的好處，有的時候甚至好處更多。
重新發(fā)明輪子
“重新發(fā)明輪子”對企業(yè)是不利的，但卻是偉大的學(xué)習(xí)方式。比如說你想掌握來自于npm的預(yù)輸入控件或事件委托類庫，那么不妨試想一下如果你自己來構(gòu)建這些東西，能幫助你學(xué)到多少。
我敢肯定看到這里一定有人想臭罵我一頓。別誤解我的意思。我不是說你不應(yīng)該使用第三方代碼。使用經(jīng)過充分測試的庫——坐享多年測試案例和bug報告總是明智的行為。
但在這篇文章中，我要說的是如何從優(yōu)秀進(jìn)步到偉大。在這個行業(yè)中大多數(shù)我認(rèn)為偉大的人，都是我們無時無刻不在使用的超級流行的庫的創(chuàng)造者或維護(hù)者。
可能你也有一個成功的職業(yè)生涯——但卻不曾構(gòu)建自己的JavaScript庫，那么你可能從未真正接近過它的本質(zhì)。
很多人會問的有關(guān)于這個行業(yè)的一個常見問題是：接下來我該構(gòu)建什么？如果你問這個問題，是因為不想去學(xué)習(xí)新的工具或創(chuàng)造新的app，那么給你個建 議：為什么不嘗試重建自己喜歡的JavaScript庫或CSS框架呢。這樣做的好處是，碰到問題的話，現(xiàn)有的庫的源代碼會明晃晃地告訴你所有的答案。
把你學(xué)到的東西寫下來
***但并非最不重要的一點是，你應(yīng)該把你學(xué)到的東西寫下來。這么做的理由有很多，但***的理由或許是這能迫使你更好地理解主題。如果你無法解釋它是如何工作的，那么很有可能其實你還沒有真正地理解。通常只有當(dāng)你嘗試將內(nèi)容寫下來的時候，才能發(fā)現(xiàn)自己其實還沒搞明白。
根據(jù)我的經(jīng)驗，寫作、發(fā)表演講、以及創(chuàng)建演示都是強迫自己從外到內(nèi)挖掘和充分理解事物的***方式之一。即使不會有人來閱讀你寫的東西，但是寫的這個過程絕對物超所值。
腳注：
[1].2014年12月1日Firefox在版本34中實現(xiàn)了規(guī)格說明變化，Chrome于2015年7月21日添加到日歷在版本44中實施，這意味著Opera很快也會這么做。Edge于2015年7月29號發(fā)布實施，而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
