背景介紹

近年來(lái)，關(guān)于低代碼（LowCode）和無(wú)代碼（NoCode）的討論在前端社區(qū)內(nèi)越來(lái)越火，簡(jiǎn)單的說(shuō)低代碼就是通過(guò)編寫少量代碼的方式完成應(yīng)用的開(kāi)發(fā)及上線，而無(wú)代碼則更進(jìn)一步，不需要編寫代碼通過(guò)配置的方式即可完成整個(gè)應(yīng)用的開(kāi)發(fā)。目前集團(tuán)內(nèi)部的低代碼平臺(tái)已經(jīng)有很多，比如iceluna，宜搭，樂(lè)高，云鳳蝶等等，而通用的無(wú)代碼搭建平臺(tái)還處在探索階段。

低代碼和無(wú)代碼

首先不管是低代碼還是無(wú)代碼，都是針對(duì)特定場(chǎng)景或者細(xì)分領(lǐng)域的，比如運(yùn)營(yíng)的活動(dòng)頁(yè)，中后臺(tái)的表單，表格頁(yè)面等，因?yàn)橹挥性谶@些場(chǎng)景下，前端交互相對(duì)收斂，能夠沉淀出足夠多的組件物料，從而通過(guò)可視化的方式拖拽組件就能夠直接搭建出頁(yè)面。

目前我所在的團(tuán)隊(duì)正在研究面向營(yíng)銷域的中后臺(tái)前端解決方案。通常來(lái)說(shuō)，中后臺(tái)解決方案的核心目標(biāo)是提效，提效包括兩個(gè)方面，一方面是對(duì)研發(fā)人員的提效，另一方面是對(duì)用戶的提效，提效的核心抓手在于生產(chǎn)關(guān)系的變更，由前端開(kāi)發(fā)向后端，視覺(jué)，產(chǎn)品各方面參與發(fā)展，從而降低前端研發(fā)的門檻，提高生產(chǎn)效率。提效解決的不是20%的個(gè)性化增量需求，而是解決讓“非前端”參與進(jìn)來(lái)，解決80%的通用需求。中后臺(tái)的提效路徑大部分走的都是ProCode->LowCode->NoCode方式。

表面上看，從ProCode->LowCode->NoCode看起來(lái)好像只有很小的差別，好像只有代碼量多少的問(wèn)題，但整個(gè)過(guò)程已經(jīng)從量變發(fā)生了質(zhì)變。ProCode和LowCode主要面向的還是一些需要有前端編程能力的人，而NoCode則代表“非前端”也能夠參與的前端的頁(yè)面搭建中來(lái)，這里面不是說(shuō)完全不需要代碼，因?yàn)榻裉炷男┧恪按a”其實(shí)比較難界定，比如用戶編寫一個(gè)配置文件，這個(gè)文件是json格式的，那到底能不能算“代碼”？所以，NoCode的意思不是說(shuō)沒(méi)有代碼，而是說(shuō)在于用戶學(xué)習(xí)門檻和學(xué)習(xí)成本的降低，普通用戶不需要經(jīng)過(guò)艱難的學(xué)習(xí)就可以做到以前程序要編碼才能實(shí)現(xiàn)的事情。

iceluna低代碼平臺(tái)的痛點(diǎn)問(wèn)題

iceluna作為集團(tuán)內(nèi)優(yōu)秀的低代碼搭建平臺(tái)，主要解決中后臺(tái)頁(yè)面快速搭建的場(chǎng)景，經(jīng)過(guò)幾年的探索，基本能夠?qū)崿F(xiàn)頁(yè)面UI的可視化搭建，但是針對(duì)業(yè)務(wù)邏輯還是需要手動(dòng)編碼來(lái)實(shí)現(xiàn)。這對(duì)非前端開(kāi)發(fā)人員的上手門檻還是比較高的。下面這張圖是最近針對(duì)iceluna的用戶（前端，后端和測(cè)試）做的一個(gè)調(diào)研分析，可以看到邏輯代碼和數(shù)據(jù)綁定的學(xué)習(xí)成本也是用戶在問(wèn)卷中提的最多的。

可視化邏輯編排

首先我們來(lái)通過(guò)一個(gè)邏輯編排的示例來(lái)看一下如果一段代碼通過(guò)編排的方式呈現(xiàn)出來(lái)之后會(huì)帶來(lái)怎么樣的體感：

邏輯節(jié)點(diǎn)抽象

可以看出，要形成這樣的邏輯圖譜，本質(zhì)上就是需要對(duì)不同邏輯節(jié)點(diǎn)進(jìn)行組合和串聯(lián)，真正的邏輯由封裝在節(jié)點(diǎn)中的函數(shù)完成。那么這里就產(chǎn)生了兩個(gè)問(wèn)題，首先是如何抽象邏輯節(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é)來(lái)說(shuō)，可能直接寫代碼效率反而更高。

通過(guò)對(duì)中后臺(tái)營(yíng)銷域的部分業(yè)務(wù)代碼進(jìn)行梳理，發(fā)現(xiàn)中后臺(tái)的頁(yè)面大都是以表單、列表，詳情為主，而其中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，屏蔽了大部分前端語(yǔ)法層面的差異，比如狀態(tài)賦值，頁(yè)面刷新，接口調(diào)用，一些常用的工具函數(shù)（時(shí)間處理）等，為邏輯節(jié)點(diǎn)的抽象提供了極大的便利性。

編排協(xié)議

由于是可視化編排，自然也避免不了編排的協(xié)議，為了避免重復(fù)建設(shè)最大程度的復(fù)用集團(tuán)內(nèi)已有的編排方案，最終計(jì)劃采用LF通用可視化邏輯編排的協(xié)議來(lái)實(shí)現(xiàn)iceluna中的邏輯編排。

技術(shù)架構(gòu)圖

技術(shù)難點(diǎn)

自動(dòng)化布局

從一開(kāi)始調(diào)研我們就發(fā)現(xiàn)大部分的編排產(chǎn)品，都是讓用戶自己進(jìn)行拖拽，連線等操作去完成，但是通過(guò)前面對(duì)邏輯代碼的分析，如果我們將異步回調(diào)操作使用async/await的方式轉(zhuǎn)換成同步的寫法，那么邏輯代碼大部分都可以看作是一種串行式的執(zhí)行過(guò)程，偶爾疊加一些if/else的分支判斷，這樣也非常符合人們常用的思維模式，理解起來(lái)非常直觀。所以從編排的角度說(shuō)，就是將不同的邏輯節(jié)點(diǎn)和分支判斷節(jié)點(diǎn)串聯(lián)起來(lái)，布局上不需要太多的靈活性，同時(shí)連線操作也顯得比較多余，因此我們將拖拽連線全部改成添加節(jié)點(diǎn)的方式，然后自動(dòng)連線即可。

采用這種自動(dòng)布局的方式會(huì)大大簡(jiǎn)化用戶的操作，用戶只需關(guān)注核心的業(yè)務(wù)邏輯流程，按順序添加節(jié)點(diǎn)即可，但同時(shí)也帶來(lái)一個(gè)問(wèn)題，由于分支類型的節(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)的效果圖如下：

代碼與schema互轉(zhuǎn)

邏輯圖編排完成之后，緊接著面臨的問(wèn)題是如何保證編排后的邏輯正確的運(yùn)行，產(chǎn)生和源碼一樣的效果。一開(kāi)始討論的有兩種方案，第一種方案把整個(gè)邏輯看成一個(gè)事件流，按照前面設(shè)計(jì)的邏輯編排schema，通過(guò)事件注冊(cè)監(jiān)聽(tīng)的方式完成邏輯節(jié)點(diǎn)的上下游串聯(lián)，最后設(shè)計(jì)一套事件執(zhí)行器，依次觸發(fā)事件即可。這種方式實(shí)現(xiàn)起來(lái)比較簡(jiǎn)單，但是對(duì)原有開(kāi)發(fā)流程的侵入性比較強(qiáng)。因?yàn)樵斜４媸录瘮?shù)的地方都要被替換成邏輯schema，同時(shí)負(fù)責(zé)code review的前端同學(xué)看到的不再是代碼diff，而是schema的diff，這無(wú)疑會(huì)大大增加了CR的風(fēng)險(xiǎn)。因此經(jīng)過(guò)一番討論之后，我們決定采用第二種方案，將邏輯編排后的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)行解析，得到抽象語(yǔ)法樹AST，然后遍歷AST中類型為statement的節(jié)點(diǎn)，最后通過(guò)正則匹配找到對(duì)應(yīng)的邏輯節(jié)點(diǎn)，并串聯(lián)好連線即可。下圖就是生成好的一份代碼示例：

斷點(diǎn)調(diào)試

對(duì)于寫業(yè)務(wù)邏輯來(lái)說(shuō)，不可避免的需要調(diào)試功能，這對(duì)有編程能力的同學(xué)來(lái)說(shuō)是件很自然的事情，但是當(dāng)邏輯變成通過(guò)可視化的編排之后，如何讓這些”非前端“用戶也能方便的通過(guò)調(diào)試定位錯(cuò)誤，變得也尤為關(guān)鍵。

調(diào)試其實(shí)本質(zhì)上對(duì)用戶來(lái)說(shuō)，就是需要一個(gè)能夠讓編排后的邏輯模擬運(yùn)行起來(lái)的過(guò)程，因此我們對(duì)邏輯節(jié)點(diǎn)的各個(gè)環(huán)節(jié)做了埋點(diǎn)，用戶在模擬運(yùn)行的過(guò)程中就能查看每個(gè)節(jié)點(diǎn)的數(shù)據(jù)狀態(tài)、上下文參數(shù)、報(bào)錯(cuò)類型等，同時(shí)根據(jù)邏輯流程圖的狀態(tài)（綠色代表執(zhí)行成功，紅色代表執(zhí)行失敗）也能非?？焖俚亩ㄎ粏?wèn)題所在，如下圖所示：

總結(jié)展望

總結(jié)

目前，可視化邏輯編排已經(jīng)搭載集團(tuán)內(nèi)的iceluna低代碼搭建平臺(tái)正式上線，并已經(jīng)在營(yíng)銷工具業(yè)務(wù)中正式使用。從低代碼向無(wú)代碼的研發(fā)模式升級(jí)仍處在探索階段，過(guò)程中避免不了會(huì)遇到很多問(wèn)題，但也算邁出了關(guān)鍵性的一步，值得期待。

展望

前面提到，從ProCode->LowCode->NoCode，通過(guò)降低研發(fā)門檻，讓非技術(shù)人員參與到應(yīng)用開(kāi)發(fā)中來(lái)，可以大大提高生產(chǎn)效率，但理想很豐滿，現(xiàn)實(shí)也很骨感，NoCode搭建平臺(tái)我認(rèn)為目前還只能在比較垂直的場(chǎng)景中才能適用，并且由于不像LowCode一樣仍然能夠?qū)懘a的逃離機(jī)制，通過(guò)NoCode的方式可能只能完成一個(gè)70分左右的產(chǎn)品。但是換一個(gè)角度去看，如果可以讓一個(gè)非技術(shù)人員，只用很低的門檻就完成一個(gè)70分左右的產(chǎn)品(最小可用產(chǎn)品MVP)，并能直接推廣到市場(chǎng)去試錯(cuò)，如果驗(yàn)證可行，再通過(guò)轉(zhuǎn)成LowCode或者ProCode的方式繼續(xù)迭代優(yōu)化。光這一點(diǎn)我認(rèn)為就是很有價(jià)值的，是推動(dòng)商業(yè)創(chuàng)新的核心驅(qū)動(dòng)力。因此我認(rèn)為未來(lái)的產(chǎn)品研發(fā)節(jié)奏可能是從NoCode->LowCode->ProCode，每一流程都要有對(duì)應(yīng)的解決方案，并且互相之間能夠相互打通，只有這樣才能在競(jìng)爭(zhēng)日益激烈的市場(chǎng)環(huán)境下更好的生存。

歡迎關(guān)注東半球最大的前端團(tuán)隊(duì)