技術方面:
第一階段(新手村)
一個前端初學者必須所掌握的核心技能HTML,CSS,JavaScript,這三項是前端最底層的技術支持了,如果你看幾年前的回答應該還會有一項jquery,但我個人覺得現(xiàn)階段的前端圈jquery可以不作為必備技能,雖然Jquery對新人很友好,但現(xiàn)在mvvm框架滿天飛Vue, Angular,React三分天下,用起來要比直接操作dom的jquery舒服很多,當然在這個階段是打基礎的階段框架,類庫什么的可以往后靠。原生Js永遠都是重中之重,只會用框架不懂底層原理永遠達不到精通,推薦紅寶書Javascript高級程序設計,吃透紅寶書打牢基礎再去學習其他框架,媽媽就再也不用擔心你的學習撤奸。接下來還有一項額外的技能PhotoShop,要知道ps可以不用去做,但必須要會,而且在一些小公司里UI只會丟給你一個PSD,沒有什么Sketch之類的東西,也沒人幫你切圖,這些都需要你自己來處理,所以ps是額外的必備技能。
第二階段(副本開啟)
進入告訴成長階段,開始打怪升級,這個階段的時間持續(xù)最長,在這期間你需要爬無數(shù)的坑,積累各種失敗的經(jīng)驗,一關一關的往下刷,關于HTML和CSS你需要知道各種UI框架的使用,如BootStrap,ElementUI……,關于不同圖片的格式標準,瀏覽器的兼容性,移動和pc端的區(qū)別,響應式布局,flex布局,柵格布局,對設計審美的提升…等關于提高你頁面開發(fā)效率的各種技能,UI框架這一塊比較雜選自己感興趣的看看就好袜茧。
Js方面這時候已經(jīng)可以開始挑一種主流框架進行學習了,前面提到的Vue, Angular,React都是不錯的選擇, 并且對面向?qū)ο缶幊?對象封裝,原型繼承,閉包,同步異步差異,等一系列的js進階知識應該進行深入了解,同時對es6標準也需要了解,可以參考阮一峰老師的es6入門,書中包含了es6的各種新特性,默認參數(shù),模版表達式,多行字符串,拆包表達式,改進的對象表達式,箭頭函數(shù) =&>,Promise,塊級作用域的let和const,class類,模塊化等常用特性.可以做到自己封裝組件,編寫維護性高,可讀性強的代碼. 而且在平時需要多看別人寫的代碼,汲取別人的優(yōu)點,并且閱讀大量的技術文獻,最重要的是要總結自己的問題,比如說你遇到一個bug,迷迷糊糊的就解決了,下一次你又遇到相同的問題,這個時候有沒有對之前問題進行總結的效果就看出來了.
第三階段及更高級
了解各種設計模式,看得懂各種框架源碼,前后端通吃,可以自己手寫js框架...好吧,我還沒到這個階段就不寫了..............
在工作中
一個完整的的工作流程應該是:
立項--項目研討--需求確認----產(chǎn)品出原型----后臺開發(fā)同時設計師拿到原型進行UI設計--前端開始開發(fā)--測試提bug--改bug--重復n次--產(chǎn)品驗收
上面只是一套籠統(tǒng)的流程,至少在前端這方面我們需要做的有梳理業(yè)務邏輯并理解業(yè)務邏輯,這對你后面的開發(fā)很有用處,同時根據(jù)需求進行應用技術的選擇,項目結構的劃分,需求模塊的劃分,完整項目的搭建,當然現(xiàn)在有很多可以自動化構建工具可以節(jié)省你很多時間, 現(xiàn)在的前端開發(fā)已經(jīng)不再僅僅只是靜態(tài)網(wǎng)頁的開發(fā)了城菊，日新月異的前端技術已經(jīng)讓前端代碼的邏輯和交互效果越來越復雜苛谷，更加的不易于管理赊锚，模塊化開發(fā)和預處理框架把項目分成若干個小模塊盗忱，增加了最后發(fā)布的困難酱床，沒有一個統(tǒng)一的標準，讓前端的項目結構千奇百怪趟佃。前端自動化構建在整個項目開發(fā)中越來越重要,但新手入門還是應該去嘗試自己一點一點的去構建一個項目,等你多做幾個項目覺得每次都這樣重復好煩,自然而然的就入了自動化構建的坑,畢竟這樣能讓你更深刻的理解,為什么要使用自動化構建……比如我們主棧是vue,我們最常用的就是vue-cli,自動化工具有很多選擇如Bower扇谣、Gulp昧捷、Grunt、node罐寨、yeoman,我們應該根據(jù)需求選擇最適合自己的去研究靡挥。
溝通
前端是團隊里最應該學會溝通的人,界面有問題需要和UI溝通,數(shù)據(jù)有問題需要和后臺溝通,功能有問題需要和產(chǎn)品溝通,測試的時候給你提bug你還需要和測試溝通……emmm心累
溝通ui
前端是最接近用戶的人,用戶對一個網(wǎng)站,軟件最直觀的感受是反映到前端的,可能你會說最直觀的不應該是UI設計師么,你要知道我是前端我為設計師代言!!!
和UI的溝通,在工作中我們不應該是被動的實現(xiàn)UI的設計,而是應該合理化的提出自己的想法,不然日后返工浪費的是雙方的時間,比如最開始剛來公司的時候,項目里對一些小圖標的圖片還在使用雪碧圖,但很明顯隨著瀏覽器的支持越來越好,svg和字體圖標慢慢占據(jù)主流,我在阿里巴巴圖標庫建了一個項目把UI也拉了進來,UI把他用到的圖標直接添加進項目,前端直接從項目生成字體圖標引入到項目,絕逼要比自己慢慢切圖,扣圖標,合并雪碧圖要省事的多,而且用起來也特別爽,想改顏色就改顏色。再比如你需要做一個圖表,用到了echarts,你完全可以讓UI基于echarts去設計樣式,而不是讓他在那里自由發(fā)揮,因為你永遠不知道設計師的腦子里裝了多少創(chuàng)意,這樣節(jié)省的是兩個人的時間,不會出現(xiàn)他做好樣式而你實現(xiàn)不了的尷尬鸯绿。
溝通產(chǎn)品
一般來說程序員和產(chǎn)品經(jīng)理之間是最難溝通的,只有相殺沒有相愛,畢竟子曾經(jīng)曰過:’這個需求很簡單,怎么實現(xiàn)我不管,明天上線!’,
下面引用lensuntop的一篇文章,我覺得寫的非常好
記得有一個段子：
產(chǎn)品汪：程序猿跋破，我們來實現(xiàn)一個緊急需求？
程序猿：請說瓶蝴。
產(chǎn)品汪：請根據(jù)手機殼的顏色幔烛，來實現(xiàn)APP啟動的顏色。
程序猿已經(jīng)在風中凌亂囊蓝。令蛉。珠叔。
從這個段子中多少能折射出產(chǎn)品和技術之間的各種激情“火花”祷安。產(chǎn)品經(jīng)理眼中簡單的需求凉唐，而在我們看來是不可能實現(xiàn)的。而程序員也無法理解產(chǎn)品經(jīng)理為什么要實現(xiàn)這樣的需求簿训。那么强品，站在一個程序員的角度應該怎么樣和產(chǎn)品經(jīng)理溝通呢的榛？
1.****深刻理解需求表伦，清楚需求的動機和緣由
我們程序員一定會在問，產(chǎn)品經(jīng)理為什么想要根據(jù)手機殼的顏色來動態(tài)實現(xiàn)APP啟動時的顏色纲熏。既然想聽解析，那就先別急著說出自己的結論——技術上無法實現(xiàn)！既然有疑問苹丸，那就先將自己的疑問解決。
2.****換位思考
產(chǎn)品有產(chǎn)品的角度。作為程序員我們追求的是什么施流？邏輯正確嫂沉，更快趟章，更容易擴展蚓土。產(chǎn)品追求的是什么蜀漆？說實話绷耍，我自己沒有深刻去思考過這個問題褂始。站在一個慣性的角度思考可以想到：一個產(chǎn)品為什么存在，他的存在能解決什么問題，他的用戶體驗好不好。這些才是決定一個產(chǎn)品的核心價值。畢竟工作性質(zhì)影響了一個人的思維邏輯祷杈，所以這時候，我們能站在一個產(chǎn)品的角度去思考每一個需求但汞，便顯得尤其重要宿刮。
3.不放過每一個細節(jié)
作為程序員想必對這句話都是深深認同的。因為一個標點符號或者類型的錯誤私蕾，會導致一個自己意想不到的bug僵缺。產(chǎn)品經(jīng)理在設計一個產(chǎn)品的時候，都是從大方向去想問題的踩叭，大方向沒有錯就行了磕潮，細節(jié)脫離不了大方向。這是他們想的容贝。但是對于程序來說自脯，卻萬萬不能。因為一個細節(jié)的邏輯往往決定了整個大方向斤富。舉個例子：有一個需求膏潮，用戶的作品需要提交審核，經(jīng)過審核才可以讓所有人看到满力。當產(chǎn)品經(jīng)理交這個需求給你的時候焕参，你能察覺到什么問題了嗎轻纪？這里面有幾個細節(jié)：1.用戶提交審核后，用戶可以不可以再編輯作品叠纷；2.作品是否會多次審核刻帚；3.需不需要記錄審核歷史；4.用戶作品是否需要有版本的控制讲岁，如要產(chǎn)生版本我擂，版本又是如何產(chǎn)生的；5.審核通過后缓艳，用戶可以不可以再修改作品校摩，若不可以，那么是不是其他人就看不見用戶作品......話說回來這只是一個簡單的邏輯需求阶淘！但是涉及的細節(jié)卻是太多太多衙吩。我們往往在編碼的時候?qū)懖幌氯ィ褪且驗榻o的需求太模糊溪窒，沒有細化到點上坤塞。
4.換一種方式說“不能實現(xiàn)”
不能實現(xiàn)，這句話想必我們都是經(jīng)常說澈蚌。但是直接對產(chǎn)品經(jīng)理說摹芙，沒準會讓產(chǎn)品經(jīng)理抓狂。因為我們會讓他們覺得他們提出的任何需求宛瞄，我們都不能實現(xiàn)浮禾。但是事實并非如此，因為不能實現(xiàn)是有條件的份汗，比如時間不夠盈电。所以我們要先認同產(chǎn)品經(jīng)理的觀點（“能實現(xiàn)”），再提出自己實現(xiàn)他的需求的條件是什么杯活。因為現(xiàn)實產(chǎn)品經(jīng)理也不會經(jīng)常犯傻匆帚，經(jīng)常提出一些不合理的需求，但是面對需求旁钧，我們需要評估實現(xiàn)的時間吸重，而且這個時間不是那么容易評估準確的。
5.當遇到不合理的需求時歪今，積極尋求替換方案
就拿段子里面的需求來說晤锹，讓我們提供幾種APP皮膚給用戶進行選擇，肯定比原先的需求容易實現(xiàn)彤委，而且也更加符合人性化鞭铆。說另外一個故事，有家智能家居的公司，要實現(xiàn)廚房水龍頭车遂，根據(jù)人聲說水溫幾度封断，就可以達到幾度。換個角度想舶担，你會感覺出40度和45度水的溫差嗎坡疼？而且根據(jù)人聲判斷，這又涉及到聲音識別系統(tǒng)衣陶，你要兼容多少種語言柄瑰？其實我就覺得左右切換就挺智能的，完全沒有必要搞的那么復雜剪况。所以程序員要找到一種更好更容易實現(xiàn)的方法教沾。別給產(chǎn)品經(jīng)理的想當然自亂陣腳。
6.必須遵循文檔精神
在開發(fā)的時候译断，我們往往會另外與產(chǎn)品經(jīng)理進行細節(jié)化的討論授翻。但是這種討論結果，我們并沒有記錄到產(chǎn)品原型里面或者需求列表里面孙咪。但是過了幾個月后堪唐，我們自己往往會忘記我們當初為什么會討論出這樣或者那樣的一個細節(jié)。所以一切的需求必須是根據(jù)的翎蹈。從另一方面來說淮菠，也保障了雙方的利益，別等到出問題的時候荤堪，不知道是誰的責任合陵，而在這一方面，程序員往往很吃虧逞力。
6.對自己的程序有一顆藝術的心
有人說過曙寡，當需求影響到代碼擴展性的時候糠爬，會首先砍需求寇荧，而不是改代碼！在一定程度上执隧，我是認同這句話的揩抡。在我看來，程序是一件思想上的作品镀琉，要達到藝術的境界峦嗤，從功能、體驗和邏輯上都必須是合情合理的屋摔。就像一件藝術品一樣烁设，看起來是渾然天成的！因為一件看起來很“丑陋”作品，一定是不符合人的邏輯和習慣的装黑。
寫到最后副瀑，感覺繞回到程序員自身了。其實跟產(chǎn)品經(jīng)理溝通恋谭，最重要的是要明白到：我們是在解決問題糠睡，而不是在制造問題！主要抱著這個核心疚颊，一切問題迎刃而解
一般來說和后臺溝通沒那么多的麻煩,約定好規(guī)則后,一般來說你們是通過api來溝通的,但當你調(diào)試接口時,出現(xiàn)一些未知的,你感覺不是自己問題的時候,及時的溝通后臺是最明智的狈孔。
責任劃分
相信大家在這一點上都深有感觸,因為前端是最后一關,所有的需求都是在前端手里變成一個具體的產(chǎn)品的,這樣也就導致你很容易變成背鍋俠,導致項目延期的情況有很多種,設計圖不及時,后臺數(shù)據(jù)出現(xiàn)問題,產(chǎn)品臨時改需求,如果你不能證明是這些問題導致項目延期,這個鍋你必背無疑,唯一的方法就是--à口頭確認--à發(fā)email到責任人確認--à通知上級,千萬不要覺得這個麻煩,出問題的時候會比這個更麻煩的,
