作者:淘系-凌乙
來源:微信公眾號(hào):淘系前端團(tuán)隊(duì)
出處:https://mp.weixin.qq.com/s?__biz=MzI5NjM5NDQxMg==&mid=2247489820&idx=1&sn=a5b450429cf7564e5b08225136b19db8
背景介紹
近年來,關(guān)于低代碼(LowCode)和無代碼(NoCode)的討論在前端社區(qū)內(nèi)越來越火,簡(jiǎn)單的說低代碼就是通過編寫少量代碼的方式完成應(yīng)用的開發(fā)及上線,而無代碼則更進(jìn)一步,不需要編寫代碼通過配置的方式即可完成整個(gè)應(yīng)用的開發(fā)。目前集團(tuán)內(nèi)部的低代碼平臺(tái)已經(jīng)有很多,比如iceluna,宜搭,樂高,云鳳蝶等等,而通用的無代碼搭建平臺(tái)還處在探索階段。
低代碼和無代碼
首先不管是低代碼還是無代碼,都是針對(duì)特定場(chǎng)景或者細(xì)分領(lǐng)域的,比如運(yùn)營的活動(dòng)頁,中后臺(tái)的表單,表格頁面等,因?yàn)橹挥性谶@些場(chǎng)景下,前端交互相對(duì)收斂,能夠沉淀出足夠多的組件物料,從而通過可視化的方式拖拽組件就能夠直接搭建出頁面。
目前我所在的團(tuán)隊(duì)正在研究面向營銷域的中后臺(tái)前端解決方案。通常來說,中后臺(tái)解決方案的核心目標(biāo)是提效,提效包括兩個(gè)方面,一方面是對(duì)研發(fā)人員的提效,另一方面是對(duì)用戶的提效,提效的核心抓手在于生產(chǎn)關(guān)系的變更,由前端開發(fā)向后端,視覺,產(chǎn)品各方面參與發(fā)展,從而降低前端研發(fā)的門檻,提高生產(chǎn)效率。提效解決的不是20%的個(gè)性化增量需求,而是解決讓“非前端”參與進(jìn)來,解決80%的通用需求。中后臺(tái)的提效路徑大部分走的都是ProCode->LowCode->NoCode方式。
表面上看,從ProCode->LowCode->NoCode看起來好像只有很小的差別,好像只有代碼量多少的問題,但整個(gè)過程已經(jīng)從量變發(fā)生了質(zhì)變。ProCode和LowCode主要面向的還是一些需要有前端編程能力的人,而NoCode則代表“非前端”也能夠參與的前端的頁面搭建中來,這里面不是說完全不需要代碼,因?yàn)榻裉炷男┧恪按a”其實(shí)比較難界定,比如用戶編寫一個(gè)配置文件,這個(gè)文件是json格式的,那到底能不能算“代碼”?所以,NoCode的意思不是說沒有代碼,而是說在于用戶學(xué)習(xí)門檻和學(xué)習(xí)成本的降低,普通用戶不需要經(jīng)過艱難的學(xué)習(xí)就可以做到以前程序要編碼才能實(shí)現(xiàn)的事情。
iceluna低代碼平臺(tái)的痛點(diǎn)問題
iceluna作為集團(tuán)內(nèi)優(yōu)秀的低代碼搭建平臺(tái),主要解決中后臺(tái)頁面快速搭建的場(chǎng)景,經(jīng)過幾年的探索,基本能夠?qū)崿F(xiàn)頁面UI的可視化搭建,但是針對(duì)業(yè)務(wù)邏輯還是需要手動(dòng)編碼來實(shí)現(xiàn)。這對(duì)非前端開發(fā)人員的上手門檻還是比較高的。下面這張圖是最近針對(duì)iceluna的用戶(前端,后端和測(cè)試)做的一個(gè)調(diào)研分析,可以看到邏輯代碼和數(shù)據(jù)綁定的學(xué)習(xí)成本也是用戶在問卷中提的最多的。
因此在這個(gè)財(cái)年,我們嘗試去用可視化邏輯編排的方式解決邏輯相關(guān)的問題,解決低代碼中最后一點(diǎn)需要編碼的部分,實(shí)現(xiàn)無代碼化的研發(fā)模式,從而進(jìn)一步降低用戶的學(xué)習(xí)和使用門檻。
可視化邏輯編排
首先我們來通過一個(gè)邏輯編排的示例來看一下如果一段代碼通過編排的方式呈現(xiàn)出來之后會(huì)帶來怎么樣的體感:
如上圖所示,原本晦澀難懂的代碼邏輯通過流程圖的形式表達(dá)出來以后,產(chǎn)品的邏輯變得非常直觀??勺x性和可維護(hù)性也變得非常高。再也不用擔(dān)心在接手其他人的項(xiàng)目時(shí),注釋不規(guī)范,文檔不全的問題,邏輯編排生成的邏輯圖譜就是天然的產(chǎn)品文檔。
邏輯節(jié)點(diǎn)抽象
可以看出,要形成這樣的邏輯圖譜,本質(zhì)上就是需要對(duì)不同邏輯節(jié)點(diǎn)進(jìn)行組合和串聯(lián),真正的邏輯由封裝在節(jié)點(diǎn)中的函數(shù)完成。那么這里就產(chǎn)生了兩個(gè)問題,首先是如何抽象邏輯節(jié)點(diǎn),抽象出的邏輯節(jié)點(diǎn)能不能被復(fù)用直接決定了用戶編排的成本,如果需要不斷的定制個(gè)性化邏輯節(jié)點(diǎn)可能就失去了編排的意義;其次是邏輯節(jié)點(diǎn)的的顆粒度大小也非常關(guān)鍵,如果封裝的邏輯顆粒度太大,大到一個(gè)功能服務(wù),那么可能就變成了業(yè)務(wù)流程編排;如果顆粒度太小,小到一個(gè)表達(dá)式級(jí)別,那么對(duì)于有編程基礎(chǔ)的同學(xué)來說,可能直接寫代碼效率反而更高。
通過對(duì)中后臺(tái)營銷域的部分業(yè)務(wù)代碼進(jìn)行梳理,發(fā)現(xiàn)中后臺(tái)的頁面大都是以表單、列表,詳情為主,而其中90%的業(yè)務(wù)邏輯基本上都圍繞在表單(校驗(yàn),取值,賦值,提交),對(duì)話框(顯隱、提示),發(fā)送請(qǐng)求,消息提示,數(shù)據(jù)處理,路由跳轉(zhuǎn),條件判斷等,相對(duì)比較收斂。同時(shí)iceluna作為集團(tuán)內(nèi)優(yōu)秀的低代碼搭建平臺(tái),在上層封裝了很多非常好用的api,屏蔽了大部分前端語法層面的差異,比如狀態(tài)賦值,頁面刷新,接口調(diào)用,一些常用的工具函數(shù)(時(shí)間處理)等,為邏輯節(jié)點(diǎn)的抽象提供了極大的便利性。
通過分析歸類,最后沉淀了10個(gè)左右的邏輯節(jié)點(diǎn),如下圖所示,同時(shí)每一個(gè)邏輯節(jié)點(diǎn)最終本質(zhì)上都是對(duì)應(yīng)一段執(zhí)行函數(shù),并接收一個(gè)參數(shù)作為入?yún)ⅲ祷匾粋€(gè)參數(shù)作為出參。
編排協(xié)議
由于是可視化編排,自然也避免不了編排的協(xié)議,為了避免重復(fù)建設(shè)最大程度的復(fù)用集團(tuán)內(nèi)已有的編排方案,最終計(jì)劃采用LF通用可視化邏輯編排的協(xié)議來實(shí)現(xiàn)iceluna中的邏輯編排。
技術(shù)架構(gòu)圖
技術(shù)難點(diǎn)
自動(dòng)化布局
從一開始調(diào)研我們就發(fā)現(xiàn)大部分的編排產(chǎn)品,都是讓用戶自己進(jìn)行拖拽,連線等操作去完成,但是通過前面對(duì)邏輯代碼的分析,如果我們將異步回調(diào)操作使用async/await的方式轉(zhuǎn)換成同步的寫法,那么邏輯代碼大部分都可以看作是一種串行式的執(zhí)行過程,偶爾疊加一些if/else的分支判斷,這樣也非常符合人們常用的思維模式,理解起來非常直觀。所以從編排的角度說,就是將不同的邏輯節(jié)點(diǎn)和分支判斷節(jié)點(diǎn)串聯(lián)起來,布局上不需要太多的靈活性,同時(shí)連線操作也顯得比較多余,因此我們將拖拽連線全部改成添加節(jié)點(diǎn)的方式,然后自動(dòng)連線即可。
采用這種自動(dòng)布局的方式會(huì)大大簡(jiǎn)化用戶的操作,用戶只需關(guān)注核心的業(yè)務(wù)邏輯流程,按順序添加節(jié)點(diǎn)即可,但同時(shí)也帶來一個(gè)問題,由于分支類型的節(jié)點(diǎn)會(huì)產(chǎn)生兩個(gè)分支流,如果遇到嵌套分支的情況下,需要自動(dòng)將上層分支的橫坐標(biāo)的位置統(tǒng)一向右偏移一個(gè)單位,否則處在上下層不同分支上的節(jié)點(diǎn)位置可能會(huì)產(chǎn)生重疊。為此,我設(shè)計(jì)了一自動(dòng)布局算法,最終實(shí)現(xiàn)的效果圖如下:
算法過程比較簡(jiǎn)單,采用的是DFS深度優(yōu)先遍歷算法,詳細(xì)過程這里就不再贅述。
代碼與schema互轉(zhuǎn)
邏輯圖編排完成之后,緊接著面臨的問題是如何保證編排后的邏輯正確的運(yùn)行,產(chǎn)生和源碼一樣的效果。一開始討論的有兩種方案,第一種方案把整個(gè)邏輯看成一個(gè)事件流,按照前面設(shè)計(jì)的邏輯編排schema,通過事件注冊(cè)監(jiān)聽的方式完成邏輯節(jié)點(diǎn)的上下游串聯(lián),最后設(shè)計(jì)一套事件執(zhí)行器,依次觸發(fā)事件即可。這種方式實(shí)現(xiàn)起來比較簡(jiǎn)單,但是對(duì)原有開發(fā)流程的侵入性比較強(qiáng)。因?yàn)樵斜4媸录瘮?shù)的地方都要被替換成邏輯schema,同時(shí)負(fù)責(zé)code review的前端同學(xué)看到的不再是代碼diff,而是schema的diff,這無疑會(huì)大大增加了CR的風(fēng)險(xiǎn)。因此經(jīng)過一番討論之后,我們決定采用第二種方案,將邏輯編排后的schema自動(dòng)轉(zhuǎn)成代碼,同時(shí)生成后的代碼也要能夠自動(dòng)轉(zhuǎn)回schema。
基于schema轉(zhuǎn)成代碼是比較容易的,因?yàn)槊總€(gè)邏輯節(jié)點(diǎn)本身就映射了一段函數(shù)片段,而將代碼轉(zhuǎn)回schema則稍微有些復(fù)雜。這里主要利用了Babel先對(duì)代碼進(jìn)行解析,得到抽象語法樹AST,然后遍歷AST中類型為statement的節(jié)點(diǎn),最后通過正則匹配找到對(duì)應(yīng)的邏輯節(jié)點(diǎn),并串聯(lián)好連線即可。下圖就是生成好的一份代碼示例:
可以看出,通過schema生成后的代碼與源碼編寫還是有一點(diǎn)區(qū)別,帶有一些邏輯編排的特征,但是可讀性更強(qiáng),從代碼基本也能直觀的反推出邏輯流程圖,反而從一定程度上降低了code review的成本。整個(gè)AST解析的過程如下:
斷點(diǎn)調(diào)試
對(duì)于寫業(yè)務(wù)邏輯來說,不可避免的需要調(diào)試功能,這對(duì)有編程能力的同學(xué)來說是件很自然的事情,但是當(dāng)邏輯變成通過可視化的編排之后,如何讓這些”非前端“用戶也能方便的通過調(diào)試定位錯(cuò)誤,變得也尤為關(guān)鍵。
調(diào)試其實(shí)本質(zhì)上對(duì)用戶來說,就是需要一個(gè)能夠讓編排后的邏輯模擬運(yùn)行起來的過程,因此我們對(duì)邏輯節(jié)點(diǎn)的各個(gè)環(huán)節(jié)做了埋點(diǎn),用戶在模擬運(yùn)行的過程中就能查看每個(gè)節(jié)點(diǎn)的數(shù)據(jù)狀態(tài)、上下文參數(shù)、報(bào)錯(cuò)類型等,同時(shí)根據(jù)邏輯流程圖的狀態(tài)(綠色代表執(zhí)行成功,紅色代表執(zhí)行失?。┮材芊浅?焖俚亩ㄎ粏栴}所在,如下圖所示:
目前調(diào)試功能還處在初級(jí)階段,后面還會(huì)持續(xù)迭代優(yōu)化,比如調(diào)試時(shí)增加單步執(zhí)行功能,像瀏覽器的單步調(diào)試工具一樣進(jìn)行斷點(diǎn)。
總結(jié)展望
總結(jié)
目前,可視化邏輯編排已經(jīng)搭載集團(tuán)內(nèi)的iceluna低代碼搭建平臺(tái)正式上線,并已經(jīng)在營銷工具業(yè)務(wù)中正式使用。從低代碼向無代碼的研發(fā)模式升級(jí)仍處在探索階段,過程中避免不了會(huì)遇到很多問題,但也算邁出了關(guān)鍵性的一步,值得期待。
展望
前面提到,從ProCode->LowCode->NoCode,通過降低研發(fā)門檻,讓非技術(shù)人員參與到應(yīng)用開發(fā)中來,可以大大提高生產(chǎn)效率,但理想很豐滿,現(xiàn)實(shí)也很骨感,NoCode搭建平臺(tái)我認(rèn)為目前還只能在比較垂直的場(chǎng)景中才能適用,并且由于不像LowCode一樣仍然能夠?qū)懘a的逃離機(jī)制,通過NoCode的方式可能只能完成一個(gè)70分左右的產(chǎn)品。但是換一個(gè)角度去看,如果可以讓一個(gè)非技術(shù)人員,只用很低的門檻就完成一個(gè)70分左右的產(chǎn)品(最小可用產(chǎn)品MVP),并能直接推廣到市場(chǎng)去試錯(cuò),如果驗(yàn)證可行,再通過轉(zhuǎn)成LowCode或者ProCode的方式繼續(xù)迭代優(yōu)化。光這一點(diǎn)我認(rèn)為就是很有價(jià)值的,是推動(dòng)商業(yè)創(chuàng)新的核心驅(qū)動(dòng)力。因此我認(rèn)為未來的產(chǎn)品研發(fā)節(jié)奏可能是從NoCode->LowCode->ProCode,每一流程都要有對(duì)應(yīng)的解決方案,并且互相之間能夠相互打通,只有這樣才能在競(jìng)爭(zhēng)日益激烈的市場(chǎng)環(huán)境下更好的生存。
作者:淘系-凌乙
來源:微信公眾號(hào):淘系前端團(tuán)隊(duì)
出處:https://mp.weixin.qq.com/s?__biz=MzI5NjM5NDQxMg==&mid=2247489820&idx=1&sn=a5b450429cf7564e5b08225136b19db8
版權(quán)聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn),該文觀點(diǎn)僅代表作者本人。本站僅提供信息存儲(chǔ)空間服務(wù),不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容, 請(qǐng)發(fā)送郵件至 舉報(bào),一經(jīng)查實(shí),本站將立刻刪除。