你可以找到大量談?wù)撝R(shí)點(diǎn)、框架和工具的文章，這是知識(shí)都是獲得一份工作所需要知道的。我想說(shuō)一些不一樣的。在這篇文章中，我會(huì)說(shuō)一說(shuō)前端工程師應(yīng)有的心態(tài)，希望能夠回答最開(kāi)始的問(wèn)題：怎樣才能做到優(yōu)秀？

很多的人只是不斷地寫一些 CSS 和 Javascript 補(bǔ)丁直到他們發(fā)現(xiàn)這些東西可以正常的工作了，然后他們就不管了。我在代碼審查的過(guò)程中看到了很多這樣的做法。

我會(huì)經(jīng)常問(wèn)別人：“為什么你要在這里加一個(gè) float: left ？” 或者 “這個(gè) overflow:hidden 真的需要嗎？”，然后他們會(huì)回答：“我不知道，但是如果我刪掉他們，就出問(wèn)題了”。

Javascript 也一樣。我看到一些人用 setTimeout 來(lái)防止執(zhí)行順序上的問(wèn)題，或者是一些人濫用 stopPropagation() 而沒(méi)有考慮到它也許會(huì)影響頁(yè)面中的其他事件處理函數(shù)。

我遇到過(guò)很多相同或類似的問(wèn)題，如果你從來(lái)不花時(shí)間去了解問(wèn)題的根源所在，你會(huì)發(fā)現(xiàn)你會(huì)一遍一遍的遭遇同樣的困境。

花時(shí)間去深入的研究你的解決方案為什么可行看起來(lái)需要耗費(fèi)很多的精力，但是我發(fā)誓它會(huì)在將來(lái)給你節(jié)約很多時(shí)間。對(duì)你現(xiàn)在工作的系統(tǒng)有一個(gè)全面的理解可以減少你將來(lái)的猜測(cè)和檢查工作。

前端跟后端主要的不同是：后端的運(yùn)行環(huán)境在你的控制之下。但是對(duì)于前端而言，相比于后端，它完全不在你的控制范圍。你的用戶所使用的平臺(tái)或者設(shè)備隨時(shí)都有可能改變，你的代碼需要能夠優(yōu)雅地處理這種情況。

我記得早在2011年的時(shí)候，我在一個(gè)非常著名的 javascript 框架看到下面這樣一段源碼（大致如此）：

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

我知道在現(xiàn)實(shí)生活中， feature detaction 并不能100%的有效，有些時(shí)候我們不得不采用這種不好的方式或者瀏覽器白名單的方式，但是任何時(shí)候你這樣做的時(shí)候，你應(yīng)該預(yù)測(cè)未來(lái)可能會(huì)發(fā)生什么，即使發(fā)生，你的代碼也不應(yīng)該出現(xiàn)bug。

對(duì)于我們大多數(shù)人而言，我們?cè)诂F(xiàn)在的工作崗位上寫的代碼會(huì)比我們的任期更長(zhǎng)。我8年前寫的一些代碼現(xiàn)在還會(huì)經(jīng)常用到，這想起來(lái)既讓人滿足又讓讓感到可怕。

瀏覽器 bug 總是存在的，但是，當(dāng)兩個(gè)瀏覽器執(zhí)行相同的代碼表現(xiàn)卻不一致時(shí)，人們經(jīng)常假設(shè)，而不是親自去檢查，只是把他們認(rèn)為的表現(xiàn)好的叫做“正?！睘g覽器，表現(xiàn)異常的叫“不正常”瀏覽器。但并非總是這樣，當(dāng)你做出了錯(cuò)誤的假設(shè)時(shí)，任何你選擇的解決方法在未來(lái)也許會(huì)失效。

一個(gè)現(xiàn)實(shí)的例子就是 flex items 的默認(rèn)最小尺寸。根據(jù)官方文檔， flex items 的 min-width 和 min-height 是 auto (而不是 0)，這意味著，它們的尺寸不會(huì)比它們的內(nèi)容還要小。 但是在過(guò)去的8個(gè)月里，只有 Firefox 是唯一一個(gè)正確的實(shí)現(xiàn)這一標(biāo)準(zhǔn)的瀏覽器。

如果你遇到過(guò)這類跨瀏覽器的兼容性問(wèn)題，而且你注意到你的頁(yè)面在 Chrome，IE，Opera，和 Safari 上表現(xiàn)一致，唯獨(dú) Firefox 上表現(xiàn)不同時(shí)，你肯定會(huì)猜測(cè)這是 Firefox 自己的問(wèn)題。

當(dāng)兩個(gè)或多個(gè)瀏覽器在渲染相同的代碼表現(xiàn)不一致時(shí)， 你應(yīng)該花一些時(shí)間去研究到底哪個(gè)瀏覽器才是正確的，然后用正確的方式寫下你的代碼。你的作品才會(huì)是面向未來(lái)的。

另外，優(yōu)秀的前端工程師經(jīng)常都是站在變化的最前列的，他們會(huì)在這些技術(shù)成為主流之前就采用這些技術(shù)，甚至為這些技術(shù)作出貢獻(xiàn)。如果你憑借你自己的實(shí)力去查找官方文檔，而且能夠想象一個(gè)技術(shù)在你能夠在瀏覽器中用它的之前將會(huì)是如何工作的，你將成為能夠談?wù)撨@個(gè)官方標(biāo)準(zhǔn)會(huì)對(duì)開(kāi)發(fā)造成什么影響的人。

閱讀其他人的代碼，無(wú)疑是成為一個(gè)更好的開(kāi)發(fā)者的最好方式。

自己解決問(wèn)題是學(xué)習(xí)的最好方式，但是如果這些問(wèn)題都是你以前解決過(guò)的，你很快就會(huì)進(jìn)入平穩(wěn)期（很難有上升的空間）。閱讀其他人的代碼可以為你打開(kāi)處理問(wèn)題的新的思路。而且閱讀和理解別人寫的代碼的能力也是在跟團(tuán)隊(duì)合作或者參與開(kāi)源項(xiàng)目時(shí)至關(guān)重要的能力。

實(shí)際上，我認(rèn)為在面試一個(gè)應(yīng)聘者是只讓他們寫代碼--新的代碼，是最大的錯(cuò)誤。我應(yīng)聘的時(shí)候，從來(lái)沒(méi)有被叫過(guò)去閱讀一些已經(jīng)存在的代碼，在這些代碼中找出問(wèn)題，然后解決它。這是非常不好的，因?yàn)樽鳛橐粋€(gè)工程師，很多時(shí)候我們是在別人的代碼上添加和改變一些代碼。很少?gòu)念^寫一些新的。

在我印象你，比起后端開(kāi)發(fā)者，更多的前端開(kāi)發(fā)者希望成為一個(gè)自由職業(yè)者（全棧）。也許是前端工程師更趨向于自學(xué)，而后端工程師更趨向于學(xué)術(shù)。

自學(xué)并為你自己工作的問(wèn)題是無(wú)法從比你聰明的人身上得到好處。沒(méi)有人來(lái)跟你討論觀點(diǎn)或者幫你審查代碼。

我強(qiáng)烈的建議，至少在你職業(yè)生涯初期，在一個(gè)團(tuán)隊(duì)中工作，特別是跟一群比你更聰明更有經(jīng)驗(yàn)的人工作。

如果你已經(jīng)結(jié)束你的職業(yè)生涯，現(xiàn)在只是為你自己工作，那么參與到開(kāi)源中來(lái)。 貢獻(xiàn)開(kāi)源項(xiàng)目會(huì)給你很多與團(tuán)隊(duì)合作的機(jī)會(huì)。

在商業(yè)上，重復(fù)造輪子是不好的，但是對(duì)于學(xué)習(xí)來(lái)說(shuō)并非如此。你也許嘗試從 npm 上獲取預(yù)輸入控件或者事件委托庫(kù)，但是想象一下如果你自己嘗試創(chuàng)造這些東西的話會(huì)學(xué)到更多。

我確定一些正在閱讀這篇文章的人對(duì)此感到強(qiáng)烈反對(duì)。不要誤會(huì)我的意思。我不是說(shuō)你永遠(yuǎn)也不應(yīng)該使用第三方庫(kù)。使用優(yōu)秀的庫(kù)是非常明智的事情。

但是，在這篇文章中，我要說(shuō)的是如何從一個(gè)不錯(cuò)的工程師成為一個(gè)優(yōu)秀的工程師。大部分我認(rèn)為的這個(gè)領(lǐng)域中優(yōu)秀的工程師都是這些優(yōu)秀的第三方庫(kù)的維護(hù)者。

你也許從來(lái)沒(méi)有構(gòu)建夠自己的 javascript 庫(kù)，但是你依然能夠在你的職業(yè)生涯中獲得成功，但是，可能你從來(lái)沒(méi)有理解到解決問(wèn)題的核心。

在這個(gè)行業(yè)中，人們經(jīng)常問(wèn)起的一個(gè)問(wèn)題是：我接下來(lái)應(yīng)該做什么？ 如果你問(wèn)了這個(gè)問(wèn)題，為什么不去嘗試重新創(chuàng)造一個(gè)你喜歡的 javascript 庫(kù)或者 CSS 框架，而不是嘗試一些新的工具或者寫一個(gè)新的 app。 這樣做的好處是，及時(shí)你遇到了困難，你也可以從目前已有的庫(kù)中的源碼找到答案。

最后， 你應(yīng)該把你學(xué)到的東西寫下來(lái)。有太多的理由這樣做了，但是，也許最重要的原因是這樣可以強(qiáng)迫你更好地理解你所學(xué)的東西。如果你無(wú)法解釋其原理，這是一個(gè)很好的機(jī)會(huì)說(shuō)明你并沒(méi)有完全搞懂它。很多時(shí)候你沒(méi)有意識(shí)到你不懂，直到你把它寫下來(lái)。

在我的經(jīng)驗(yàn)中，書(shū)寫、做一個(gè)演講、以及寫一些 demos 是強(qiáng)迫我自己完全弄懂一個(gè)東西的最好方式，從里到外。即使沒(méi)有一個(gè)人會(huì)看你寫的東西，但是做這件事的過(guò)程更有價(jià)值。

文章地址：http://blog.mcbird.cn/2015/08/15/How-to-Become-a-Great-Front-End-Engineer/