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

低代碼和無代碼

首先不管是低代碼還是無代碼，都是針對特定場景或者細分領(lǐng)域的，比如運營的活動頁，中后臺的表單，表格頁面等，因為只有在這些場景下，前端交互相對收斂，能夠沉淀出足夠多的組件物料，從而通過可視化的方式拖拽組件就能夠直接搭建出頁面。

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

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

iceluna低代碼平臺的痛點問題

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

可視化邏輯編排

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

如上圖所示，原本晦澀難懂的代碼邏輯通過流程圖的形式表達出來以后，產(chǎn)品的邏輯變得非常直觀。可讀性和可維護性也變得非常高。再也不用擔心在接手其他人的項目時，注釋不規(guī)范，文檔不全的問題，邏輯編排生成的邏輯圖譜就是天然的產(chǎn)品文檔。

邏輯節(jié)點抽象

可以看出，要形成這樣的邏輯圖譜，本質(zhì)上就是需要對不同邏輯節(jié)點進行組合和串聯(lián)，真正的邏輯由封裝在節(jié)點中的函數(shù)完成。那么這里就產(chǎn)生了兩個問題，首先是如何抽象邏輯節(jié)點，抽象出的邏輯節(jié)點能不能被復用直接決定了用戶編排的成本，如果需要不斷的定制個性化邏輯節(jié)點可能就失去了編排的意義；其次是邏輯節(jié)點的的顆粒度大小也非常關(guān)鍵，如果封裝的邏輯顆粒度太大，大到一個功能服務(wù)，那么可能就變成了業(yè)務(wù)流程編排；如果顆粒度太小，小到一個表達式級別，那么對于有編程基礎(chǔ)的同學來說，可能直接寫代碼效率反而更高。

通過對中后臺營銷域的部分業(yè)務(wù)代碼進行梳理，發(fā)現(xiàn)中后臺的頁面大都是以表單、列表，詳情為主，而其中90%的業(yè)務(wù)邏輯基本上都圍繞在表單(校驗，取值，賦值，提交)，對話框（顯隱、提示），發(fā)送請求，消息提示，數(shù)據(jù)處理，路由跳轉(zhuǎn)，條件判斷等，相對比較收斂。同時iceluna作為集團內(nèi)優(yōu)秀的低代碼搭建平臺，在上層封裝了很多非常好用的api，屏蔽了大部分前端語法層面的差異，比如狀態(tài)賦值，頁面刷新，接口調(diào)用，一些常用的工具函數(shù)（時間處理）等，為邏輯節(jié)點的抽象提供了極大的便利性。

編排協(xié)議

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

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

技術(shù)難點

自動化布局

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

采用這種自動布局的方式會大大簡化用戶的操作，用戶只需關(guān)注核心的業(yè)務(wù)邏輯流程，按順序添加節(jié)點即可，但同時也帶來一個問題，由于分支類型的節(jié)點會產(chǎn)生兩個分支流，如果遇到嵌套分支的情況下，需要自動將上層分支的橫坐標的位置統(tǒng)一向右偏移一個單位，否則處在上下層不同分支上的節(jié)點位置可能會產(chǎn)生重疊。為此，我設(shè)計了一自動布局算法，最終實現(xiàn)的效果圖如下：

算法過程比較簡單，采用的是DFS深度優(yōu)先遍歷算法，詳細過程這里就不再贅述。

代碼與schema互轉(zhuǎn)

邏輯圖編排完成之后，緊接著面臨的問題是如何保證編排后的邏輯正確的運行，產(chǎn)生和源碼一樣的效果。一開始討論的有兩種方案，第一種方案把整個邏輯看成一個事件流，按照前面設(shè)計的邏輯編排schema，通過事件注冊監(jiān)聽的方式完成邏輯節(jié)點的上下游串聯(lián)，最后設(shè)計一套事件執(zhí)行器，依次觸發(fā)事件即可。這種方式實現(xiàn)起來比較簡單，但是對原有開發(fā)流程的侵入性比較強。因為原有保存事件函數(shù)的地方都要被替換成邏輯schema，同時負責code review的前端同學看到的不再是代碼diff，而是schema的diff，這無疑會大大增加了CR的風險。因此經(jīng)過一番討論之后，我們決定采用第二種方案，將邏輯編排后的schema自動轉(zhuǎn)成代碼，同時生成后的代碼也要能夠自動轉(zhuǎn)回schema。

基于schema轉(zhuǎn)成代碼是比較容易的，因為每個邏輯節(jié)點本身就映射了一段函數(shù)片段，而將代碼轉(zhuǎn)回schema則稍微有些復雜。這里主要利用了Babel先對代碼進行解析，得到抽象語法樹AST，然后遍歷AST中類型為statement的節(jié)點，最后通過正則匹配找到對應(yīng)的邏輯節(jié)點，并串聯(lián)好連線即可。下圖就是生成好的一份代碼示例：

斷點調(diào)試

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

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

目前調(diào)試功能還處在初級階段，后面還會持續(xù)迭代優(yōu)化，比如調(diào)試時增加單步執(zhí)行功能，像瀏覽器的單步調(diào)試工具一樣進行斷點。

總結(jié)展望

總結(jié)

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

展望

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