最近我收到一封讀者來(lái)信讓我陷入了思考，信是這么寫(xiě)的：

Hi Philip，您是否介意我問(wèn)您是如何成為一名卓越 (great) 的前端工程師的？對(duì)此您有什么建議嗎？

我不得不承認(rèn)，我很驚訝被問(wèn)這樣的問(wèn)題，因?yàn)槲覐膩?lái)不覺(jué)得自己是個(gè)很卓越的前端工程師。甚至我入行頭幾年時(shí)并不認(rèn)為自己可以做好這一行。我只確定自己比自己想象中還才疏學(xué)淺，而且大家面試我的時(shí)候都不知道從何問(wèn)起

話雖這么說(shuō)，我到現(xiàn)在做得還算不錯(cuò)，而且成為了團(tuán)隊(duì)中有價(jià)值的一員。但我最終離開(kāi) (去尋求新的挑戰(zhàn)——即我還不能夠勝任的工作) 的時(shí)候，我經(jīng)常會(huì)被要求招聘我的繼任者?，F(xiàn)在回看這些面試，我不禁感嘆當(dāng)我剛開(kāi)始的時(shí)候自己在這方面的知識(shí)是多么的匱乏。我現(xiàn)在或許不會(huì)按照我自己的模型 進(jìn)行招聘，即便我個(gè)人的這種經(jīng)歷也有可能成功。

我在 web 領(lǐng)域工作越長(zhǎng)時(shí)間，我就越意識(shí)到區(qū)分人才和***人才的并不是他們的知識(shí)——而是他們思考問(wèn)題的方式。很顯然，知識(shí)在很多情況下是非常重要而且關(guān)鍵的——但 是在一個(gè)快速發(fā)展的領(lǐng)域，你前進(jìn)和獲取知識(shí)的方式 (至少在相當(dāng)長(zhǎng)的一段時(shí)間里) 會(huì)比你已經(jīng)掌握的知識(shí)顯得更加重要。更重要的是：你是如何運(yùn)用這些知識(shí)解決每天的問(wèn)題的。

這里有許許多多的文章談?wù)撃愎ぷ髦行枰恼Z(yǔ)言、框架、工具等等。我希望給一些不一樣的建議。在這篇文章里，我想談一談一個(gè)前端工程師的心態(tài)，希望可以幫助大家找到通往卓越的道路。

別光解決問(wèn)題，想想究竟發(fā)生了什么

很多人埋頭寫(xiě) CSS 和 JavaScript 直到程序工作起來(lái)了，然后就去做別的事情了。我通過(guò) code review 發(fā)現(xiàn)這種事經(jīng)常發(fā)生。

我總會(huì)問(wèn)大家：“為什么你會(huì)在這里添加 float: left？”或者“這里的 overflow: hidden 是必要的嗎？”，他們往往答道：“我也不知道，可是我一刪掉它們，頁(yè)面就亂套了。”

JavaScript 也是一樣，我總會(huì)在一個(gè)條件競(jìng)爭(zhēng)的地方看到一個(gè) setTimeout，或者有些人無(wú)意中阻止了事件傳播，卻不知道它會(huì)影響到頁(yè)面中其它的事件處理。

我發(fā)現(xiàn)很多情況下，當(dāng)你遇到問(wèn)題的時(shí)候，你只是解決當(dāng)下的問(wèn)題罷了。但是如果你永遠(yuǎn)不花時(shí)間理解問(wèn)題的本源，你將一次又一次的面對(duì)相同的問(wèn)題。

花一些時(shí)間找出為什么，這看上去費(fèi)時(shí)費(fèi)力，但是我保證它會(huì)節(jié)省你未來(lái)的時(shí)間。在完全理解整個(gè)系統(tǒng)之后，你就不需要總?cè)ゲ聹y(cè)和論證了。

學(xué)會(huì)預(yù)見(jiàn)未來(lái)的瀏覽器發(fā)展趨勢(shì)

前后端開(kāi)發(fā)的一個(gè)主要區(qū)別在于后端代碼通常都運(yùn)行在完全由你掌控的環(huán)境下。前端相對(duì)來(lái)說(shuō)不那么在你的掌控之中。不同用戶的平臺(tái)或設(shè)備是前端永恒的話題，你的代碼需要優(yōu)雅掌控這一切。

我記得自己 2011 年之前曾經(jīng)閱讀某主流 JavaScript 框架的時(shí)候看到過(guò)下面這樣的代碼 (簡(jiǎn)化過(guò)的)：


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

在這個(gè)例子中變量 IE6 為了判斷 IE 瀏覽器版本是否是 6 或更低的版本。那么在 IE10 發(fā)布時(shí)，我們的程序判斷還是會(huì)出問(wèn)題。

我理解在真實(shí)世界特性檢測(cè)并不 100% 工作，而且有的時(shí)候你不得不依賴有 bug 的特性或根據(jù)瀏覽器特性檢測(cè)的錯(cuò)誤設(shè)計(jì)白名單。但你為此做的每一件事都非常關(guān)鍵，因?yàn)槟泐A(yù)見(jiàn)到了不再有 bug 的未來(lái)。

對(duì)于我們當(dāng)中的很多人來(lái)說(shuō)，我們今天寫(xiě)的代碼都會(huì)比我們的工作周期要長(zhǎng)。有些我寫(xiě)的代碼已經(jīng)過(guò)去 8 年多了還在產(chǎn)品線上運(yùn)行。這讓人很滿足又很不安。

閱讀規(guī)范文檔

瀏覽器有 bug 是很難免的事，但是當(dāng)同一份代碼在兩個(gè)瀏覽器渲染出來(lái)的效果不一樣，人們總會(huì)不假思索的推測(cè)，那個(gè)“廣受好評(píng)”的瀏覽器是對(duì)的，而“不起眼”的瀏覽器是錯(cuò)的。但事實(shí)并不一定如此，當(dāng)你的假設(shè)出現(xiàn)錯(cuò)誤時(shí)，你選取的變通辦法都會(huì)在未來(lái)遭遇問(wèn)題。

一個(gè)就近的例子是 flex 元素的默認(rèn)最小尺寸問(wèn)題。根據(jù)規(guī)范的描述，flex 元素初始化的 min-width 和 min-height 的值是 auto (而不是 0)，也就是說(shuō)它們默認(rèn)應(yīng)該收縮到自己內(nèi)容的最小尺寸。但是在過(guò)去長(zhǎng)達(dá) 8 個(gè)月的時(shí)間里，只有 Firefox 的實(shí)現(xiàn)是準(zhǔn)確的。[1]

如果你遇到了這個(gè)瀏覽器兼容性的問(wèn)題并且發(fā)現(xiàn) Chrome、IE、Opera、Safari 的效果相同而 Firefox 和它們不同時(shí)，你很可能會(huì)認(rèn)為是 Firefox 搞錯(cuò)了。事實(shí)上這種情況我見(jiàn)多了。很多我在自己 Flexbugs 項(xiàng)目上報(bào)的問(wèn)題都是這樣的。而且這些解決方案的問(wèn)題會(huì)在兩周之后 Chrome 44 修復(fù)之后被體現(xiàn)出來(lái)。和遵循標(biāo)準(zhǔn)的解決方案相比，這些方案都傷害到了正確的規(guī)范行為。[2]

當(dāng)同一份代碼在兩個(gè)或更多瀏覽器的渲染結(jié)果不同時(shí)，你應(yīng)該花些時(shí)間確定哪個(gè)效果是正確的，并且以此為標(biāo)準(zhǔn)寫(xiě)代碼。你的解決方案應(yīng)該是對(duì)未來(lái)友好的。

額外的，所謂“卓越”的前端工程師是時(shí)刻感受變化，在某項(xiàng)技術(shù)成為主流之前就去適應(yīng)它的，甚至在為這樣的技術(shù)做著貢獻(xiàn)。如果你鍛煉自己看到規(guī)范就能在瀏覽器支持它之前想象出它如何工作的，那么你將成為談?wù)摬⒂绊懫湟?guī)范開(kāi)發(fā)的那群人。

閱讀別人的代碼

出于樂(lè)趣閱讀別人的代碼可能并不是你每周六晚上會(huì)想到的娛樂(lè)項(xiàng)目，但是這毫無(wú)疑問(wèn)是你成為優(yōu)秀工程師的***途徑。

自己獨(dú)立解決問(wèn)題絕對(duì)是個(gè)不錯(cuò)的方式，但是這不應(yīng)該是你唯一的方式，因?yàn)樗芸炀蜁?huì)讓你穩(wěn)定在某個(gè)層次。閱讀別人的代碼會(huì)讓你開(kāi)闊思維，并且閱讀和理解別人寫(xiě)的代碼也是團(tuán)隊(duì)協(xié)作或開(kāi)源貢獻(xiàn)必須具備的能力。

我著實(shí)認(rèn)為很多公司在招聘新員工的時(shí)候犯的***錯(cuò)誤是他們只評(píng)估應(yīng)聘者從輪廓開(kāi)始寫(xiě)新代碼的能力。我?guī)缀鯖](méi)有見(jiàn)過(guò)一場(chǎng)面試會(huì)要求應(yīng)聘者閱讀現(xiàn)有的代 碼，找出其中的問(wèn)題，并修復(fù)它們。缺少這樣的面試流程真的非常不好，因?yàn)槟阕鳛楣こ處煹暮芏鄷r(shí)間都花費(fèi)在了在現(xiàn)有的代碼的基礎(chǔ)上增加或改變上門(mén)，而不是搭 建新的東西。

與比你聰明的人一起工作

我印象中的很多前端開(kāi)發(fā)者 (相比于全職工作來(lái)說(shuō)) 都是自由職業(yè)者，有同類想法的后端開(kāi)發(fā)者并沒(méi)有那么多。可能是因?yàn)楹芏嗲岸硕际亲詫W(xué)成才的而后端則多是學(xué)校里學(xué)出來(lái)的。

不論是自我學(xué)習(xí)還是自我工作，我們都面對(duì)一個(gè)問(wèn)題：你并沒(méi)有機(jī)會(huì)從比你聰明的家伙那里學(xué)到什么。沒(méi)有人幫你 review 代碼，也沒(méi)有人與你碰撞靈感。

我強(qiáng)烈建議，最起碼在你職業(yè)發(fā)展的前期，你要在一個(gè)團(tuán)隊(duì)里工作，尤其是一個(gè)普遍比你聰明而且有經(jīng)驗(yàn)的團(tuán)隊(duì)里工作。

如果你最終會(huì)在你職業(yè)發(fā)展的某個(gè)階段選擇獨(dú)立工作，一定要讓自己投身在開(kāi)源社區(qū)當(dāng)中。保持對(duì)開(kāi)源項(xiàng)目的活躍貢獻(xiàn)，這會(huì)給你團(tuán)隊(duì)工作相同甚至更多的益處。

“造輪子”

造輪子在商業(yè)上是非常糟糕的，但是從學(xué)習(xí)的角度是非常好的。你可能很想把那些庫(kù)和小工具直接從 npm 里拿下來(lái)用，但也可以想象一下你獨(dú)立建造它們能夠?qū)W到多少東西。

我知道有些人讀到這里是特別不贊成的。別誤會(huì)，我并沒(méi)有說(shuō)你不應(yīng)該使用第三方代碼。那些經(jīng)過(guò)充分測(cè)試的庫(kù)具有多年的測(cè)試用例積累和已知問(wèn)題積累，使用它們絕對(duì)是非常明智的選擇。

但在這里我想說(shuō)的是如何從優(yōu)秀到卓越。我覺(jué)得這個(gè)領(lǐng)域很多卓越的人都是我每天在用的非常流行的庫(kù)的作者或維護(hù)者。

你可能不曾打造過(guò)自己的 JavaScript 庫(kù)也擁有一個(gè)成功的職業(yè)發(fā)展，但是你從不把自己手弄臟是幾乎不可能淘到金子的。

在這一行大家普遍會(huì)問(wèn)的一個(gè)問(wèn)題是：我接下來(lái)應(yīng)該做點(diǎn)什么？如果你沒(méi)有試著學(xué)一個(gè)新的工具創(chuàng)建一個(gè)新的應(yīng)用，那不妨試著重新造一個(gè)你喜歡的 JavaScript 庫(kù)或 CSS 框架。這樣做的一個(gè)好消息是，在你遇到困難的時(shí)候，所有現(xiàn)成的庫(kù)的源代碼都會(huì)為你提供幫助。

把你學(xué)到的東西都記錄下來(lái)

***，但絲毫不遜色的是，你應(yīng)該把你學(xué)到的東西記錄下來(lái)。這樣做有很多原因，但也許最重要的原因是它強(qiáng)迫你更好的理解這件事。如果你無(wú)法講清楚它的工作原理，在整個(gè)過(guò)程中它會(huì)推動(dòng)你自己把并不真正理解的東西弄清楚。很多情況下你根本意識(shí)不到自己還不理解它們——直到自己動(dòng)手寫(xiě)的時(shí)候。

根據(jù)我的經(jīng)驗(yàn)，寫(xiě)作、演講、做 demo 是強(qiáng)迫自己完全深入理解一件事的***方式。就算你寫(xiě)的東西沒(méi)有人看，整個(gè)過(guò)程也會(huì)讓你受益匪淺。

該文章來(lái)自于阿里巴巴技術(shù)協(xié)會(huì)（ATA）作者：勾股

英文原文：philipwalton.com，譯文：aliyun.com