本文摘自同行說用戶“凌風(fēng)”分享的文章牛郑，原文鏈接：http://jiongks.name/blog/how-to-become-a-great-front-end-engineer/笙各，如涉及版權(quán)問題請及時聯(lián)系小編杈抢！
譯注：本文翻譯自谷歌工程師 Philip Walton 的一篇博客■昀粒看過之后非常有感觸窥岩，很多觀點(diǎn)都是自己長期非常堅(jiān)持和認(rèn)同的，所以翻譯出來分享給更多的前端同學(xué)朦乏！
最近我收到一封讀者來信讓我陷入了思考，信是這么寫的：
Hi Philip刽锤，您是否介意我問并思，您是如何成為一名卓越 (great) 的前端工程師的？對此您有什么建議嗎输涕？
不得不承認(rèn)，被問這樣的問題型奥，我很驚訝厢汹，因?yàn)槲覐膩聿挥X得自己是個很卓越的前端工程師界弧。甚至我入行的頭幾年時并不認(rèn)為自己可以做好這一行垢箕。我只確定自己比自己想象中還才疏學(xué)淺，而且大家面試我的時候都不知道從何問起
話雖這么說帅掘，我到現(xiàn)在做得還算不錯，而且成為了團(tuán)隊(duì)中有價值的一員吱窝。但我最終離開 (去尋求新的挑戰(zhàn)——即我還不能夠勝任的工作) 的時候，我經(jīng)常會被要求招聘我的繼任者。現(xiàn)在回看這些面試，我不禁感嘆當(dāng)我剛開始的時候自己在這方面的知識是多么的匱乏欢策。我現(xiàn)在或許不會按照我自己的模型進(jìn)行招聘踩寇，即便我個人的這種經(jīng)歷也有可能成功辣卒。
我在 web 領(lǐng)域工作越長時間，我就越意識到區(qū)分人才和頂尖人才的并不是他們的知識——而是他們思考問題的方式啡莉。很顯然，知識在很多情況下是非常重要而且關(guān)鍵的——但是在一個快速發(fā)展的領(lǐng)域该押，你前進(jìn)和獲取知識的方式 (至少在相當(dāng)長的一段時間里) 會比你已經(jīng)掌握的知識顯得更加重要。更重要的是：你是如何運(yùn)用這些知識解決每天的問題的奠蹬。
這里有許許多多的文章談?wù)撃愎ぷ髦行枰恼Z言、框架狸演、工具等等。我希望給一些不一樣的建議满哪。在這篇文章里哨鸭，我想談一談一個前端工程師的心態(tài)，希望可以幫助大家找到通往卓越的道路娇妓。
別光解決問題像鸡，想想究竟發(fā)生了什么
很多人埋頭寫 CSS 和 JavaScript 直到程序工作起來了，然后就去做別的事情了哈恰。我通過 code review 發(fā)現(xiàn)這種事經(jīng)常發(fā)生只估。
我總會問大家：“為什么你會在這里添加float: left？”或者“這里的overflow: hidden是必要的嗎仅乓？”赖舟，他們往往答道：“我也不知道，可是我一刪掉它們夸楣，頁面就亂套了宾抓。”
JavaScript 也是一樣豫喧，我總會在一個條件競爭的地方看到一個setTimeout石洗，或者有些人無意中阻止了事件傳播，卻不知道它會影響到頁面中其它的事件處理紧显。
我發(fā)現(xiàn)很多情況下讲衫，當(dāng)你遇到問題的時候，你只是解決當(dāng)下的問題罷了孵班。但是如果你永遠(yuǎn)不花時間理解問題的本源涉兽，你將一次又一次的面對相同的問題。
花一些時間找出為什么篙程，這看上去費(fèi)時費(fèi)力枷畏，但是我保證它會節(jié)省你未來的時間。在完全理解整個系統(tǒng)之后虱饿，你就不需要總?cè)ゲ聹y和論證了拥诡。
學(xué)會預(yù)見未來的瀏覽器發(fā)展趨勢
前后端開發(fā)的一個主要區(qū)別在于后端代碼通常都運(yùn)行在完全由你掌控的環(huán)境下。前端相對來說不那么在你的掌控之中氮发。不同用戶的平臺或設(shè)備是前端永恒的話題渴肉，你的代碼需要優(yōu)雅掌控這一切。
我記得自己 2011 年之前曾經(jīng)閱讀某主流 JavaScript 框架的時候看到過下面這樣的代碼 (簡化過的)：
JavaScript：
1?varisIE6=!isIE7&&!isIE8&&!isIE9;
在這個例子中變量 IE6 為了判斷 IE 瀏覽器版本是否是 6 或更低的版本爽冕。那么在 IE10 發(fā)布時仇祭，我們的程序判斷還是會出問題。
我理解在真實(shí)世界特性檢測并不 100% 工作扇售，而且有的時候你不得不依賴有 bug 的特性或根據(jù)瀏覽器特性檢測的錯誤設(shè)計(jì)白名單前塔。但你為此做的每一件事都非常關(guān)鍵，因?yàn)槟泐A(yù)見到了不再有 bug 的未來承冰。
對于我們當(dāng)中的很多人來說，我們今天寫的代碼都會比我們的工作周期要長食零。有些我寫的代碼已經(jīng)過去 8 年多了還在產(chǎn)品線上運(yùn)行困乒。這讓人很滿足又很不安。
閱讀規(guī)范文檔
瀏覽器有 bug 是很難免的事贰谣，但是當(dāng)同一份代碼在兩個瀏覽器渲染出來的效果不一樣娜搂，人們總會不假思索的推測迁霎，那個“廣受好評”的瀏覽器是對的，而“不起眼”的瀏覽器是錯的百宇。但事實(shí)并不一定如此考廉，當(dāng)你的假設(shè)出現(xiàn)錯誤時，你選取的變通辦法都會在未來遭遇問題携御。
一個就近的例子是 flex 元素的默認(rèn)最小尺寸問題昌粤。根據(jù)規(guī)范的描述，flex 元素初始化的min-width和min-height的值是auto(而不是 0)啄刹，也就是說它們默認(rèn)應(yīng)該收縮到自己內(nèi)容的最小尺寸涮坐。但是在過去長達(dá) 8 個月的時間里，只有 Firefox 的實(shí)現(xiàn)是準(zhǔn)確的誓军。[1]
如果你遇到了這個瀏覽器兼容性的問題并且發(fā)現(xiàn) Chrome袱讹、IE、Opera昵时、Safari 的效果相同而 Firefox 和它們不同時捷雕，你很可能會認(rèn)為是 Firefox 搞錯了。事實(shí)上這種情況我見多了壹甥。很多我在自己Flexbugs項(xiàng)目上報的問題都是這樣的救巷。而且這些解決方案的問題會在兩周之后 Chrome 44 修復(fù)之后被體現(xiàn)出來。和遵循標(biāo)準(zhǔn)的解決方案相比盹廷，這些方案都傷害到了正確的規(guī)范行為征绸。[2]
當(dāng)同一份代碼在兩個或更多瀏覽器的渲染結(jié)果不同時，你應(yīng)該花些時間確定哪個效果是正確的俄占，并且以此為標(biāo)準(zhǔn)寫代碼管怠。你的解決方案應(yīng)該是對未來友好的。
額外的缸榄，所謂“卓越”的前端工程師是時刻感受變化渤弛，在某項(xiàng)技術(shù)成為主流之前就去適應(yīng)它的，甚至在為這樣的技術(shù)做著貢獻(xiàn)甚带。如果你鍛煉自己看到規(guī)范就能在瀏覽器支持它之前想象出它如何工作的她肯，那么你將成為談?wù)摬⒂绊懫湟?guī)范開發(fā)的那群人。
閱讀別人的代碼
出于樂趣閱讀別人的代碼可能并不是你每周六晚上會想到的娛樂項(xiàng)目鹰贵，但是這毫無疑問是你成為優(yōu)秀工程師的最佳途徑晴氨。
自己獨(dú)立解決問題絕對是個不錯的方式，但是這不應(yīng)該是你唯一的方式碉输，因?yàn)樗芸炀蜁屇惴€(wěn)定在某個層次籽前。閱讀別人的代碼會讓你開闊思維，并且閱讀和理解別人寫的代碼也是團(tuán)隊(duì)協(xié)作或開源貢獻(xiàn)必須具備的能力。
我著實(shí)認(rèn)為很多公司在招聘新員工的時候犯的最大錯誤是他們只評估應(yīng)聘者從輪廓開始寫新代碼的能力枝哄。我?guī)缀鯖]有見過一場面試會要求應(yīng)聘者閱讀現(xiàn)有的代碼肄梨，找出其中的問題，并修復(fù)它們挠锥。缺少這樣的面試流程真的非常不好众羡，因?yàn)槟阕鳛楣こ處煹暮芏鄷r間都花費(fèi)在了在現(xiàn)有的代碼的基礎(chǔ)上增加或改變上門，而不是搭建新的東西蓖租。
與比你聰明的人一起工作
我印象中的很多前端開發(fā)者 (相比于全職工作來說) 都是自由職業(yè)者粱侣，有同類想法的后端開發(fā)者并沒有那么多〔饲兀可能是因?yàn)楹芏嗲岸硕际亲詫W(xué)成才的而后端則多是學(xué)校里學(xué)出來的甜害。
不論是自我學(xué)習(xí)還是自我工作，我們都面對一個問題：你并沒有機(jī)會從比你聰明的家伙那里學(xué)到什么球昨。沒有人幫你 review 代碼尔店，也沒有人與你碰撞靈感。
我強(qiáng)烈建議主慰，最起碼在你職業(yè)發(fā)展的前期嚣州，你要在一個團(tuán)隊(duì)里工作，尤其是一個普遍比你聰明而且有經(jīng)驗(yàn)的團(tuán)隊(duì)里工作共螺。
如果你最終會在你職業(yè)發(fā)展的某個階段選擇獨(dú)立工作该肴，一定要讓自己投身在開源社區(qū)當(dāng)中。保持對開源項(xiàng)目的活躍貢獻(xiàn)藐不，這會給你團(tuán)隊(duì)工作相同甚至更多的益處匀哄。
“造輪子”
造輪子在商業(yè)上是非常糟糕的，但是從學(xué)習(xí)的角度是非常好的雏蛮。你可能很想把那些庫和小工具直接從 npm 里拿下來用涎嚼，但也可以想象一下你獨(dú)立建造它們能夠?qū)W到多少東西。
我知道有些人讀到這里是特別不贊成的挑秉。別誤會法梯，我并沒有說你不應(yīng)該使用第三方代碼。那些經(jīng)過充分測試的庫具有多年的測試用例積累和已知問題積累犀概，使用它們絕對是非常明智的選擇立哑。
但在這里我想說的是如何從優(yōu)秀到卓越骑晶。我覺得這個領(lǐng)域很多卓越的人都是我每天在用的非常流行的庫的作者或維護(hù)者凿渊。
你可能不曾打造過自己的 JavaScript 庫也擁有一個成功的職業(yè)發(fā)展探赫，但是你從不把自己手弄臟是幾乎不可能淘到金子的举畸。
在這一行大家普遍會問的一個問題是：我接下來應(yīng)該做點(diǎn)什么？如果你沒有試著學(xué)一個新的工具創(chuàng)建一個新的應(yīng)用强重，那不妨試著重新造一個你喜歡的 JavaScript 庫或 CSS 框架镣典。這樣做的一個好消息是所计，在你遇到困難的時候镊叁，所有現(xiàn)成的庫的源代碼都會為你提供幫助尘颓。
把你學(xué)到的東西都記錄下來
最后，但絲毫不遜色的是晦譬，你應(yīng)該把你學(xué)到的東西記錄下來疤苹。這樣做有很多原因，但也許最重要的原因是它強(qiáng)迫你更好的理解這件事敛腌。如果你無法講清楚它的工作原理卧土，在整個過程中它會推動你自己把并不真正理解的東西弄清楚。很多情況下你根本意識不到自己還不理解它們——直到自己動手寫的時候像樊。
根據(jù)我的經(jīng)驗(yàn)尤莺，寫作、演講生棍、做 demo 是強(qiáng)迫自己完全深入理解一件事的最佳方式颤霎。就算你寫的東西沒有人看，整個過程也會讓你受益匪淺涂滴。
Footnotes:
Firefox implemented the spec change inversion 34on December 1, 2014. Chrome implemented it inversion 44on July 21, 2015, which means Opera will get it shortly. Edge shipped with this implemented on July 29, 2015. A Safari implementation appears to bein progress.
You can refer toFlexbug #1for a future-friendly, cross-browser workaround to this issue.
團(tuán)隊(duì)開發(fā)了一款工程師友酱、產(chǎn)品經(jīng)理必備神器【同行說】APP，找大牛柔纵、看最新最熱干貨缔杉，勾搭妹紙，快來同行說吧搁料！
