如何快速成長爲一名合格的web前端工程師？

基層知識：HTML，CSS，javascript是基本；Vue.js，AngularJS，React爲主流；

原生永遠是最核心的技術；

《JavaScript高級程序設計》渡劫必備神器。

下面就是PS了，早期的前端多數由美工轉化而來，因此PS沒問題；

如今的前端基本都是專業領域培訓了，基本不懂PS；不少小公司不注重工做流程，把PSD一股腦甩給前端處理切圖和標註，浪費開發大量的時間；UI的進階有不少插件，好比Sketch什麼的。術業有專攻，那是他們的學習路程；

進階：ES6,ES7,響應式，兼容性，移動和PC端差別化，flex佈局，審美等海量項目的淬鍊；以及各類提升本身開發效率的技能。平時多看別人寫的代碼，汲取別人的優勢，提升代碼的可讀性和維護性；

要針對本身遇到的bug多總結，多思考；高階：掌握Node，koa框架，mysql數據庫等，拿下後端基本是每一個前端的終極目標；

不是說必定要作後端，而是理解了後端開發邏輯，數據庫設計原理之後，纔是真正打通了編程；

完整的工做流程：項目立項--立項評審--肯定需求--產品原型--設計定稿--前端開發--提測--修復bug--驗收--上線前端這方面咱們須要作的有梳理業務邏輯並理解業務邏輯,這對你後面的開發頗有用處,同時根據需求進行應用技術的選擇,項目結構的劃分,需求模塊的劃分,完整項目的搭建,固然如今有不少能夠自動化構建工具能夠節省你不少時間, 如今的前端開發已經再也不僅僅只是靜態網頁的開發了，突飛猛進的前端技術已經讓前端代碼的邏輯和交互效果愈來愈複雜，更加的不易於管理，模塊化開發和預處理框架把項目分紅若干個小模塊，增長了最後發佈的困難，沒有一個統一的標準，讓前端的項目結構千奇百怪。

前端自動化構建在整個項目開發中愈來愈重要,但新手入門仍是應該去嘗試本身一點一點的去構建一個項目,等你多作幾個項目以爲每次都這樣重複好煩,天然而然的就入了自動化構建的坑,畢竟這樣能讓你更深入的理解,爲何要使用自動化構建……好比咱們主棧是vue,咱們最經常使用的就是vue-cli,自動化工具備不少選擇如Bower、Gulp、Grunt、node、yeoman,咱們應該根據需求選擇最適合本身的去研究。

前端是團隊裏最應該學會溝通的人,界面有問題須要和UI溝通,數據有問題須要和後臺溝通,功能有問題須要和產品溝通,測試的時候給你提bug你還須要和測試溝通……（心塞吧）

前端是最接近用戶的人,用戶對一個網站,軟件最直觀的感覺是反映到前端；交互體驗更是前端項目的核心點；

和UI的溝通,在工做中咱們不該該是被動的實現UI的設計,而是應該合理化的提出本身的想法,否則往後返工浪費的是雙方的時間。好比通用組件的設計，每次出頁面都會有一套全新的toast提示，很明顯在大量開發任務的前提下，通用的統一的消息提示更能提升開發效率，而不影響頁面交互體驗；

前端應該跟UI溝通制定統一的通用組件，否則你會一直寫重複而且不能提升技術含金量的任務；

再好比你須要作一個圖表,用到了echarts,你徹底可讓UI基於echarts去設計樣式,而不是讓他在那裏自由發揮,由於你永遠不知道設計師的腦子裏裝了多少創意,這樣節省的是兩我的的時間,不會出現他作好樣式而你實現不了的尷尬。

若是大家的關係上升足夠好，你可讓他們給你預留出時間，去嘗試一下新的特效和體驗；能夠就用，不能夠就換設計方案；（前提是UI能配合你的創新）出色的產品經理會考慮的面面俱到，大家爭論的需求需求合理性而不會是邏輯缺失性的東西；通常來講程序員和產品經理之間是最難溝通的,只有相殺沒有相愛。

由於「這個需求比較簡單，怎麼實現你本身搞定，明天要求上線」

記得有一個段子：

產品汪：程序猿，咱們來實現一個緊急需求？

程序猿：請說。

產品汪：請根據手機殼的顏色，來實現APP啓動的顏色。

程序猿已經在風中凌亂。。。從這個段子中多少能折射出產品和技術之間的各類激情「火花」。

產品經理眼中簡單的需求，而在咱們看來是不可能實現的。而程序員也沒法理解產品經理爲何要實現這樣的需求。那麼，站在一個程序員的角度應該怎麼樣和產品經理溝通呢？

1.深入理解需求，清楚需求的動機和原因咱們程序員必定會在問，產品經理爲何想要根據手機殼的顏色來動態實現APP啓動時的顏色。既然想聽解析，那就先別急着說出本身的結論——技術上沒法實現！既然有疑問，那就先將本身的疑問解決。

2.換位思考產品有產品的角度。做爲程序員咱們追求的是什麼？邏輯正確，更快，更容易擴展。產品追求的是什麼？說實話，我本身沒有深入去思考過這個問題。站在一個慣性的角度思考能夠想到：一個產品爲何存在，他的存在能解決什麼問題，他的用戶體驗好很差。這些纔是決定一個產品的核心價值。畢竟工做性質影響了一我的的思惟邏輯，因此這時候，咱們能站在一個產品的角度去思考每個需求，便顯得尤爲重要。

3.不放過每個細節做爲程序員想必對這句話都是深深認同的。由於一個標點符號或者類型的錯誤，會致使一個本身意想不到的bug。

產品經理在設計一個產品的時候，都是從大方向去想問題的，大方向沒有錯就好了，細節脫離不了大方向。這是他們想的。可是對於程序來講，卻萬萬不能。由於一個細節的邏輯每每決定了整個大方向。舉個例子：有一個需求，用戶的做品須要提交審覈，通過審覈纔可讓全部人看到。當產品經理交這個需求給你的時候，你能察覺到什麼問題了嗎？這裏面有幾個細節：

• 1.用戶提交審覈後，用戶能夠不能夠再編輯做品；
• 2.做品是否會屢次審覈；
• 3.需不須要記錄審覈歷史；
• 4.用戶做品是否須要有版本的控制，如要產生版本，版本又是如何產生的；
• 5.審覈經過後，用戶能夠不能夠再修改做品，若不能夠，那麼是否是其餘人就看不見用戶做品......話說回來這只是一個簡單的邏輯需求！可是涉及的細節倒是太多太多。咱們每每在編碼的時候寫不下去，就是由於給的需求太模糊，沒有細化到點上。

4.換一種方式說「不能實現」不能實現，這句話想必咱們都是常常說。可是直接對產品經理說，沒準會讓產品經理抓狂。由於咱們會讓他們以爲他們提出的任何需求，咱們都不能實現。可是事實並不是如此，由於不能實現是有條件的，好比時間不夠。因此咱們要先認同產品經理的觀點（「能實現」），再提出本身實現他的需求的條件是什麼。由於現實產品經理也不會常常犯傻，常常提出一些不合理的需求，可是面對需求，咱們須要評估實現的時間，並且這個時間不是那麼容易評估準確的。(你只要盡全力實現產品的需求，產品也會慎重對待你的難度)

5.當遇到不合理的需求時，積極尋求替換方案就拿段子裏面的需求來講，讓咱們提供幾種APP皮膚給用戶進行選擇，確定比原先的需求容易實現，並且也更加符合人性化。說另一個故事，有家智能家居的公司，要實現廚房水龍頭，根據人聲說水溫幾度，就能夠達到幾度。換個角度想，你會感受出40度和45度水的溫差嗎？並且根據人聲判斷，這又涉及到聲音識別系統，你要兼容多少種語言？其實我就以爲左右切換就挺智能的，徹底沒有必要搞的那麼複雜。因此程序員要找到一種更好更容易實現的方法。別給產品經理的想固然自亂陣腳。咱們常說的：拒絕別人方案的時候給他一個更合適的解決方案；

6.必須遵循文檔精神在開發的時候，咱們每每會另外與產品經理進行細節化的討論。可是這種討論結果，咱們並無記錄到產品原型裏面或者需求列表裏面。可是過了幾個月後，咱們本身每每會忘記咱們當初爲何會討論出這樣或者那樣的一個細節。因此一切的需求必須是根據的。從另外一方面來講，也保障了雙方的利益，別等到出問題的時候，不知道是誰的責任，而在這一方面，程序員每每很吃虧。7.對本身的程序有一顆藝術的心有人說過，當需求影響到代碼擴展性的時候，會首先砍需求，而不是改代碼！在必定程度上，我是認同這句話的。在我看來，程序是一件思想上的做品，要達到藝術的境界，從功能、體驗和邏輯上都必須是合情合理的。就像一件藝術品同樣，看起來是渾然天成的！由於一件看起來很「醜陋」做品，必定是不符合人的邏輯和習慣的。寫到最後，感受繞回到程序員自身了。其實跟產品經理溝通，最重要的是要明白到：咱們是在解決問題，而不是在製造問題！主要抱着這個核心，一切問題迎刃而解通常來講和後臺溝通沒那麼多的麻煩,約定好規則後,通常來講大家是經過api來溝通的,但當你調試接口時,出現一些未知的,你感受不是本身問題的時候,及時的溝通後臺是最明智的。

責任劃分相信你們在這一點上都深有感觸,由於前端是最後一關,全部的需求都是在前端手裏變成一個具體的產品的,這樣也就致使你很容易變成背鍋俠,致使項目延期的狀況有不少種,設計圖不及時,後臺數據出現問題,產品臨時改需求,若是你不能證實是這些問題致使項目延期,這個鍋你必背無疑,惟一的方法就是--口頭確認--釘釘通知到責任人確認--通知上級,千萬不要以爲這個麻煩,出問題的時候會比這個更麻煩的。

合格的web前端工程師尚且須要好多修煉，入門級的web前端工程師也是不容易達到的。想要成爲一名web前端工程師，從知海匠庫http://www.zhihaijiangku.com的web前端課程開始。課程結合項目實戰，還有就業指導，幫助新手快速入門並就業。