如何成為一名卓越的前端工程師

本文摘自同行說使用者“凌風”分享的文章，原文連結：http://jiongks.name/blog/how-to-become-a-great-front-end-engineer/，如涉及版權問題請及時聯絡小編！

譯註：本文翻譯自谷歌工程師 Philip Walton 的一篇部落格。看過之後非常有感觸，很多觀點都是自己長期非常堅持和認同的，所以翻譯出來分享給更多的前端同學！

最近我收到一封讀者來信讓我陷入了思考，信是這麼寫的：

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

不得不承認，被問這樣的問題，我很驚訝，因為我從來不覺得自己是個很卓越的前端工程師。甚至我入行的頭幾年時並不認為自己可以做好這一行。我只確定自己比自己想象中還才疏學淺，而且大家面試我的時候都不知道從何問起

話雖這麼說，我到現在做得還算不錯，而且成為了團隊中有價值的一員。但我最終離開 (去尋求新的挑戰——即我還不能夠勝任的工作) 的時候，我經常會被要求招聘我的繼任者。現在回看這些面試，我不禁感嘆當我剛開始的時候自己在這方面的知識是多麼的匱乏。我現在或許不會按照我自己的模型進行招聘，即便我個人的這種經歷也有可能成功。

我在 web 領域工作越長時間，我就越意識到區分人才和頂尖人才的並不是他們的知識——而是他們思考問題的方式。很顯然，知識在很多情況下是非常重要而且關鍵的——但是在一個快速發展的領域，你前進和獲取知識的方式 (至少在相當長的一段時間裡) 會比你已經掌握的知識顯得更加重要。更重要的是：你是如何運用這些知識解決每天的問題的。

這裡有許許多多的文章談論你工作中需要的語言、框架、工具等等。我希望給一些不一樣的建議。在這篇文章裡，我想談一談一個前端工程師的心態，希望可以幫助大家找到通往卓越的道路。

別光解決問題，想想究竟發生了什麼

很多人埋頭寫 CSS 和 JavaScript 直到程式工作起來了，然後就去做別的事情了。我通過 code review 發現這種事經常發生。

我總會問大家：“為什麼你會在這裡新增float: left？”或者“這裡的overflow: hidden是必要的嗎？”，他們往往答道：“我也不知道，可是我一刪掉它們，頁面就亂套了。”

JavaScript 也是一樣，我總會在一個條件競爭的地方看到一個setTimeout，或者有些人無意中阻止了事件傳播，卻不知道它會影響到頁面中其它的事件處理。

我發現很多情況下，當你遇到問題的時候，你只是解決當下的問題罷了。但是如果你永遠不花時間理解問題的本源，你將一次又一次的面對相同的問題。

花一些時間找出為什麼，這看上去費時費力，但是我保證它會節省你未來的時間。在完全理解整個系統之後，你就不需要總去猜測和論證了。

學會預見未來的瀏覽器發展趨勢

前後端開發的一個主要區別在於後端程式碼通常都執行在完全由你掌控的環境下。前端相對來說不那麼在你的掌控之中。不同使用者的平臺或裝置是前端永恆的話題，你的程式碼需要優雅掌控這一切。

我記得自己 2011 年之前曾經閱讀某主流 JavaScript 框架的時候看到過下面這樣的程式碼 (簡化過的)：

JavaScript：

1 varisIE6=!isIE7&&!isIE8&&!isIE9;

在這個例子中變數 IE6 為了判斷 IE 瀏覽器版本是否是 6 或更低的版本。那麼在 IE10 釋出時，我們的程式判斷還是會出問題。

我理解在真實世界特性檢測並不 100% 工作，而且有的時候你不得不依賴有 bug 的特性或根據瀏覽器特性檢測的錯誤設計白名單。但你為此做的每一件事都非常關鍵，因為你預見到了不再有 bug 的未來。

對於我們當中的很多人來說，我們今天寫的程式碼都會比我們的工作週期要長。有些我寫的程式碼已經過去 8 年多了還在產品線上執行。這讓人很滿足又很不安。

閱讀規範文件

瀏覽器有 bug 是很難免的事，但是當同一份程式碼在兩個瀏覽器渲染出來的效果不一樣，人們總會不假思索的推測，那個“廣受好評”的瀏覽器是對的，而“不起眼”的瀏覽器是錯的。但事實並不一定如此，當你的假設出現錯誤時，你選取的變通辦法都會在未來遭遇問題。

一個就近的例子是 flex 元素的預設最小尺寸問題。根據規範的描述，flex 元素初始化的min-width和min-height的值是auto(而不是 0)，也就是說它們預設應該收縮到自己內容的最小尺寸。但是在過去長達 8 個月的時間裡，只有 Firefox 的實現是準確的。1

如果你遇到了這個瀏覽器相容性的問題並且發現 Chrome、IE、Opera、Safari 的效果相同而 Firefox 和它們不同時，你很可能會認為是 Firefox 搞錯了。事實上這種情況我見多了。很多我在自己Flexbugs專案上報的問題都是這樣的。而且這些解決方案的問題會在兩週之後 Chrome 44 修復之後被體現出來。和遵循標準的解決方案相比，這些方案都傷害到了正確的規範行為。[2]

當同一份程式碼在兩個或更多瀏覽器的渲染結果不同時，你應該花些時間確定哪個效果是正確的，並且以此為標準寫程式碼。你的解決方案應該是對未來友好的。

額外的，所謂“卓越”的前端工程師是時刻感受變化，在某項技術成為主流之前就去適應它的，甚至在為這樣的技術做著貢獻。如果你鍛鍊自己看到規範就能在瀏覽器支援它之前想象出它如何工作的，那麼你將成為談論並影響其規範開發的那群人。

閱讀別人的程式碼

出於樂趣閱讀別人的程式碼可能並不是你每週六晚上會想到的娛樂專案，但是這毫無疑問是你成為優秀工程師的最佳途徑。

自己獨立解決問題絕對是個不錯的方式，但是這不應該是你唯一的方式，因為它很快就會讓你穩定在某個層次。閱讀別人的程式碼會讓你開闊思維，並且閱讀和理解別人寫的程式碼也是團隊協作或開源貢獻必須具備的能力。

我著實認為很多公司在招聘新員工的時候犯的最大錯誤是他們只評估應聘者從輪廓開始寫新程式碼的能力。我幾乎沒有見過一場面試會要求應聘者閱讀現有的程式碼，找出其中的問題，並修復它們。缺少這樣的面試流程真的非常不好，因為你作為工程師的很多時間都花費在了在現有的程式碼的基礎上增加或改變上門，而不是搭建新的東西。

與比你聰明的人一起工作

我印象中的很多前端開發者 (相比於全職工作來說) 都是自由職業者，有同類想法的後端開發者並沒有那麼多。可能是因為很多前端都是自學成才的而後端則多是學校裡學出來的。

不論是自我學習還是自我工作，我們都面對一個問題：你並沒有機會從比你聰明的傢伙那裡學到什麼。沒有人幫你 review 程式碼，也沒有人與你碰撞靈感。

我強烈建議，最起碼在你職業發展的前期，你要在一個團隊裡工作，尤其是一個普遍比你聰明而且有經驗的團隊裡工作。

如果你最終會在你職業發展的某個階段選擇獨立工作，一定要讓自己投身在開源社群當中。保持對開源專案的活躍貢獻，這會給你團隊工作相同甚至更多的益處。

“造輪子”

造輪子在商業上是非常糟糕的，但是從學習的角度是非常好的。你可能很想把那些庫和小工具直接從 npm 裡拿下來用，但也可以想象一下你獨立建造它們能夠學到多少東西。

我知道有些人讀到這裡是特別不贊成的。別誤會，我並沒有說你不應該使用第三方程式碼。那些經過充分測試的庫具有多年的測試用例積累和已知問題積累，使用它們絕對是非常明智的選擇。

但在這裡我想說的是如何從優秀到卓越。我覺得這個領域很多卓越的人都是我每天在用的非常流行的庫的作者或維護者。

你可能不曾打造過自己的 JavaScript 庫也擁有一個成功的職業發展，但是你從不把自己手弄髒是幾乎不可能淘到金子的。

在這一行大家普遍會問的一個問題是：我接下來應該做點什麼？如果你沒有試著學一個新的工具建立一個新的應用，那不妨試著重新造一個你喜歡的 JavaScript 庫或 CSS 框架。這樣做的一個好訊息是，在你遇到困難的時候，所有現成的庫的原始碼都會為你提供幫助。

把你學到的東西都記錄下來

最後，但絲毫不遜色的是，你應該把你學到的東西記錄下來。這樣做有很多原因，但也許最重要的原因是它強迫你更好的理解這件事。如果你無法講清楚它的工作原理，在整個過程中它會推動你自己把並不真正理解的東西弄清楚。很多情況下你根本意識不到自己還不理解它們——直到自己動手寫的時候。

根據我的經驗，寫作、演講、做 demo 是強迫自己完全深入理解一件事的最佳方式。就算你寫的東西沒有人看，整個過程也會讓你受益匪淺。

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.

團隊開發了一款工程師、產品經理必備神器【同行說】APP，找大牛、看最新最熱乾貨，勾搭妹紙，快來同行說吧！