365:前端過去10年與未來10年

发布时间2020-03-31    点击数: 117   作者:365体育平台首页

第三款是做海報的(因為海報圖比較大、比較長,切割起來比較耗費內存,這塊軟件速度比較快)和Gif動畫的,但我用的少,大部分時間都用PhotoshopCS4來搞定。雖說這三款軟件最火,但真正讓我入坑前端(那個時候還沒有“前端”這個稱呼,有的就是“切圖仔”)的理由,是因為我想當一位網頁設計師。

軟件工程搞Java、C++、C真是挺枯燥無聊的,寫一段程序,還得編譯、部署,等上個兩三分鐘的,特別無語;而當初接觸Web頁面開發時(當時還是一位外教授課),發現網頁這東西很神奇,在一個Text文本編輯器里敲上幾行代碼,改個擴展名,雙擊頁面就展示出來了,這種所見即所得的美的視覺沖擊力,當時讓我向這個方向上蠢蠢欲動,埋下了禍根

在教育網慶幸地就是可以翻墻看了不少國外的網站,當時最大的感受就是美觀、大氣、留白充足,而國內的網頁哪里是網頁,UI的設計簡直齪的不要不要的,沒什么美感,全是一堆文字和框,外加一堆閃來閃去的gif(比如那個“New”)堆砌,尤其是教育網的官網,那丑的簡直不要不要的了。再加上當時的QQ空間很火,這塊DIY自己的空間,但還是感覺不大氣,所以當時就想著自己做出一款比較高端大氣上檔次的網頁

大學期間,雖然自己學設計做網頁這個想法被身邊同學嘲笑說這應該是專科同學才去搞的東西,但的確還是堅持下來了。平時自己除了讀專業課程和完成課程實踐以外,就是在寢室、在圖書館、在選修課、實驗室里抱著一堆影樓的P圖視頻寶典和一本影印版的厚厚的設計資料度過的。當時自學了Photoshop,也學會了設計中的三原色原理,并應用在班級日常校園種海報設計、照片美化等工作上,如今拿著單反拍個照P個圖的本領也都那個時候積累下來的。

再然后就是在校園里找了個實驗室的項目,跟一伙人做一個外賣網站,自己擔任網頁的開發部分。老實說那個時候對方都不信任我能搞定網頁開發,畢竟我還是初級的小白。所以自己那個時候啃W3C,在網上邊學邊做,雖然當時有個不錯的jQuery的框架,但自己還是純手工用HTML4、CSS、Javascript擼出了級聯地域菜單選擇器,而且UI也是自己設計的,頓時信心感爆棚,所以一發不可收拾的一個項目一個項目地走向了網頁開發或者叫切圖仔這個行業。這大概就是我與前端埋下的不解之緣吧,算是一腳踏入了前端這個行業。

而要說真正接觸“前端”這2個字的時候,那還是在面試淘寶時面試官向我提起的。雖然當時還是聽不懂前端到底是干嘛的,但一聽面試官說能跟設計師一起工作,而且未來想做設計師也可以內轉,我就沒有再半點猶豫,當時一天就搞定了所有面試流程,簽下了淘寶前端開發工程師的Offer,從此就兩腳都踏入了前端這個行業了

當你真正從校園出來,沉浸于工作之后,就會發現時間過得速度遠比你在學校里快了不止一倍,每時每刻都覺得時間不夠用、業務完全做不完,感覺自己的時間都給了工作,我過去也在反思這個原因到底是什么,后來也漸漸想明白,這種快本身與互聯網的發展相輔相成的,從2G到3G,再到4G,以及接下來的5G、6G……,正因為互聯網大潮的發展,以及我們這些推潮者的存在,我們的時間變快也就變得正常了。我知道很多人不理解,但在這個圈子里的人都會理解或有同樣的聲音存在。就比如以前端發展的這10年為例,你就會深有體會了。

以下就是詳細介紹前端發展的這黃金10年,有興趣的讀者可以細讀,沒有興趣的可以通過這點概述繞過:前端在最初,僅僅是為了完成一張網頁的開發,到后來,要能在同時完成5張、10張甚至更多張頁面的開發,對前端的挑戰變大,所以前端作業內容從單純的網頁開發,拆分成模塊式開發,拆分到前后端分離,過渡到可視化搭建系統等等,職能范圍也從網頁開發逐漸過渡到后端開發、全棧開發,領域范圍也從網頁開發細分到PC端開發、移動端開發、游戲/互動開發、Nodejs開發、架構工程開發等,工程內容也從一段jQuery代碼就搞定的階段發展到前端也需要構建、打包、集成、測試、灰度等高度工程體系化的復雜程度。但生產力還以人肉為主,互聯網前端行業還是勞動密集型作業方式。

2010年的前端,IE6還盛行,jQuery是老大,YUI雖然也不差,但用的人畢竟沒有jQuery多。有個比較牛逼的工具叫Firebug,這算是給前端的最大福利。這個時候的前端,在我看來應該還算刀耕火種階段,雖然有Dreamweaver這樣的網頁可視化編輯工具,但產生的無用代碼量真是挺多了,而且對接數據比較麻煩,維護成本也不低,在當時的網絡條件下,用它的人可能也不少,但我一直不用它。

2011年,來到阿里實習之后,發現天貓(當時還叫淘寶商城)的頁面的確很高端、大氣,而且也的確跟設計師在一起工作(當時還叫UED),很興奮。當時的前端規模不大(算上外包,15~20人左右),YUI在公司還比較盛行,KISSY開始展露頭角,看到前人大牛寫的代碼有條有理、的確非常膜拜,所以基本那半年的實習生活里大部分周末都泡在公司里或者加班或者自己學習前人的東西。與此同時,公司內還有一款非常牛逼的產品叫TMS,可以通過模塊化以及模板化的思想,分分鐘就可以搭出一張頁面來,簡直牛逼的不要不要的,那個時候淘寶商城的雙11(雖然很多人當時還把雙11當光棍節)活動頁面就是用這塊大殺器搭建完成的。用模塊化搭建的思路來解決頁面批量生產的問題,這個思路在當時業界也算領先,而且這個思路一直延續到今天。所以如果阿里有個產品歷史博物館的話,TMS絕對位列其中。

在2011~2014年之間的歷史階段里,模塊化的思路占為主導。當時為了進行Assets資源加載器的設計,就制定了模塊化的協議規范。當時比較流行的模塊化協議就是AMD(RequireJS)、CMD(Seajs為代表)、KMD(Kissy為代表)。在淘寶、天貓,Kissy應用的很火,YUI退出歷史舞臺,所以KMD主導天下;在支付寶及外部社區,Seajs應用的很火,所以CMD主導天下,玉伯大大的名氣和威望也在前端圈里特別高;而AMD在國外比較流行,但漸漸也被后來出現的CommonJS規范削弱了氣勢。

當時的前端借助模塊化的思想和各路框架(YUI、jQuery、Kissy、……),來支撐著網頁頁面的生產,前端Assets資源已經不再跟服務端代碼捆綁在一起發布了,但doc頁面還在服務端的web容器內,前后端的生產需要聯調、需要注意發布順序。TMS雖然好用,但還是在營銷活動(比如618、雙11)上優勢比較強,數據還是偏向靜態化的居多,在如頻道、搜索、交易等這種產品態的復雜主鏈路上還起不到快速生產的作用。不過慶幸的是,那個時候的營銷活動并沒有那么密集,一年之內活動屈指可數,所以對前端的生產壓力還沒有那么明顯。但痛苦在框架升級上,每年一次的Kissy升級,讓所有業務的前端痛心疾首。

伴隨著瀏覽器大戰,瀏覽器內核技術在向前發展(有興趣地同學可以在網上自助看看瀏覽器的內核發展史,IE逐漸跟不上Firefox、Safari和Chrome的節奏。后起之秀Chrome非常關注JavaScript的引擎性能,覺得可以再提升10倍,所以自研一款高性能JavaScript引擎,名叫V8,以BSD許可證開源,Chrome在瀏覽器家族內的地位如日中天。給前端配套的debug工具鏈更加完善,通過控制臺可以完成代碼調試、性能檢測、資源檢測、網絡檢測、DOM結構檢測等等諸多工作,Chrome在前端的眼里簡直可以說是一款瀏覽器走天下,IDE什么的完全通通不用。

因為Chrome的加持,前端的研發效能有所提升,外加HTML5+CSS3誕生和瀏覽器對它的爭先支持,Web頁面的性能體驗也逐漸上了一個臺階,在網頁上可以做的技術嘗試也開始展露,如網頁特效/動畫、網頁游戲。

這個思想的提出當時是一位阿里的前端高P,這種思想的誕生目的就是為了解決前后端在Web容器上的過度耦合,導致前后端的研發效率相互制約,所以將這種耦合轉變成對數據的耦合,面向數據編程,將Web部分徹底交給前端,這樣前后端的研發效率會大有提升。

而這個思想的提出時機恰好是在NodeJS和NPM生態初步建立的階段,阿里借助NodeJS做前后端的分離嘗試,在后端諸多質疑聲中,干掉了PHP、廢棄了Java的Web容器,一路拿下了前端在Web容器上的主動權。前端在NodeJS生態上,也開始有express、koa、egg、begg這樣的Web應用框架開源,也開始有了借助NodeJS完成的工程腳手架套件(如webpack),同時也衍生了一個新的工種NodeJS開發工程師,基本阿里的所有Java中間件生態,在NodeJS生態上也有對應的一份了。

前后端分離,讓前端主導Web容器,帶來的直接益處就是前端可以從Client和Server兩端進行一體化的生產工程設計,讓前端的頁面加載性能達到極致化。當然,前端職能的拓寬,也給前端帶來了額外的工作負擔,所以如果沒有充分人力準備的部門,輕易不會嘗試負責WebServer端,畢竟運維需要成本。但慶幸的是,隨著docker容器化技術的發展和云基礎設施運維能力的發展,從IaaS發展到PaaS,再到SaaS,服務端的運維成本大幅度降低,所以前端運維WebServer的成本就降低很多。

當然,前后端分離并沒有對前端的研發效率上有太多的改觀,倒是在前端工程體系上更加完善和健全。以前的前端可以被叫頁面仔,但這個階段前端已經不再是了,因為前端的工程體系(如IDE、研發、構建、打包、集成、測試、灰度、生產服務等等)不比Java的差多少。

2013年,移動端興起,阿里AllinMobile,移動端瀏覽器的發展勢弱,趕不上App的用戶體驗,多年在PC時代沉淀下的技術產物發現在移動端弱網的環境下難以應對,MobileFirst技術戰略之下,很多基建又得從移動端開始重新設計。

比如:kissy在移動端的mini版kimi,但后來也因為kissy在業務前端的口碑形象下滑的厲害,以及社區內有RN(ReactNative)和Vue的興起,所以kissy的生態也在時代的車輪下漸漸消失。

隨著3G、4G的發展和iOS和Android手機在市場的普及量大增,PC業務主戰場也逐漸過渡到移動端。前端的思維模式由PC轉向了移動端,并向App的用戶體驗看齊。移動端的HTML5協議支持不完善,前端的生產配套不全,Android的屏幕碎片化,所以那個時候的前端開發移動端頁面適配的痛苦要遠遠超過PC時代。

不過,慶幸地是有Angular、React、Vue、RN(ReactNative)這樣的MVVM框架出現,讓前端接受了數據驅動思想的洗禮之外,還借助RN完成了移動端的體驗升級,包括后來的Weex、Flutter。

所以為了解決多端復用的問題,Weex又借助生態上的Vue框架,打通webview和weex兩端,夢想著一套代碼跑天下。但現實中就是打臉的,兩種終端容器能力不對齊,相互制約,一套代碼寫得瞻前顧后。這個時候的前端,被終端技術折磨的苦不堪言。

但好在Web在移動端的發展越來越強,同時借助客戶端的一些能力加持(如hybird、cache、prefetch等),web頁面的體驗強到可以與App分庭抗禮。所以經歷過煎熬的四五年時間,如今web的聲音已經在移動端占主導地位。對應的移動端框架也確定下來。

同時,2016年,小程序的概念開始提出到上線,一種輕App的開放解決方案開始在國內掀起浪潮,微信、支付寶、百度等一堆互聯網大廠(包括如小米、華為等的手機硬件廠商)在這個大潮之下分食。所以一種小程序的新DSL誕生在前端眼前,前端要兼顧web及各個廠商之間的小程序DSL,痛苦又翻倍增加。有痛苦就有人解痛,像WePY、mpvue、Taro等小程序框架如雨后春筍。

在經歷過多方聲音的反反復復多年的爭吵下,最終總算確定了中后臺全部采用React,PC的C端采用跟移動端一樣的同構方案。雖經歷過幾年的痛苦折磨期,但框架之爭總算平靜下來,前端的目光開始關注更上層的東西組件化物料(如AntD、Fussion、ICE中后臺物料等)的建設以及前端行業領域的細分。

面向的是企業ERP、CRM、OA等業務場景,如供應鏈系統,在這個場景下,借助AntD、Fusion、ICE中后臺物料,形成可視化的中后臺搭建解決方案,為業務的前端、開發或產品角色提供一站式中后臺生產解決方案。采用搭建,目的肯定是為了業務生產的提效。

面向的是企業的數據BI分析和可視化呈現場景,如雙11的阿里和商家的企業級數據實時大屏。在這個場景下,借助echart、highcharts、AntV等數據可視化圖表物料,形成一套數據可視化搭建系統,為業務的前端、開發或產品角色提供一站式數據可視化圖表生產解決方案。采用搭建,目的肯定也是為了業務生產的提效。

回看這10年,是互聯網發展和終端發展最快的10年,也是前端發展最快的10年,更是前端程序員掉頭發、白頭發最快的10年。因為沒有哪個技術領域,可以層出不窮地出現新輪子、可以反復不斷的推翻升級升級推翻,但慶幸的是,經歷過百家爭鳴之后的前端行業在各個領域內的建設深度也愈發地趨漸成熟。與此同時,大家也會發現,這些復雜的建設也都是圍繞著能解決業務問題和能提升自身生產效率的角度出發的。

因為這直接與阿里的業務體量相關,阿里每一年的業務體量都是相比去年翻番的(比如出海、下沉、新業務……),所以如果生產力效率跟不上業務的發展節奏,那么在市場競爭上就不占優勢,以2019年三四線下沉市場高度競對的場景為例,如果前端撐不住業務發展的節奏,還是慢慢悠悠地搞生產,那么企業就很難占據市場了。

假設1個中等水平的前端產出一張功能齊全的頁面需要1周時間,1個牛逼的前端可能只需2天時間;而即便都雇傭牛逼的前端,1個前端單打獨斗一周之內最多也就4張頁面產出,如果僅是生產10張頁面,那么雇傭1~2個牛逼的前端一周之內就搞定了,但如果是生產100張、1000張頁面呢?這個時候雇傭多少前端比較合適呢?高端人才的緊俏和招人成本的控制,都會導致廠內的前端的業務壓力倍增。

解鈴還須系鈴人,所以業內開始不斷地涌現hardcode向lowcode方向轉變的提效熱潮。不說外界,單以阿里為例,面向中后臺、C端、數據可視化方向的lowcode平臺就層出不窮,雖說上手復雜度很高(畢竟解決問題的復雜度擺在那里,就像Photoshop一樣),但也都在趨于成熟。

以我帶的團隊為例,我們服務的每一條線下的業務量和復雜度都是居高不下(每條線承接的是千萬級流量,所以業務復雜度自然會高),除了日常產品迭代,每月至少有1~2次的營銷活動同時進行,即便用了上述的lowcode產品,但還是解不了業務方頻繁上訴要人的困局,甚至排期、砍需求這種傳統小伎倆如今也對業務方沒有藥效了。

就像當iOS、AndroidApp生態剛開始興起階段,不斷地有客戶端的人才在向市場輸入,而今當App在市場飽和、用戶分配在終端上安裝的App數量有限,以及移動端Web和輕App技術的飛速發展等客觀因素沖擊下,客戶端的從業者發現保住自己的飯碗越發的困難了。

所以要看一個行業的未來發展怎樣,就看這個行業的人才目前和未來在市場上被密集需要的地方在哪、規則最混濁或混亂的地方在哪。如果說這個行業的規則出奇地清晰、人才的供給又出奇的冷靜,那么基本上來說,這個行業在市場的發展已經達到平衡狀態,而能打破這種平衡重新建立平衡的也肯定是另外的行業的發展滲入。

所以回歸到我們所處的前端行業,如今前端人才被需要的肯定是在互聯網公司,尤其是大廠,因為業務發展需要,且被需要的很密集(勞動密集型產業),而且這個行業恰巧也是發展規則相對混亂的。為何混亂呢?一方面是因終端多元化趨勢嚴重,比如智能穿戴設備和IOT智能家居、智慧醫療、智能建筑等新興產業的市場沖擊,另一方面是因業務的發展形態、發展規模、發展距離(國內到國外)等因素的影響,都導致著過去的終端的技術規則無法適應到新興終端領域內,所以規則在變、技術在變、框架在變、從業者的領域也在變。

所以從這個角度看前端的職能領域只會越來越寬,人才的需求量只會越來越大,供給的能力要求只會越來越高。可以說這是市場對前端這個行業利好的信號,但同樣也是對前端這個行業壓力提醒的信號,如果在這個市場內的前端不能很好的解決市場壓力問題,一旦有新興技術手段形成的新生產力出現,那么前端的這個香餑餑的行業飯碗也就不保了。市場就是這樣冷靜殘酷的,當市場出清淘汰一個行業的時候或許連一聲招呼都不會打,沒有為什么,這是發展的必須。

如今我們看清形勢,再反觀我們的生產力手段,可以說還是人肉勞動密集型的,就算招再牛逼的人才進來,如還是以這種的生產手段生產,那么早晚都會被淘汰,不管有多資深,哪怕是專家、研究員。所以前端發展到這個檔口下,看似成熟,實則危機四伏。

歷史的經驗告訴我們,一個行業的生產供給能力翻倍,那么一定跟這個行業的工藝手段脫不了關系。比如傳統制造業制造一款鞋子、織一塊布,都是人手工的,當這種供給達到瓶頸之后,就開始出現機械化來輔助人來生產,機械化達到一定程度就是自動化,自動化就可以完全脫離人工進行生產。

同樣的道理,前端目前的生產工藝還是人肉的,即便有一定的程度的lowcode產品手段來輔助前端釋放生產壓力,但還是解決不了供不應求的問題,所以沒有別的辦法,只有一條路就是去人肉,改成完全自動化的生產手段,只有讓供給能力遠遠超越需求的市場增長指數,那么才能徹底解決供不應求的問題。

調研發現,市面上就2種形態的解決思路,一種就是堆人的hardcode方式,包括傳統的組件化生態,也都停留在這個階段上;再有一種解法是lowcode的方式,或者輔助自己或者輔助其他角色來做生產(換一句話來說就是生產關系轉移到其他角色身上),這種方式在特定領域內能一定程度上提效,但一旦領域拓寬或稍有移植,就會面臨著不適應,用它工作量反而比hardcode增加很多。目前我們就在第2階段,但生產效率問題還是非常突出。所以我選擇的解法是nocode,雖然這個詞也不是我新創的,但這個詞的涵義足以表達我對生產力供給能力提升下一個階段的看法。而能幫助前端實現nocode解法的技術,一定就是AI(準確來說是機器學習)。Why?

互聯網的發展就是帶來了海量的數據,依靠人腦已經無法去分析清楚一個行業的特征了,至少我們都是凡人大眾,那種類似愛因斯坦的天才畢竟還是少見,不可能哪個行業都要等著愛因斯坦出現才能找到解決方案。所以凡人大腦做不到的事情我們就交給計算機來做,如今的云計算發展和AI發展,已經降低了我們應用AI來解決我們問題的門檻,所以入行AI也是遲早的事,不可能每天都蒙著眼睛裝看不到,而且也一定程度上得承認AI比我們更聰明,所以逃避不了的事實我們干脆一些接受好了。AI就是為海量數據和復雜問題而生的。

這個問題對純前端從業者來說很難,對算法從業者來說也很難,但對既懂前端又會算法的從業者來說就不難了。為了講清楚這個問題,那么我首先來講解下這兩者解題思維的慣性差異是什么,幫助大家先從思想上進行轉變,這樣大家也就更易接受一些。

如果前端看到上面需求時,他的思維慣式一般是這樣的:首先,要有一張畫布,上面有小鳥、管道這兩種對象(Object),小鳥對象中有x、y、width、height、alive等屬性,x、y代表它的水平和垂直位移,width、height代表小鳥自身寬高,alive代表小鳥的生死;管道對象中至少有x、y、width、height、speed5個屬性,x、y代表管道的水平和垂直坐標位置,width、height代表管道的寬高,speed代表的是管道向左的移動速度。其次,要根據管道的移動速度給小鳥建立一個雷達預警機制,通過輪詢的方式不斷地探測正前方是否有障礙物,一旦有了就不斷地在垂直方向上上下位移來做避障。最后,依次類推的方式達到終點。

如果算法看到上面需求時,他的思維慣式一般這樣的:首先,需要找一款模型,拿network為例,可以利用遺傳算法來解決上面的問題,具體就是通過50代小鳥不斷地嘗試碰撞,將每一代失敗的小鳥的基因記錄下來,然后遺傳給下一代,形成遺傳記憶,這樣小鳥就不會以失敗的方式過障,以此類推,直到沒有失敗的小鳥出現,那么成功的基因就訓練完畢,這樣的一代小鳥就可以完全過障了。

大家可以看到,前端的給的解題思路的代碼里是有具體交代小鳥應該怎樣判斷過障的;而看算法解題思路的代碼里其實并沒有具體教小鳥過障的代碼邏輯,有的只是將一些特征和反饋抽取傳遞給到network,而真正的過障判斷過程是模型去做的。而這就是這兩種思路的關鍵差別,準確說是程序員和AI算法工程師的思維慣式差別,程序員的腦海里有著“我能用代碼定義世界”的思維,而AI算法工程師腦海里有著“我該用什么樣的數據訓練模式讓模型自己盡快掌握對錯”的思維。前者是一種由自己來解問題的主觀視角,所以寫的代碼純粹是翻譯給計算機要怎么去解這個問題;后者是一種由機器來替我解決問題的客觀視角,所以寫的代碼純粹是怎樣把問題拋給計算機,并告知輸入及結果對錯,至于計算機是怎么解決這個問題的過程和規律算法工程師都不關心,只關心結果。

前端,里面的關鍵字是“端”,所謂的“前”就是交代離用戶最近的地方。所以用戶接觸到的終端(包括各種異形屏的、沒屏幕的僅有傳感器的終端等等)上面所呈現的任何人機交互內容(可視覺傳達、聽覺傳達、肢體傳達、甚至可能嗅覺傳達等等)都可以認為是前端職責范圍內的工作。面對這種形式多樣的終端,要想快速產出人機交互的內容,我們用AI該怎么做呢?

一種思路是,首先,聚焦在網頁上能呈現的內容形態看看到底有哪幾種(空間軸上的語言),比如文字、圖片、視頻(視頻可以理解為圖片的逐幀動畫,加上音頻)、音頻;然后,我們再看下網頁上什么樣的內容是經常變化的(時間軸上無序狀態),什么樣的內容是通過交互方式產生變化的(時間軸上的有序狀態)。最后,我們的生產策略是,優先考慮將一組時間軸上的訓練數據喂給一個模型讓它識別出時間軸上的變化內容,然后再借助CV或NLP模型針對變化的內容進行實體識別(實體識別可能具體到一系列的模型存在,比如細化到商品圖識別模型),再然后借助另外的CV或NLP模型來識別時間軸上不變的內容(往往這部分內容就是頁面布局和容器框架),再通過一系列實體識別模型來做頁面結構代碼上的映射(高維空間向量余弦值相等)。理論上來說,如有大量的訓練樣本數據,那么模型針對時間軸上的有序狀態(即事件響應)也是可以慢慢自己學習出規律出來的。

也許上面思維未來是對的,但今天來說,前端還沒有準備好,還在一步步進行思維上的轉變和迭代,這的確是需要一個過程。而且機器學習也不是萬能的,它受模型的制約因素很大,而模型往往也是一種算力的象征。我們可以把機器學習比作是一個擁有高復雜度并行密集計算能力(高維空間上的矩陣計算)的統計學計算器,而模型就是這款計算器的內核。也許它能在背后計算出

這樣的宇宙規律,但至少也是進行了深度計算的,而這種深度的計算需要的就是海量的樣本。而樣本就是這款計算器內核塑造成型的靈魂,但這種海量樣本的制造工作也絕非是一朝一夕依靠一個軟件工程出身的技術人員搞得定的。樣本本身就是數據,所以一定要有存量的數據才會有往深度學習方向上發展的可能性。否則人肉制造的樣本,要不質量太差(不夠客觀)、要么就是量的規模不夠。當然,也可以先把計算器搭起來,至于樣本可以隨著時間進行積累,這樣的辦法也不是不可以,就是等待的時日可能比較長,沒法立竿見影收到奇效。

所以,針對商業行為來說,我們至少得有2套方案,一套是長遠的(如上的方案)的準備,一套是短期眼前的方案。如果做短期的,就借助規則系統+機器學習的混合方式來做方案。但不管哪種,樣本問題都是要解的。2套方案也是2種選擇,也許你還有第3種選擇,都是選擇,所以多與少沒有什么差別,只是看能在選擇之后投入多少和堅持多久。這種投入就涉及到知識和技能的儲備了,所以前端至于前端想解決問題,還是得盡快上手機器學習。至于具體怎么上手在此就不做過多介紹了,網上的課程有很多,也可以看西瓜書上手,但關鍵是動手。可以先從CV領域入手,NLP工程對個人來說單機部署有點難,得借助云(比如谷歌的TPU平臺)。

長遠來看,前端+AI的這種前端智能化方向肯定是持續存在的,前端也會因為AI能力的加入,會產生諸多不一樣的生產力變化(比如上圖所標之處)。這種變化可能是階段性的,也可能是終極的,總之生產力會慢慢向計算機身上過渡,前端做的工作是驅動這一切的更深層工作。這個方向沒有退路,也繞不過去(專家系統不可能無敵),所以要解的問題直到徹底解決為止。

2~3年內,前端智能化從業者數量翻倍,AI在前端領域內或多或少有一些產品形態上的應用,終端開始浮現各種前端機器學習框架,用戶產品在智能化體驗方面的設計也有對應的傾斜,社區上也開始浮現出各種前端智能化的工程框架、訓練框架和AI平臺;

3~5年內,前端智能化從業者數量繼續增長,傳統前端已經被淘汰,前端領域內智能化在特定領域內小有成績,可以解決特定領域內的一些業務或人力生產效率問題,終端智能體驗會趨漸成熟,給用戶帶來的沉浸式體驗增強,線上線下無屏化無差異體驗趨近相同,社區上開始開源一些前端的智能化產品;


Copyright 2003 - 2002 365体育平台首页. All Rights Reserved 版权所有粤ICP11235728 地址:BENZCLOUD奔馳雲端 優質平價雲端服務