入坑前端到今天也將近兩年半了,這兩天突然想到了第一次面試時面試官的一個問題——-你怎樣理解前端的工作?
對於當時我一個小白而言完全是胡說一通,詞不達意,搞得面試官一臉懵逼,現在想想那可能就叫尬聊吧……時隔兩年在不斷爬坑中對這個問題有了自己新的認識,今天趁著上午沒什麼事情,寫下這篇部落格,想到哪寫到哪,談一談我所理解的前端。
技術方面:
第一階段(新手村)
一個前端初學者必須所掌握的核心技能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