無代碼解決方案：如何完全實現無代碼化研發模式

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

低代碼和無代碼

首先無論是低代碼仍是無代碼，都是針對特定場景或者細分領域的，好比運營的活動頁，中後臺的表單，表格頁面等，由於只有在這些場景下，前端交互相對收斂，可以沉澱出足夠多的組件物料，從而經過可視化的方式拖拽組件就可以直接搭建出頁面。

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

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

iceluna低代碼平臺的痛點問題

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

所以在這個財年，咱們嘗試去用可視化邏輯編排的方式解決邏輯相關的問題，解決低代碼中最後一點須要編碼的部分，實現無代碼化的研發模式，從而進一步下降用戶的學習和使用門檻。

可視化邏輯編排

首先咱們來經過一個邏輯編排的示例來看一下若是一段代碼經過編排的方式呈現出來以後會帶來怎麼樣的體感：

如上圖所示，本來晦澀難懂的代碼邏輯經過流程圖的形式表達出來之後，產品的邏輯變得很是直觀。可讀性和可維護性也變得很是高。不再用擔憂在接手其餘人的項目時，註釋不規範，文檔不全的問題，邏輯編排生成的邏輯圖譜就是自然的產品文檔。

邏輯節點抽象

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

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

經過分析歸類，最後沉澱了10個左右的邏輯節點，以下圖所示，同時每個邏輯節點最終本質上都是對應一段執行函數，並接收一個參數做爲入參，返回一個參數做爲出參。

編排協議

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

技術架構圖

技術難點

自動化佈局

從一開始調研咱們就發現大部分的編排產品，都是讓用戶本身進行拖拽，連線等操做去完成，可是經過前面對邏輯代碼的分析，若是咱們將異步回調操做使用async/await的方式轉換成同步的寫法，那麼邏輯代碼大部分均可以看做是一種串行式的執行過程，偶爾疊加一些if/else的分支判斷，這樣也很是符合人們經常使用的思惟模式，理解起來很是直觀。因此從編排的角度說，就是將不一樣的邏輯節點和分支判斷節點串聯起來，佈局上不須要太多的靈活性，同時連線操做也顯得比較多餘，所以咱們將拖拽連線所有改爲添加節點的方式，而後自動連線便可。

採用這種自動佈局的方式會大大簡化用戶的操做，用戶只需關注核心的業務邏輯流程，按順序添加節點便可，但同時也帶來一個問題，因爲分支類型的節點會產生兩個分支流，若是遇到嵌套分支的狀況下，須要自動將上層分支的橫座標的位置統一貫右偏移一個單位，不然處在上下層不一樣分支上的節點位置可能會產生重疊。爲此，我設計了一自動佈局算法，最終實現的效果圖以下：

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

代碼與schema互轉

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

基於schema轉成代碼是比較容易的，由於每一個邏輯節點自己就映射了一段函數片斷，而將代碼轉回schema則稍微有些複雜。這裏主要利用了Babel先對代碼進行解析，獲得抽象語法樹AST，而後遍歷AST中類型爲statement的節點，最後經過正則匹配找到對應的邏輯節點，並串聯好連線便可。下圖就是生成好的一份代碼示例：

能夠看出，經過schema生成後的代碼與源碼編寫仍是有一點區別，帶有一些邏輯編排的特徵，可是可讀性更強，從代碼基本也能直觀的反推出邏輯流程圖，反而從必定程度上下降了code review的成本。整個AST解析的過程以下：

斷點調試

對於寫業務邏輯來講，不可避免的須要調試功能，這對有編程能力的同窗來講是件很天然的事情，可是當邏輯變成經過可視化的編排以後，如何讓這些」非前端「用戶也能方便的經過調試定位錯誤，變得也尤其關鍵。

調試其實本質上對用戶來講，就是須要一個可以讓編排後的邏輯模擬運行起來的過程，所以咱們對邏輯節點的各個環節作了埋點，用戶在模擬運行的過程當中就能查看每一個節點的數據狀態、上下文參數、報錯類型等，同時根據邏輯流程圖的狀態（綠色表明執行成功，紅色表明執行失敗）也能很是快速的定位問題所在，以下圖所示：

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

總結展望

總結

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

展望

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

• 做者：凌乙