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

原文出處： Philip Walton   譯文出處：趙錦江（@勾三股四） 

譯註：本文翻譯自谷歌工程師 Philip Walton 的一篇博客。看過以後很是有感觸，不少觀點都是本身長期很是堅持和認同的，因此翻譯出來分享給更多的前端同窗！

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

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

　　不得不認可，被問這樣的問題，我很驚訝，由於我歷來不以爲本身是個很卓越的前端工程師。甚至我入行的頭幾年時並不認爲本身能夠作好這一行。我只肯定本身比本身想象中還才疏學淺，並且你們面試個人時候都不知道從何問起。
　　話雖這麼說，我到如今作得還算不錯，並且成爲了團隊中有價值的一員。但我最終離開 (去尋求新的挑戰——即我還不可以勝任的工做) 的時候，我常常會被要求招聘個人繼任者。如今回看這些面試，我不由感嘆當我剛開始的時候本身在這方面的知識是多麼的匱乏。我如今或許不會按照我本身的模型進行招聘，即使我我的的這種經歷也有可能成功。
　　我在 web 領域工做越長時間，我就越意識到區分人才和頂尖人才的並非他們的知識——而是他們思考問題的方式。很顯然，知識在不少狀況下是很是重要並且關鍵的——可是在一個快速發展的領域，你前進和獲取知識的方式 (至少在至關長的一段時間裏) 會比你已經掌握的知識顯得更加劇要。更重要的是：你是如何運用這些知識解決天天的問題的。

　　這裏有許許多多的文章談論你工做中須要的語言、框架、工具等等。我但願給一些不同的建議。在這篇文章裏，我想談一談一個前端工程師的心態，但願能夠幫助你們找到通往卓越的道路。

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

　　不少人埋頭寫 CSS 和 JavaScript 直到程序工做起來了，而後就去作別的事情了。我經過 code review 發現這種事常常發生。
　　我總會問你們：「爲何你會在這裏添加 float: left？」或者「這裏的 overflow: hidden 是必要的嗎？」，他們每每答道：「我也不知道，但是我一刪掉它們，頁面就亂套了。」
　　JavaScript 也是同樣，我總會在一個條件競爭的地方看到一個 setTimeout，或者有些人無心中阻止了事件傳播，殊不知道它會影響到頁面中其它的事件處理。
　　我發現不少狀況下，當你遇到問題的時候，你只是解決當下的問題罷了。可是若是你永遠不花時間理解問題的本源，你將一次又一次的面對相同的問題。
　　花一些時間找出爲何，這看上去費時費力，可是我保證它會節省你將來的時間。在徹底理解整個系統以後，你就不須要總去猜想和論證了。

 

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

　　先後端開發的一個主要區別在於後端代碼一般都運行在徹底由你掌控的環境下。前端相對來講不那麼在你的掌控之中。不一樣用戶的平臺或設備是前端永恆的話題，你的代碼須要優雅掌控這一切。
　　我記得本身 2011 年以前曾經閱讀某主流 JavaScript 框架的時候看到過下面這樣的代碼 (簡化過的)：

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

　　在這個例子中變量 IE6 爲了判斷 IE 瀏覽器版本是不是 6 或更低的版本。那麼在 IE10 發佈時，咱們的程序判斷仍是會出問題。
　　我理解在真實世界特性檢測並不 100% 工做，並且有的時候你不得不依賴有 bug 的特性或根據瀏覽器特性檢測的錯誤設計白名單。但你爲此作的每一件事都很是關鍵，由於你預見到了再也不有 bug 的將來。
　　對於咱們當中的不少人來講，咱們今天寫的代碼都會比咱們的工做週期要長。有些我寫的代碼已通過去 8 年多了還在產品線上運行。這讓人很知足又很不安。

閱讀規範文檔

　　瀏覽器有 bug 是很不免的事，可是當同一份代碼在兩個瀏覽器渲染出來的效果不同，人們總會不假思索的推測，那個「廣受好評」的瀏覽器是對的，而「不起眼」的瀏覽器是錯的。但事實並不必定如此，當你的假設出現錯誤時，你選取的變通辦法都會在將來遭遇問題。
　　一個就近的例子是 flex 元素的默認最小尺寸問題。根據規範的描述，flex 元素初始化的 min-width 和 min-height 的值是 auto (而不是 0)，也就是說它們默認應該收縮到本身內容的最小尺寸。可是在過去長達 8 個月的時間裏，只有 Firefox 的實現是準確的。
　　若是你遇到了這個瀏覽器兼容性的問題而且發現 Chrome、IE、Opera、Safari 的效果相同而 Firefox 和它們不一樣時，你極可能會認爲是 Firefox 搞錯了。事實上這種狀況我見多了。不少我在本身 Flexbugs 項目上報的問題都是這樣的。並且這些解決方案的問題會在兩週以後 Chrome 44 修復以後被體現出來。和遵循標準的解決方案相比，這些方案都傷害到了正確的規範行爲。
　　當同一份代碼在兩個或更多瀏覽器的渲染結果不一樣時，你應該花些時間肯定哪一個效果是正確的，而且以此爲標準寫代碼。你的解決方案應該是對將來友好的。
　　額外的，所謂「卓越」的前端工程師是時刻感覺變化，在某項技術成爲主流以前就去適應它的，甚至在爲這樣的技術作着貢獻。若是你鍛鍊本身看到規範就能在瀏覽器支持它以前想象出它如何工做的，那麼你將成爲談論並影響其規範開發的那羣人。

 

閱讀別人的代碼

　　出於樂趣閱讀別人的代碼可能並非你每週六晚上會想到的娛樂項目，可是這毫無疑問是你成爲優秀工程師的最佳途徑。
　　本身獨立解決問題絕對是個不錯的方式，可是這不該該是你惟一的方式，由於它很快就會讓你穩定在某個層次。閱讀別人的代碼會讓你開闊思惟，而且閱讀和理解別人寫的代碼也是團隊協做或開源貢獻必須具有的能力。
　　我着實認爲不少公司在招聘新員工的時候犯的最大錯誤是他們只評估應聘者從輪廓開始寫新代碼的能力。我幾乎沒有見過一場面試會要求應聘者閱讀現有的代碼，找出其中的問題，並修復它們。缺乏這樣的面試流程真的很是很差，由於你做爲工程師的不少時間都花費在了在現有的代碼的基礎上增長或改變上門，而不是搭建新的東西。

與比你聰明的人一塊兒工做

　　我印象中的不少前端開發者 (相比於全職工做來講) 都是自由職業者，有同類想法的後端開發者並無那麼多。多是由於不少前端都是自學成才的然後端則可能是學校裏學出來的。
　　不管是自我學習仍是自我工做，咱們都面對一個問題：你並無機會從比你聰明的傢伙那裏學到什麼。沒有人幫你 review 代碼，也沒有人與你碰撞靈感。
　　我強烈建議，最起碼在你職業發展的前期，你要在一個團隊裏工做，尤爲是一個廣泛比你聰明並且有經驗的團隊裏工做。
　　若是你最終會在你職業發展的某個階段選擇獨立工做，必定要讓本身投身在開源社區當中。保持對開源項目的活躍貢獻，這會給你團隊工做相同甚至更多的益處。

 

「造輪子」

　　造輪子在商業上是很是糟糕的，可是從學習的角度是很是好的。你可能很想把那些庫和小工具直接從 npm 裏拿下來用，但也能夠想象一下你獨立建造它們可以學到多少東西。
　　我知道有些人讀到這裏是特別不同意的。別誤會，我並無說你不該該使用第三方代碼。那些通過充分測試的庫具備多年的測試用例積累和已知問題積累，使用它們絕對是很是明智的選擇。
　　但在這裏我想說的是如何從優秀到卓越。我以爲這個領域不少卓越的人都是我天天在用的很是流行的庫的做者或維護者。
　　你可能未曾打造過本身的 JavaScript 庫也擁有一個成功的職業發展，可是你從不把本身手弄髒是幾乎不可能淘到金子的。
　　在這一行你們廣泛會問的一個問題是：我接下來應該作點什麼？若是你沒有試着學一個新的工具建立一個新的應用，那不妨試着從新造一個你喜歡的 JavaScript 庫或 CSS 框架。這樣作的一個好消息是，在你遇到困難的時候，全部現成的庫的源代碼都會爲你提供幫助。

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

　　最後，但絲絕不遜色的是，你應該把你學到的東西記錄下來。這樣作有不少緣由，但也許最重要的緣由是它強迫你更好的理解這件事。若是你沒法講清楚它的工做原理，在整個過程當中它會推進你本身把並不真正理解的東西弄清楚。不少狀況下你根本意識不到本身還不理解它們——直到本身動手寫的時候。
　　根據個人經驗，寫做、演講、作 demo 是強迫本身徹底深刻理解一件事的最佳方式。就算你寫的東西沒有人看，整個過程也會讓你受益不淺。

 

Footnotes:

　　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.　　You can refer to Flexbug #1 for a future-friendly, cross-browser workaround to this issue.