我所理解的前端

入坑前端到今天也將近兩年半了,這兩天忽然想到了第一次面試時面試官的一個問題-------你怎樣理解前端的工做?

對於當時我一個小白而言徹底是胡說一通,詞不達意,搞得面試官一臉懵逼,如今想一想那可能就叫尬聊吧……時隔兩年在不斷爬坑中對這個問題有了本身新的認識,今天趁着上午沒什麼事情,寫下這篇博客,想到哪寫到哪,談一談我所理解的前端。

技術方面:

第一階段(新手村)

一個前端初學者必須所掌握的核心技能HTML,CSS,JavaScript,這三項是前端最底層的技術支持了,若是你看幾年前的回答應該還會有一項jquery,但我我的以爲現階段的前端圈jquery能夠不做爲必備技能,雖然Jquery對新人很友好,但如今mvvm框架滿天飛Vue, Angular,React三分天下,用起來要比直接操做dom的jquery舒服不少,固然在這個階段是打基礎的階段框架,類庫什麼的能夠日後靠。原生Js永遠都是重中之重,只會用框架不懂底層原理永遠達不到精通,推薦紅寶書Javascript高級程序設計,吃透紅寶書打牢基礎再去學習其餘框架,媽媽就不再用擔憂你的學習。接下來還有一項額外的技能PhotoShop,要知道ps能夠不用去作,但必需要會,並且在一些小公司裏UI只會丟給你一個PSD,沒有什麼Sketch之類的東西,也沒人幫你切圖,這些都須要你本身來處理,因此ps是額外的必備技能。

第二階段(副本開啓)

進入告訴成長階段,開始打怪升級,這個階段的時間持續最長,在這期間你須要爬無數的坑,積累各類失敗的經驗,一關一關的往下刷,關於HTML和CSS你須要知道各類UI框架的使用,如BootStrap,ElementUI……,關於不一樣圖片的格式標準,瀏覽器的兼容性,移動和pc端的區別,響應式佈局,flex佈局,柵格佈局,對設計審美的提高…等關於提升你頁面開發效率的各類技能,UI框架這一塊比較雜選本身感興趣的看看就好。

Js方面這時候已經能夠開始挑一種主流框架進行學習了,前面提到的Vue, Angular,React都是不錯的選擇, 而且對面向對象編程,對象封裝,原型繼承,閉包,同步異步差別,等一系列的js進階知識應該進行深刻了解,同時對es6標準也須要了解,能夠參考阮一峯老師的es6入門,書中包含了es6的各類新特性,默認參數,模版表達式,多行字符串,拆包表達式,改進的對象表達式,箭頭函數 =&>,Promise,塊級做用域的let和const,class類,模塊化等經常使用特性.能夠作到本身封裝組件,編寫維護性高,可讀性強的代碼. 並且在平時須要多看別人寫的代碼,汲取別人的優勢,而且閱讀大量的技術文獻,最重要的是要總結本身的問題,好比說你遇到一個bug,迷迷糊糊的就解決了,下一次你又遇到相同的問題,這個時候有沒有對以前問題進行總結的效果就看出來了.

第三階段及更高級

瞭解各類設計模式,看得懂各類框架源碼,先後端通吃,能夠本身手寫js框架...好吧,我還沒到這個階段就不寫了..............

在工做中

一個完整的的工做流程應該是:

立項--項目研討--需求確認----產品出原型----後臺開發同時設計師拿到原型進行UI設計--前端開始開發--測試提bug--改bug--重複n次--產品驗收

上面只是一套籠統的流程,至少在前端這方面咱們須要作的有梳理業務邏輯並理解業務邏輯,這對你後面的開發頗有用處,同時根據需求進行應用技術的選擇,項目結構的劃分,需求模塊的劃分,完整項目的搭建,固然如今有不少能夠自動化構建工具能夠節省你不少時間, 如今的前端開發已經再也不僅僅只是靜態網頁的開發了，突飛猛進的前端技術已經讓前端代碼的邏輯和交互效果愈來愈複雜，更加的不易於管理，模塊化開發和預處理框架把項目分紅若干個小模塊，增長了最後發佈的困難，沒有一個統一的標準，讓前端的項目結構千奇百怪。前端自動化構建在整個項目開發中愈來愈重要,但新手入門仍是應該去嘗試本身一點一點的去構建一個項目,等你多作幾個項目以爲每次都這樣重複好煩,天然而然的就入了自動化構建的坑,畢竟這樣能讓你更深入的理解,爲何要使用自動化構建……好比咱們主棧是vue,咱們最經常使用的就是vue-cli,自動化工具備不少選擇如Bower、Gulp、Grunt、node、yeoman,咱們應該根據需求選擇最適合本身的去研究。

溝通

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

溝通ui

前端是最接近用戶的人,用戶對一個網站,軟件最直觀的感覺是反映到前端的,可能你會說最直觀的不該該是UI設計師麼,你要知道我是前端我爲設計師代言!!!

和UI的溝通,在工做中咱們不該該是被動的實現UI的設計,而是應該合理化的提出本身的想法,否則往後返工浪費的是雙方的時間,好比最開始剛來公司的時候,項目裏對一些小圖標的圖片還在使用雪碧圖,但很明顯隨着瀏覽器的支持愈來愈好,svg和字體圖標慢慢佔據主流,我在阿里巴巴圖標庫建了一個項目把UI也拉了進來,UI把他用到的圖標直接添加進項目,前端直接從項目生成字體圖標引入到項目,絕逼要比本身慢慢切圖,扣圖標,合併雪碧圖要省事的多,並且用起來也特別爽,想改顏色就改顏色。再好比你須要作一個圖表,用到了echarts,你徹底可讓UI基於echarts去設計樣式,而不是讓他在那裏自由發揮,由於你永遠不知道設計師的腦子裏裝了多少創意,這樣節省的是兩我的的時間,不會出現他作好樣式而你實現不了的尷尬。

溝通產品

通常來講程序員和產品經理之間是最難溝通的,只有相殺沒有相愛,畢竟子曾經曰過:’這個需求很簡單,怎麼實現我無論,明天上線!’,

下面引用lensuntop的一篇文章,我以爲寫的很是好

記得有一個段子：

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

程序猿：請說。

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

程序猿已經在風中凌亂。。。

從這個段子中多少能折射出產品和技術之間的各類激情「火花」。產品經理眼中簡單的需求，而在咱們看來是不可能實現的。而程序員也沒法理解產品經理爲何要實現這樣的需求。那麼，站在一個程序員的角度應該怎麼樣和產品經理溝通呢？

1.深入理解需求，清楚需求的動機和原因

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

2.換位思考

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

 

3.不放過每個細節

做爲程序員想必對這句話都是深深認同的。由於一個標點符號或者類型的錯誤，會致使一個本身意想不到的bug。產品經理在設計一個產品的時候，都是從大方向去想問題的，大方向沒有錯就好了，細節脫離不了大方向。這是他們想的。可是對於程序來講，卻萬萬不能。由於一個細節的邏輯每每決定了整個大方向。舉個例子：有一個需求，用戶的做品須要提交審覈，通過審覈纔可讓全部人看到。當產品經理交這個需求給你的時候，你能察覺到什麼問題了嗎？這裏面有幾個細節：1.用戶提交審覈後，用戶能夠不能夠再編輯做品；2.做品是否會屢次審覈；3.需不須要記錄審覈歷史；4.用戶做品是否須要有版本的控制，如要產生版本，版本又是如何產生的；5.審覈經過後，用戶能夠不能夠再修改做品，若不能夠，那麼是否是其餘人就看不見用戶做品......話說回來這只是一個簡單的邏輯需求！可是涉及的細節倒是太多太多。咱們每每在編碼的時候寫不下去，就是由於給的需求太模糊，沒有細化到點上。

4.換一種方式說「不能實現」

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

5.當遇到不合理的需求時，積極尋求替換方案

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

6.必須遵循文檔精神

在開發的時候，咱們每每會另外與產品經理進行細節化的討論。可是這種討論結果，咱們並無記錄到產品原型裏面或者需求列表裏面。可是過了幾個月後，咱們本身每每會忘記咱們當初爲何會討論出這樣或者那樣的一個細節。因此一切的需求必須是根據的。從另外一方面來講，也保障了雙方的利益，別等到出問題的時候，不知道是誰的責任，而在這一方面，程序員每每很吃虧。

6.對本身的程序有一顆藝術的心

有人說過，當需求影響到代碼擴展性的時候，會首先砍需求，而不是改代碼！在必定程度上，我是認同這句話的。在我看來，程序是一件思想上的做品，要達到藝術的境界，從功能、體驗和邏輯上都必須是合情合理的。就像一件藝術品同樣，看起來是渾然天成的！由於一件看起來很「醜陋」做品，必定是不符合人的邏輯和習慣的。

寫到最後，感受繞回到程序員自身了。其實跟產品經理溝通，最重要的是要明白到：咱們是在解決問題，而不是在製造問題！主要抱着這個核心，一切問題迎刃而解

通常來講和後臺溝通沒那麼多的麻煩,約定好規則後,通常來講大家是經過api來溝通的,但當你調試接口時,出現一些未知的,你感受不是本身問題的時候,及時的溝通後臺是最明智的。

責任劃分

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

寫不動了,以上就是我的爬坑後對前端的一些理解(ps:雖然我還在坑裏),也算對本身工做的一個總結吧,寫的比較絮叨,不喜勿噴,最後祝你們2018升職加薪,找到女友!!!

個人博客即將搬運同步至騰訊雲+社區，邀請你們一同入駐：https://cloud.tencent.com/developer/support-plan