從前端到全棧開發(fā)的技術(shù)迭代升級(jí)

從前端到全棧開發(fā)的技術(shù)迭代升級(jí)，從前端技術(shù)演進(jìn)看前端發(fā)展野心、同時(shí)滿足技術(shù)需求和商業(yè)需求的前端全棧、打破物理隔離，實(shí)現(xiàn)真全棧、小程序云服務(wù)的發(fā)展優(yōu)化、 從前端開發(fā)到全棧開發(fā)等五個(gè)方面具體來(lái)看看。

一、 從前端技術(shù)演進(jìn)看前端發(fā)展野心

從兩個(gè)維度去分析前端的技術(shù)發(fā)展，一個(gè)維度是前端復(fù)雜度，具體來(lái)講就是前端在解決創(chuàng)建應(yīng)用復(fù)雜度方面做的一些事情；另一個(gè)是從廣度層面看前端做的事情，這兩個(gè)維度構(gòu)成了一個(gè)類似于二維平面的時(shí)間事件平面。

1、逐漸降低創(chuàng)建應(yīng)用復(fù)雜度

單看復(fù)雜度，前端最開始的階段只有HTML、JS、CSS，應(yīng)用雖然是非常簡(jiǎn)單的，開發(fā)起來(lái)卻是非常復(fù)雜的，因此，單單只是DOM操作方面就有大量的DOM操作API。為了降低操作成本，就出現(xiàn)了DOM操作框架，比如jquery。這個(gè)階段類似于從原始的刀耕火種進(jìn)入石器時(shí)代。對(duì)dom的操作帶來(lái)了很大的便利性。盡管如此，真正在構(gòu)建一個(gè)復(fù)雜應(yīng)用的時(shí)候，因?yàn)闃I(yè)務(wù)邏輯和手動(dòng)操作dom邏輯交織在一起，應(yīng)用維護(hù)變得越來(lái)越難。

下一個(gè)階段，引入了MVC分層思想，比如backbone,這能夠?qū)⑦壿嬍崂淼母忧逦恍?。不過(guò)，MVC還是需要去關(guān)注視圖層的。

接著，就出現(xiàn)了mvvm框架，開發(fā)者不需要再關(guān)注視圖層的更新，只需要關(guān)注邏輯層、數(shù)據(jù)層。這一點(diǎn)為構(gòu)建復(fù)雜大型app提供了極大的便利性。mvvm從Angular到現(xiàn)在react、vue的廣泛應(yīng)用，前端在邏輯構(gòu)建層面發(fā)展已經(jīng)到了一個(gè)新的階段。在構(gòu)建大型應(yīng)用的時(shí)候，僅有邏輯層是不行的，還缺乏工程性的思想。因此，出現(xiàn)了打包的模式，幫助我們構(gòu)建更復(fù)雜的應(yīng)用。這樣我們所能做的APP復(fù)雜度是一個(gè)指數(shù)型的增長(zhǎng)。

為了進(jìn)一步提高可構(gòu)建應(yīng)用的復(fù)雜度、增強(qiáng)前端的性能，assembly技術(shù)標(biāo)準(zhǔn)出現(xiàn)，提供了前端字節(jié)碼的標(biāo)準(zhǔn)，為創(chuàng)建更加復(fù)雜的應(yīng)用打好了堅(jiān)實(shí)的基礎(chǔ)。

2、 一直在擴(kuò)展的前端廣度

剛開始只能在瀏覽器上運(yùn)行，后來(lái)有了node代碼，可以讓我們的代碼擴(kuò)展到服務(wù)器端。緊接著PC端有electron。再到移動(dòng)端有RN框架，支持我們向移動(dòng)端進(jìn)展?，F(xiàn)在出現(xiàn)了小程序，小程序框架能夠讓前端繼續(xù)在移動(dòng)端輕應(yīng)用做探索。這里沒(méi)有講到的嵌入式開發(fā)，這方面也有相應(yīng)的解決方案。前端不斷擴(kuò)展廣度，把前面的邊界不斷擴(kuò)大。最終前端想一統(tǒng)天下，把前端全棧化。

二、 同時(shí)滿足技術(shù)需求和商業(yè)需求的前端全棧

所有的技術(shù)在發(fā)展時(shí)期都有兩條線去支撐著它發(fā)展，一條線是技術(shù)需求，即技術(shù)層面的技術(shù)創(chuàng)意和技術(shù)訴求；另外一條線是商業(yè)需求，即技術(shù)要滿足對(duì)應(yīng)的商業(yè)訴求。

一個(gè)解決方案只有同時(shí)滿足商業(yè)訴求和技術(shù)需求，才能蓬勃的發(fā)展。如果偏離這兩條線，就很難發(fā)展起來(lái)。舉個(gè)例子，比如Symbian，有些人有想嘗試這個(gè)技術(shù)訴求，但是因?yàn)樗呀?jīng)脫離商業(yè)需求的層面，所以這個(gè)技術(shù)會(huì)慢慢被淘汰掉。

那么，如果僅有商業(yè)需求又會(huì)出現(xiàn)怎樣的情況呢？比如，2000年的時(shí)候?qū)I有商業(yè)上的需求，但是技術(shù)需求并滿足，當(dāng)時(shí)AI就是一個(gè)要被擱置的東西。前端全棧，是怎樣在滿足技術(shù)需求的同時(shí)滿足商業(yè)需求的呢？

我們回歸到移動(dòng)端APP的開發(fā)實(shí)際場(chǎng)景，只有兩個(gè)層面：一個(gè)是UI交互界面的開發(fā)，這個(gè)是可以被用戶感知到的，另外一個(gè)是用戶感受不到的服務(wù)邏輯層面。如果來(lái)看現(xiàn)有的開發(fā)模式，單單從UI交互界面上來(lái)看，就有不同的平臺(tái)端android、ios、h5，對(duì)應(yīng)的語(yǔ)言有Java、OC、swift、js等幾種語(yǔ)言，后端的語(yǔ)言和技術(shù)實(shí)現(xiàn)是更多的。在現(xiàn)在的模式下，一個(gè)小型公司如果需要開發(fā)一個(gè)完整的APP項(xiàng)目，就需要六種技術(shù)！

每一種技術(shù)如果需要找一個(gè)專門的人來(lái)做，這就需要6個(gè)人。那么反映到公司企業(yè)運(yùn)營(yíng)上面，人力成本是比較高的，除了人力成本還有同樣非常高的溝通成本。從溝通的角度上來(lái)看，全棧式開發(fā)模式的出現(xiàn)，能夠讓一個(gè)人負(fù)責(zé)更多的業(yè)務(wù)開發(fā)，降低溝通成本。

由此可見，前端全棧既滿足技術(shù)需求，也滿足商業(yè)需求的，所以我相信未來(lái)前端全棧一定會(huì)蓬勃發(fā)展。

三、 打破物理隔離，實(shí)現(xiàn)真全棧

再回過(guò)頭看前端散落的各種技術(shù)，在這個(gè)發(fā)展的過(guò)程中，有一個(gè)很深的隔離，這個(gè)隔離本質(zhì)上就是物理隔離，比如前端和后端，存在手機(jī)和服務(wù)器之間的物理隔離。

因?yàn)楦鞣N端是實(shí)體端，每個(gè)端之間都存在物理隔離。就比如前端和后端，存在手機(jī)和服務(wù)器之間的物理隔離。如果能解決這些隔離，就可以把前端的技術(shù)做到真正的統(tǒng)一開發(fā)模式，才能做到真全棧開發(fā)。

其實(shí)后端的物理隔離，比如每臺(tái)服務(wù)器之間的物理隔離，可以通過(guò)云端化，我們把代碼上傳到云端平臺(tái)，云端平臺(tái)會(huì)屏蔽機(jī)器之間的物理隔離，暴露給開發(fā)者的只有一個(gè)集群的概念，而不是一臺(tái)機(jī)器一臺(tái)機(jī)器管理部署。云端化之后，后端的物理隔離被消除了。
我們現(xiàn)在的前端代碼和服務(wù)器之間終存在一個(gè)物理隔離，目前的解決方案是通過(guò)中間的協(xié)議打破物理隔離，比如http協(xié)議，但http協(xié)議畢竟是中間協(xié)議。
而serverless的理念就能完完全全解決掉這層物理隔離，因?yàn)榇a即服務(wù)，serverless能打破這層隔離實(shí)現(xiàn)前端的真全棧。

Serverless中的FaaS，函數(shù)即服務(wù)，我在使用后端服務(wù)的時(shí)候，不再關(guān)心后端的ip地址，后端的域名是什么樣的，直接調(diào)用函數(shù)即可，對(duì)前端來(lái)說(shuō)，后端服務(wù)是一個(gè)函數(shù)，函數(shù)就是前端的代碼的一部分，后端服務(wù)和前端完全的融合在一種代碼體系里去了，這樣后端的服務(wù)即是一個(gè)函數(shù)，至于這個(gè)函數(shù)是在前端實(shí)現(xiàn)，或者是在后端很遠(yuǎn)的地方實(shí)現(xiàn)，開發(fā)者都可以不用關(guān)心。所以說(shuō)，severless打破了物理隔離。開發(fā)者不再去做任何隔離中間層的事前，我只需要關(guān)心函數(shù)的實(shí)現(xiàn)就可以了，函數(shù)也是用我的前端代碼來(lái)寫，所以達(dá)到了充分融合的定義。

回過(guò)來(lái)看具體的實(shí)現(xiàn)場(chǎng)景，比如云開發(fā)，整個(gè)小程序的前后端邏輯都能在一個(gè)IDE里面完成，用戶其實(shí)完全不用擔(dān)心哪些是服務(wù)器的邏輯，他們都去向了哪里，只需要像前端函數(shù)一樣去理解就可以了。云函數(shù)現(xiàn)在也支持了本地調(diào)試，就像前端代碼一樣調(diào)試，所以可以做真正的前端全棧技術(shù)開發(fā)，這對(duì)現(xiàn)有的開發(fā)模式是一個(gè)很大的革新。

四、 小程序云服務(wù)的發(fā)展優(yōu)化

那么，在大前端技術(shù)發(fā)展的這波浪潮里面，小程序云服務(wù)又有什么樣的發(fā)展呢？早在2017年初小程序正式發(fā)布的時(shí)候，第一代騰訊云小程序云服務(wù)就已經(jīng)誕生了，但隨著8月份全面向個(gè)人開發(fā)者開放，我們發(fā)現(xiàn)這套支服務(wù)還是有一定門檻的。于是就開始著手去做更深度的云服務(wù)整合和優(yōu)化，才有了后來(lái)的wafer2 和現(xiàn)在的云開發(fā)。

早期第一代產(chǎn)品 Wafer 的整個(gè)開發(fā)部署流程，統(tǒng)計(jì)了一下大概需要十幾步，對(duì)許多中長(zhǎng)尾的客戶來(lái)說(shuō)并不是那么友好。于是我們開始著手優(yōu)化。

通過(guò)整個(gè)優(yōu)化，可以簡(jiǎn)略成四步。第一步是通過(guò)一鍵的配置購(gòu)買就能把云開發(fā)產(chǎn)品開通起來(lái)，第二步是工程師進(jìn)行小程序的前后臺(tái)開發(fā)，第三步進(jìn)行代碼的預(yù)覽上傳，測(cè)試體驗(yàn)完，最后便是發(fā)布。經(jīng)過(guò)我們這一兩年的努力，小程序開發(fā)的流程已經(jīng)由十幾步簡(jiǎn)化到四步了。目前如果從市面上來(lái)看，我們這個(gè)產(chǎn)品在用戶體驗(yàn)以及流程簡(jiǎn)化度上，在行業(yè)內(nèi)是較為領(lǐng)先的。

那么，我們騰訊云團(tuán)隊(duì)和微信團(tuán)隊(duì)如何一步一步優(yōu)化我們的產(chǎn)品，將產(chǎn)品的接入門檻降低、流程變簡(jiǎn)的呢？

最初我們看到的是可以將 devops 的部份環(huán)節(jié)給優(yōu)化一下，包括代碼上傳部署。這就催生了后來(lái)的Wafer 2，亦即第二代的小程序云服務(wù)產(chǎn)品。另外開通購(gòu)買步驟也是比較繁瑣的。將騰訊云和小程序的賬號(hào)打通后，可以做到一鍵授權(quán)并且開通環(huán)境與服務(wù)，并且我們提供了一個(gè)免費(fèi)的開發(fā)環(huán)境，這樣可以讓更多開發(fā)者在進(jìn)來(lái)發(fā)布小程序之前，可以以更低的成本門檻用上云開發(fā)。

剩下還可以優(yōu)化的就只有 SDK 引入和填寫配置的環(huán)節(jié)了。

SDK 其實(shí)可以采用內(nèi)置的方式，畢竟小程序的前端接口也是直接內(nèi)置到運(yùn)行環(huán)境的 webview里面的。但是配置這塊并不太好做了。因?yàn)橐恢币詠?lái)，小程序前端和后臺(tái)的開發(fā)都是割裂的，因此整個(gè)用戶的鑒權(quán)機(jī)制都是交由小程序開發(fā)者自己去處理。但為什么小程序與云服務(wù)一定是要割裂的呢，為什么不能整合到一起呢？而 Serverless 這種開發(fā)模式是前后端緊密結(jié)合的最佳粘合劑。

一般而言，請(qǐng)求從小程序側(cè)發(fā)起，到云服務(wù)的后臺(tái)邏輯進(jìn)行鑒權(quán)處理，如果鑒權(quán)成功再調(diào)用微信公開發(fā) API，然后再把數(shù)據(jù)返回到小程序。

但我們稍微將整個(gè)請(qǐng)求鏈路改變一下，小程序側(cè)的請(qǐng)求先通過(guò)微信的服務(wù)，認(rèn)證并鑒權(quán)成功之后，再到騰訊云這邊的 Serverless 服務(wù)進(jìn)行邏輯的處理，處理完畢后再返回到小程序側(cè)。這樣，我們把整個(gè)配置和鑒權(quán)服務(wù)都幫用戶完成了，這又大大減輕了開發(fā)者的負(fù)擔(dān)。

通過(guò)介紹整個(gè)小程序云服務(wù)的優(yōu)化歷程，相信大家能感悟到整個(gè)產(chǎn)品的理念，就是希望一方面云能力逐步成為小程序開發(fā)的基礎(chǔ)能力，另一方面也希望盡量減少開發(fā)者需要理解的概念。

五、 從前端開發(fā)到全棧開發(fā)

在云開發(fā)模式的推動(dòng)下，我們開發(fā)模式是怎么一步步走到現(xiàn)在的開發(fā)模式的？

在Web剛出現(xiàn)的時(shí)候，后臺(tái)開發(fā)本就是大包大攬，后臺(tái)邏輯完成后，再把模板和數(shù)據(jù)吐出來(lái)到瀏覽器渲染。當(dāng)時(shí)基本上都是做一些比較簡(jiǎn)單的Web應(yīng)用。但是當(dāng)時(shí)沒(méi)有人會(huì)吐槽你的后臺(tái)工程師只有一個(gè)人，怎么都把后臺(tái)和前端服務(wù)都干完了，可能當(dāng)時(shí)的業(yè)務(wù)邏輯并不是很復(fù)雜，前端技術(shù)也不是那么的規(guī)范化，應(yīng)用場(chǎng)景不是那么多，所以才出現(xiàn)這樣的情況。

可是到后來(lái)，隨著瀏覽器逐步發(fā)展，JS、CSS、HTML有一個(gè)規(guī)范委員會(huì)幫它每年制定一些新的特性。而且隨著業(yè)務(wù)場(chǎng)景越來(lái)越復(fù)雜，這種情況下開始提出前后端分離，開始要求后臺(tái)和前端是分開兩個(gè)人做事情，前后兩端是通過(guò)API的請(qǐng)求和返回去做一個(gè)數(shù)據(jù)交互。

再到了2008年的時(shí)候，喬老爺子憑一己之力開啟了移動(dòng)端的開發(fā)生態(tài)。到了2017年張小龍大神也跟微信團(tuán)隊(duì)推出了小程序且打造了小程序生態(tài)。這個(gè)時(shí)候很多專家提出了“大前端”的概念，希望只寫一份代碼，就是編譯并完成不同客戶端的業(yè)務(wù)，這些端只需要共享一個(gè)后臺(tái)服務(wù)就可以了。
這個(gè)時(shí)代國(guó)外出現(xiàn)了一些跨端方案，比如React Native，國(guó)內(nèi)也涌現(xiàn)了 Taro，Omi 等優(yōu)秀的跨端方案。這幾個(gè)時(shí)期的前端職能是有明顯擴(kuò)張的。

只做了大前端完全滿足不了前端的野心，隨著Node.js的發(fā)展，有一些中臺(tái)的服務(wù)，比如同構(gòu)渲染和業(yè)務(wù)接口但逐步轉(zhuǎn)給Node.js 來(lái)做。后臺(tái)的同事開始專注于去寫一些后臺(tái)的調(diào)度服務(wù)或者優(yōu)化整個(gè)數(shù)據(jù)的讀取性能。這個(gè)時(shí)期，前端開發(fā)者也開始從前端逐步往后臺(tái)做一個(gè)拓展。

但大前端的步伐遠(yuǎn)遠(yuǎn)不只于此，在很多業(yè)務(wù)場(chǎng)景里面，前端工程師比較貼近客戶，所以他更能夠去理解到一些業(yè)務(wù)邏輯，無(wú)論是業(yè)務(wù)的前臺(tái)或是后臺(tái)，交給前端工程師來(lái)做是更好的。舉個(gè)例子，云開發(fā)的其中一個(gè)客戶是唯品會(huì)的前端團(tuán)隊(duì)。他們其中有個(gè)業(yè)務(wù)需要依靠后臺(tái)來(lái)支持，但他們的后臺(tái)人力很緊缺沒(méi)有辦法馬上投入支持。于是他們的前端就借助云開發(fā)，投入1個(gè)前端工程師就迅速把這個(gè)業(yè)務(wù)給做完上線了。其實(shí)許多公司的業(yè)務(wù)都有類似的情況，公司業(yè)務(wù)發(fā)展非?？欤械臅r(shí)候要前端等待后臺(tái)的人力，這樣就影響到整個(gè)公司的業(yè)務(wù)發(fā)展。

可是前端的全棧開發(fā)的模式，從前端到后臺(tái)，把所有的業(yè)務(wù)全都寫完了，其實(shí)你會(huì)發(fā)現(xiàn)又回到我們最初的一個(gè)工程師大包大攬的做事情?？墒沁@個(gè)業(yè)務(wù)是復(fù)雜的，如果沒(méi)有一個(gè)工具或者一個(gè)云的基建設(shè)施去支撐這個(gè)夢(mèng)想的話，其實(shí)是完全不能實(shí)現(xiàn)的。

面對(duì)這樣的挑戰(zhàn)，我們應(yīng)該怎么答復(fù)我們的老板呢？

騰訊云目前提供的解決方案就是云開發(fā)。

傳統(tǒng)開發(fā)模式會(huì)讓前端變成大包大攬地做業(yè)務(wù)，其實(shí)是相當(dāng)困難的，因?yàn)橐环矫嬉_發(fā)前端和后端的邏輯，還要處理所有的運(yùn)維的事情，靠一個(gè)人是不可能的，所以才有了現(xiàn)在這樣的傳統(tǒng)分工模式，就是前端、后臺(tái)、運(yùn)維。如果把這個(gè)業(yè)務(wù)用上云開發(fā)的話，我們主要關(guān)心的只有一小部分，主要都是我們的業(yè)務(wù)邏輯。至少只要這個(gè)工程師能夠懂Node.js，基本上就可以把服務(wù)穩(wěn)定、性能卓越和有一定安全性的小程序應(yīng)用獨(dú)立開發(fā)出來(lái)。

云開發(fā)的開發(fā)模式真正可以實(shí)現(xiàn)前端工程師全棧開發(fā)的理想模式。

來(lái)源：騰訊云開發(fā)TCB

985大學(xué) 211大學(xué) 全國(guó)院校對(duì)比 專升本