[譯]如何成爲一個優秀的前端工程師

來自Google的前端工程師-Philip Walton 分享了本身關於如何成爲優秀的工程師的一些觀點。我的感受頗有價值，因此翻譯成中文，方便你們閱讀。水平有限，如翻譯不妥之處請在評論中指出。

原文地址：http://philipwalton.com/articles/how-to-become-a-great-front-end-engineer/

---

最近，我收到了讀者的郵件，引起了個人一些思考。這是他在郵件中問個人問題：

Hi Philip, is it okay to ask how you become a great front-end engineer? Any advice?

我不得不認可，我感到很是的驚訝，竟然會被問到這樣的問題，由於我歷來沒有想過本身是一個優秀的前端工程師。實際上，我在這個行業工做的前幾年裏，我真的不以爲我可以勝任個人工做。我接受了這些工做只是由於我之前沒有意識到我知道得東西太少了，我可以獲得這些工做只是由於之前面試個人人不知道問我什麼問題。

話雖這麼說，我最後仍是把我本身的角色作得很是好，並且成爲了團隊裏有價值的一員。當我最後離職的時候（下一個職位我仍是沒法勝任）我一般也會應試那些將要應聘個人職位的人。如今回想那些我面試過的應聘者，讓我明白，看待知識的重要性。儘管我一開始在這個領域很薄弱。我如今的本身可能也不會僱傭之前的那個本身，儘管我知道隨着工做經驗的積累，成功也是可能的。

在Web領域，我工做的越久，越讓我意識到不錯的人和真正優秀的人的區別在於不是他們知道什麼，而是他們如何思考。 很明顯，知識是很重要的--特別是在某些狀況下--可是，在一個快速變化的領域並不是如此。你獲取知識的方式比你知道那些知識更爲重要。並且也許最重要的是：你如何利用你的知識去解決平常生活中的問題。

你能夠找到大量談論知識點、框架和工具的文章，這是知識都是得到一份工做所須要知道的。我想說一些不同的。在這篇文章中，我會說一說前端工程師應有的心態，但願可以回答最開始的問題：怎樣才能作到優秀？

不要只是解決問題，找到問題的根源所在

不少的人只是不斷地寫一些 CSS 和 Javascript 補丁直到他們發現這些東西能夠正常的工做了，而後他們就無論了。我在代碼審查的過程當中看到了不少這樣的作法。

我會常常問別人：「爲何你要在這裏加一個 float: left ？」 或者 「這個 overflow:hidden 真的須要嗎？」，而後他們會回答：「我不知道，可是若是我刪掉他們，就出問題了」。

Javascript 也同樣。我看到一些人用 setTimeout 來防止執行順序上的問題，或者是一些人濫用 stopPropagation() 而沒有考慮到它也許會影響頁面中的其餘事件處理函數。

我遇到過不少相同或相似的問題，若是你歷來不花時間去了解問題的根源所在，你會發現你會一遍一遍的遭遇一樣的困境。

花時間去深刻的研究你的解決方案爲何可行看起來須要耗費不少的精力，可是我發誓它會在未來給你節約不少時間。對你如今工做的系統有一個全面的理解能夠減小你未來的猜想和檢查工做。

學會預測瀏覽器領域未來的變化

前端跟後端主要的不一樣是：後端的運行環境在你的控制之下。可是對於前端而言，相比於後端，它徹底不在你的控制範圍。你的用戶所使用的平臺或者設備隨時都有可能改變，你的代碼須要可以優雅地處理這種狀況。

我記得早在2011年的時候，我在一個很是著名的 javascript 框架看到下面這樣一段源碼（大體如此）：

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

我知道在現實生活中， feature detaction 並不能100%的有效，有些時候咱們不得不採用這種很差的方式或者瀏覽器白名單的方式，可是任什麼時候候你這樣作的時候，你應該預測將來可能會發生什麼，即便發生，你的代碼也不該該出現bug。

對於咱們大多數人而言，咱們在如今的工做崗位上寫的代碼會比咱們的任期更長。我8年前寫的一些代碼如今還會常常用到，這想起來既讓人知足又讓讓感到可怕。

閱讀官方文檔

瀏覽器 bug 老是存在的，可是，當兩個瀏覽器執行相同的代碼表現卻不一致時，人們常常假設，而不是親自去檢查，只是把他們認爲的表現好的叫作「正常」瀏覽器，表現異常的叫「不正常」瀏覽器。但並不是老是這樣，當你作出了錯誤的假設時，任何你選擇的解決方法在將來也許會失效。

一個現實的例子就是 flex items 的默認最小尺寸。根據官方文檔， flex items 的 min-width 和 min-height 是 auto (而不是 0)，這意味着，它們的尺寸不會比它們的內容還要小。 可是在過去的8個月裏，只有 Firefox 是惟一一個正確的實現這一標準的瀏覽器。

若是你遇到過這類跨瀏覽器的兼容性問題，並且你注意到你的頁面在 Chrome，IE，Opera，和 Safari 上表現一致，惟獨 Firefox 上表現不一樣時，你確定會猜想這是 Firefox 本身的問題。

當兩個或多個瀏覽器在渲染相同的代碼表現不一致時， 你應該花一些時間去研究到底哪一個瀏覽器纔是正確的，而後用正確的方式寫下你的代碼。你的做品纔會是面向將來的。

另外，優秀的前端工程師常常都是站在變化的最前列的，他們會在這些技術成爲主流以前就採用這些技術，甚至爲這些技術做出貢獻。若是你憑藉你本身的實力去查找官方文檔，並且可以想象一個技術在你可以在瀏覽器中用它的以前將會是如何工做的，你將成爲可以談論這個官方標準會對開發形成什麼影響的人。

閱讀其餘人的代碼

閱讀其餘人的代碼，無疑是成爲一個更好的開發者的最好方式。

本身解決問題是學習的最好方式，可是若是這些問題都是你之前解決過的，你很快就會進入平穩期（很難有上升的空間）。閱讀其餘人的代碼能夠爲你打開處理問題的新的思路。並且閱讀和理解別人寫的代碼的能力也是在跟團隊合做或者參與開源項目時相當重要的能力。

實際上，我認爲在面試一個應聘者是隻讓他們寫代碼--新的代碼，是最大的錯誤。我應聘的時候，歷來沒有被叫過去閱讀一些已經存在的代碼，在這些代碼中找出問題，而後解決它。這是很是很差的，由於做爲一個工程師，不少時候咱們是在別人的代碼上添加和改變一些代碼。不多從頭寫一些新的。

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

在我印象你，比起後端開發者，更多的前端開發者但願成爲一個自由職業者（全棧）。也許是前端工程師更趨向於自學，然後端工程師更趨向於學術。

自學併爲你本身工做的問題是沒法從比你聰明的人身上獲得好處。沒有人來跟你討論觀點或者幫你審查代碼。

我強烈的建議，至少在你職業生涯初期，在一個團隊中工做，特別是跟一羣比你更聰明更有經驗的人工做。

若是你已經結束你的職業生涯，如今只是爲你本身工做，那麼參與到開源中來。 貢獻開源項目會給你不少與團隊合做的機會。

重複造輪子

在商業上，重複造輪子是很差的，可是對於學習來講並不是如此。你也許嘗試從 npm 上獲取預輸入控件或者事件委託庫，可是想象一下若是你本身嘗試創造這些東西的話會學到更多。

我肯定一些正在閱讀這篇文章的人對此感到強烈反對。不要誤會個人意思。我不是說你永遠也不該該使用第三方庫。使用優秀的庫是很是明智的事情。

可是，在這篇文章中，我要說的是如何從一個不錯的工程師成爲一個優秀的工程師。大部分我認爲的這個領域中優秀的工程師都是這些優秀的第三方庫的維護者。

你也許歷來沒有構建夠本身的 javascript 庫，可是你依然可以在你的職業生涯中得到成功，可是，可能你歷來沒有理解到解決問題的核心。

在這個行業中，人們常常問起的一個問題是：我接下來應該作什麼？ 若是你問了這個問題，爲何不去嘗試從新創造一個你喜歡的 javascript 庫或者 CSS 框架，而不是嘗試一些新的工具或者寫一個新的 app。 這樣作的好處是，及時你遇到了困難，你也能夠從目前已有的庫中的源碼找到答案。

把你學到的東西寫下來

最後， 你應該把你學到的東西寫下來。有太多的理由這樣作了，可是，也許最重要的緣由是這樣能夠強迫你更好地理解你所學的東西。若是你沒法解釋其原理，這是一個很好的機會說明你並無徹底搞懂它。不少時候你沒有意識到你不懂，直到你把它寫下來。

在個人經驗中，書寫、作一個演講、以及寫一些 demos 是強迫我本身徹底弄懂一個東西的最好方式，從裏到外。即便沒有一我的會看你寫的東西，可是作這件事的過程更有價值。

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