|
譯注：本文翻譯自谷歌工程師 Philip Walton 的一篇博客。看過之后非常有感觸，很多觀點都是自己長期非常堅持和認同的，所以翻譯出來分享給更多的前端同學(xué)！ 最近我收到一封讀者來信讓我陷入了思考，信是這么寫的：
不得不承認，被問這樣的問題，我很驚訝，因為我從來不覺得自己是個很卓越的前端工程師。甚至我入行的頭幾年時并不認為自己可以做好這一行。我只確定自己比自己想象中還才疏學(xué)淺，而且大家面試我的時候都不知道從何問起。 話雖這么說，我到現(xiàn)在做得還算不錯，而且成為了團隊中有價值的一員。但我最終離開 (去尋求新的挑戰(zhàn)——即我還不能夠勝任的工作) 的時候，我經(jīng)常會被要求招聘我的繼任者?，F(xiàn)在回看這些面試，我不禁感嘆當我剛開始的時候自己在這方面的知識是多么的匱乏。我現(xiàn)在或許不會按照我自己的模型進行招聘，即便我個人的這種經(jīng)歷也有可能成功。 我在 web 領(lǐng)域工作越長時間，我就越意識到區(qū)分人才和頂尖人才的并不是他們的知識——而是他們思考問題的方式。很顯然，知識在很多情況下是非常重要而且關(guān)鍵的——但是在一個快速發(fā)展的領(lǐng)域，你前進和獲取知識的方式 (至少在相當長的一段時間里) 會比你已經(jīng)掌握的知識顯得更加重要。更重要的是：你是如何運用這些知識解決每天的問題的。 這里有許許多多的文章談?wù)撃愎ぷ髦行枰恼Z言、框架、工具等等。我希望給一些不一樣的建議。在這篇文章里，我想談一談一個前端工程師的心態(tài)，希望可以幫助大家找到通往卓越的道路。 別光解決問題，想想究竟發(fā)生了什么 很多人埋頭寫 CSS 和 JavaScript 直到程序工作起來了，然后就去做別的事情了。我通過 code review 發(fā)現(xiàn)這種事經(jīng)常發(fā)生。 我總會問大家：“為什么你會在這里添加 float: left？”或者“這里的 overflow: hidden 是必要的嗎？”，他們往往答道：“我也不知道，可是我一刪掉它們，頁面就亂套了?！?/p> JavaScript 也是一樣，我總會在一個條件競爭的地方看到一個 setTimeout，或者有些人無意中阻止了事件傳播，卻不知道它會影響到頁面中其它的事件處理。 我發(fā)現(xiàn)很多情況下，當你遇到問題的時候，你只是解決當下的問題罷了。但是如果你永遠不花時間理解問題的本源，你將一次又一次的面對相同的問題。 花一些時間找出為什么，這看上去費時費力，但是我保證它會節(jié)省你未來的時間。在完全理解整個系統(tǒng)之后，你就不需要總?cè)ゲ聹y和論證了。 學(xué)會預(yù)見未來的瀏覽器發(fā)展趨勢 前后端開發(fā)的一個主要區(qū)別在于后端代碼通常都運行在完全由你掌控的環(huán)境下。前端相對來說不那么在你的掌控之中。不同用戶的平臺或設(shè)備是前端永恒的話題，你的代碼需要優(yōu)雅掌控這一切。 我記得自己 2011 年之前曾經(jīng)閱讀某主流 JavaScript 框架的時候看到過下面這樣的代碼 (簡化過的)：
在這個例子中變量 IE6 為了判斷 IE 瀏覽器版本是否是 6 或更低的版本。那么在 IE10 發(fā)布時，我們的程序判斷還是會出問題。 我理解在真實世界特性檢測并不 100% 工作，而且有的時候你不得不依賴有 bug 的特性或根據(jù)瀏覽器特性檢測的錯誤設(shè)計白名單。但你為此做的每一件事都非常關(guān)鍵，因為你預(yù)見到了不再有 bug 的未來。 對于我們當中的很多人來說，我們今天寫的代碼都會比我們的工作周期要長。有些我寫的代碼已經(jīng)過去 8 年多了還在產(chǎn)品線上運行。這讓人很滿足又很不安。 閱讀規(guī)范文檔 瀏覽器有 bug 是很難免的事，但是當同一份代碼在兩個瀏覽器渲染出來的效果不一樣，人們總會不假思索的推測，那個“廣受好評”的瀏覽器是對的，而“不起眼”的瀏覽器是錯的。但事實并不一定如此，當你的假設(shè)出現(xiàn)錯誤時，你選取的變通辦法都會在未來遭遇問題。 一個就近的例子是 flex 元素的默認最小尺寸問題。根據(jù)規(guī)范的描述，flex 元素初始化的 min-width 和 min-height 的值是 auto (而不是 0)，也就是說它們默認應(yīng)該收縮到自己內(nèi)容的最小尺寸。但是在過去長達 8 個月的時間里，只有 Firefox 的實現(xiàn)是準確的。 如果你遇到了這個瀏覽器兼容性的問題并且發(fā)現(xiàn) Chrome、IE、Opera、Safari 的效果相同而 Firefox 和它們不同時，你很可能會認為是 Firefox 搞錯了。事實上這種情況我見多了。很多我在自己 Flexbugs 項目上報的問題都是這樣的。而且這些解決方案的問題會在兩周之后 Chrome 44 修復(fù)之后被體現(xiàn)出來。和遵循標準的解決方案相比，這些方案都傷害到了正確的規(guī)范行為。 當同一份代碼在兩個或更多瀏覽器的渲染結(jié)果不同時，你應(yīng)該花些時間確定哪個效果是正確的，并且以此為標準寫代碼。你的解決方案應(yīng)該是對未來友好的。 額外的，所謂“卓越”的前端工程師是時刻感受變化，在某項技術(shù)成為主流之前就去適應(yīng)它的，甚至在為這樣的技術(shù)做著貢獻。如果你鍛煉自己看到規(guī)范就能在瀏覽器支持它之前想象出它如何工作的，那么你將成為談?wù)摬⒂绊懫湟?guī)范開發(fā)的那群人。 閱讀別人的代碼 出于樂趣閱讀別人的代碼可能并不是你每周六晚上會想到的娛樂項目，但是這毫無疑問是你成為優(yōu)秀工程師的最佳途徑。 自己獨立解決問題絕對是個不錯的方式，但是這不應(yīng)該是你唯一的方式，因為它很快就會讓你穩(wěn)定在某個層次。閱讀別人的代碼會讓你開闊思維，并且閱讀和理解別人寫的代碼也是團隊協(xié)作或開源貢獻必須具備的能力。 我著實認為很多公司在招聘新員工的時候犯的最大錯誤是他們只評估應(yīng)聘者從輪廓開始寫新代碼的能力。我?guī)缀鯖]有見過一場面試會要求應(yīng)聘者閱讀現(xiàn)有的代碼，找出其中的問題，并修復(fù)它們。缺少這樣的面試流程真的非常不好，因為你作為工程師的很多時間都花費在了在現(xiàn)有的代碼的基礎(chǔ)上增加或改變上門，而不是搭建新的東西。 與比你聰明的人一起工作 我印象中的很多前端開發(fā)者 (相比于全職工作來說) 都是自由職業(yè)者，有同類想法的后端開發(fā)者并沒有那么多?？赡苁且驗楹芏嗲岸硕际亲詫W(xué)成才的而后端則多是學(xué)校里學(xué)出來的。 不論是自我學(xué)習(xí)還是自我工作，我們都面對一個問題：你并沒有機會從比你聰明的家伙那里學(xué)到什么。沒有人幫你 review 代碼，也沒有人與你碰撞靈感。 我強烈建議，最起碼在你職業(yè)發(fā)展的前期，你要在一個團隊里工作，尤其是一個普遍比你聰明而且有經(jīng)驗的團隊里工作。 如果你最終會在你職業(yè)發(fā)展的某個階段選擇獨立工作，一定要讓自己投身在開源社區(qū)當中。保持對開源項目的活躍貢獻，這會給你團隊工作相同甚至更多的益處。 “造輪子” 造輪子在商業(yè)上是非常糟糕的，但是從學(xué)習(xí)的角度是非常好的。你可能很想把那些庫和小工具直接從 npm 里拿下來用，但也可以想象一下你獨立建造它們能夠?qū)W到多少東西。 我知道有些人讀到這里是特別不贊成的。別誤會，我并沒有說你不應(yīng)該使用第三方代碼。那些經(jīng)過充分測試的庫具有多年的測試用例積累和已知問題積累，使用它們絕對是非常明智的選擇。 但在這里我想說的是如何從優(yōu)秀到卓越。我覺得這個領(lǐng)域很多卓越的人都是我每天在用的非常流行的庫的作者或維護者。 你可能不曾打造過自己的 JavaScript 庫也擁有一個成功的職業(yè)發(fā)展，但是你從不把自己手弄臟是幾乎不可能淘到金子的。 在這一行大家普遍會問的一個問題是：我接下來應(yīng)該做點什么？如果你沒有試著學(xué)一個新的工具創(chuàng)建一個新的應(yīng)用，那不妨試著重新造一個你喜歡的 JavaScript 庫或 CSS 框架。這樣做的一個好消息是，在你遇到困難的時候，所有現(xiàn)成的庫的源代碼都會為你提供幫助。 把你學(xué)到的東西都記錄下來 |
|
|
