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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于我們當(dāng)中的很多人來(lái)說(shuō)，我們今天寫的代碼都會(huì)比我們的工作周期要長(zhǎng)。有些我寫的代碼已經(jīng)過去 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)遭遇問題。

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

如果你遇到了這個(gè)瀏覽器兼容性的問題并且發(fā)現(xiàn) Chrome、IE、Opera、Safari 的效果相同而 Firefox 和它們不同時(shí)，你很可能會(huì)認(rèn)為是 Firefox 搞錯(cuò)了。事實(shí)上這種情況我見多了。很多我在自己 Flexbugs 項(xiàng)目上報(bào)的問題都是這樣的。而且這些解決方案的問題會(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)寫代碼。你的解決方案應(yīng)該是對(duì)未來(lái)友好的。

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

閱讀別人的代碼

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

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

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

與比你聰明的人一起工作

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

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

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

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

“造輪子”

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

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

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

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

在這一行大家普遍會(huì)問的一個(gè)問題是：我接下來(lái)應(yīng)該做點(diǎn)什么？如果你沒有試著學(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è)過程中它會(huì)推動(dòng)你自己把并不真正理解的東西弄清楚。很多情況下你根本意識(shí)不到自己還不理解它們——直到自己動(dòng)手寫的時(shí)候。

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

Footnotes:

1. Firefox implemented the spec change in version 34 on December 1, 2014. Chrome implemented it in version 44 on July 21, 2015, which means Opera will get it shortly. Edge shipped with this implemented on July 29, 2015. A Safari implementation appears to be in progress.
2. You can refer to Flexbug #1 for a future-friendly, cross-browser workaround to this issue.

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

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