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

低代碼和無代碼

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

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

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

iceluna低代碼平臺的痛點問題

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

可視化邏輯編排

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

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

邏輯節點抽象

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

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

編排協議

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

技術架構圖

技術難點

自動化布局

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

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

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

代碼與schema互轉

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

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

斷點調試

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

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

目前調試功能還處在初級階段，后面還會持續迭代優化，比如調試時增加單步執行功能，像瀏覽器的單步調試工具一樣進行斷點。

總結展望

總結

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

展望

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