基層知識：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.稽核通過後，使用者可以不可以再修改作品，若不可以，那麼是不是其他人就看不見使用者作品......話說回來這只是一個簡單的邏輯需求！但是涉及的細節卻是太多太多。我們往往在編碼的時候寫不下去，就是因為給的需求太模糊，沒有細化到點上。
基層知識：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.稽核通過後，使用者可以不可以再修改作品，若不可以，那麼是不是其他人就看不見使用者作品......話說回來這只是一個簡單的邏輯需求！但是涉及的細節卻是太多太多。我們往往在編碼的時候寫不下去，就是因為給的需求太模糊，沒有細化到點上。