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

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

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

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

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

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

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

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

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

2、 一直在擴展的前端廣度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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