簡介：現實中，業務場景多，迭代頻繁，變化快到跟不上，規則可能由多人掌握，無法通過一個人了解全貌； 還有業務所在行業固有的復雜度和歷史包袱，這些問題都會讓我們感到痛苦。 除了邏輯問題，我們還關注易用性交互開發的問題。

作者 | 偏左
來源 | 阿里技術公眾號

一 中后臺前端研發復雜度背景

做中后臺前端開發，會經常碰到復雜交互和復雜邏輯問題：

你負責的業務中，規則是不是很多？是不是會不自覺的試圖用if...else解決一切問題，邏輯是不是在迭代過程中變得越來越亂？最后徹底變成一個看不懂改不動的黑盒子，沒有人能搞清楚黑盒子里面到底發生了什么。

現實中，業務場景多，迭代頻繁，變化快到跟不上，規則可能由多人掌握，無法通過一個人了解全貌；

還有業務所在行業固有的復雜度和歷史包袱，這些問題都會讓我們感到痛苦。

除了邏輯問題，我們還關注易用性交互開發的問題。

試想，在中后臺系統中，沒有說明、沒有指引，那該有多難用？所以通過內容運營，增加指引提升易用性是十分必要的，但對于前端開發來說，又像是下了一道魔咒。為什么這么說呢？

易用性交互的形式很多，不但會放大整體功能開發難度，而且很容易干擾到業務功能，讓本來已經很復雜的開發工作更加復雜，加速了整體腐化。

本身排期就已經低于功能需求了，再加上這些問題，導致大家都不愛去做，長此下去，平臺越來越難用。

那么問題逐漸顯現，如何面對中后臺復雜場景中最深刻的兩個問題：即復雜交互、復雜邏輯。

二 復雜交互解法

1 思路

首先是使用動態標注生成交互界面，來解決復雜交互問題：

這是一個典型的后臺功能配置頁：這里面有列表有詳情，加入了很多指引。這里相當一部分交互的繁瑣編碼工作，其實是以一種簡潔高效的低代碼方式去解決的。

首先我們需要把頁面劃分為業務功能交互以及輔助內容交互，所謂業務功能交互，即脫離了這部分交互業務就不再完整了，而輔助內容交互則是沒有這部分交互系統也能用，但是可能會很難用。

那么我們方案的核心目標就是：將業務功能交互，還是由前端通過procode開發完成，而這些輔助內容交互，就可以由低代碼配置去完成了。

想法比較直接，那么真實的效果如何呢？

這是一個比較復雜的配置頁，使用了大量引導類交互，有點擊出現彈窗、查看文檔、還有各種加下劃線氣泡、stepbystep引導、還有更過分的要加復雜流程圖、這是SVG做的，圖里面還要帶有氣泡按鈕解釋的，等等，像這種交互在系統中有近400個，如果把這些寫在代碼里面，是一個非常大的負擔，而這些，我們都是通過低代碼配置化去解決的。

2 實踐

接下來是實戰部分：

第一步，我們要找到輔助類的交互，哪些是必須要procode的業務關鍵能力，哪些是非必須的。在我們的實踐經驗中，像這些輔助類交互都是可以抽象成組件復用的。

第二步，我們將這些組件，通過動態標注的方式，渲染到界面上。

關鍵流程可以描述為，首先捕捉用戶的行為，如元素點擊、移入移出，或是節點生成、銷毀、或是URL改變了等等。

當匹配這些行為時，找到組件插入或更新的位置，然后渲染出來，這個時候組件會按預設的規則動態的標注到頁面指定位置上。

比如，當用戶進入某個頁面時（行為是URL改變），我們給指定區域（可能是一個選擇器指定的），插入一張流程圖。

第三步，這些組件可能互相之間是有交互的，比如點擊問號按鈕的時候出現彈窗，點擊好用不好用的時候要感謝反饋等等，這個我們是通過一種自定義協議的url來完成的，這里給出了一些例子來展示下我們正在使用的動作，如：

向機器人提問、提交工單、顯示消息、打開彈窗、復制內容等等

通過給組件配置url來完成不同的動作

這樣就完成整個易用性交互的標注和動作過程。

3 相關問題

那么問題來了，現在都是一些動態渲染技術，狀態變了那么頁面結構可能也變了呀，那組件也丟失了。沒有關系，當DOM變化的時候，我們仍然是在監聽的，只要檢測到DOM樹變化或關鍵屬性變化，我們就重新執行一次渲染。

第二個問題是，這些規則都太專業了，CSS選擇器、XPath，這些對于非技術同學來說使用成本非常高，而且可能因為一個很小的頁面改動就會導致配置失效。

這類問題我們的實踐方案是，可以通過視覺特征的相似度去做模糊匹配，使用者只要去勾選出相應的特征和偏差范圍，就可以自動生成腳本去做匹配，這里我們是通過擴展了XQuery形成了自己的模糊查詢方式。

4 復雜交互動作

標注的問題解決了，但是復雜的交互動作怎么做呢？這里有個例子說明一下：

試想一個場景，一個系統，對于新用戶、老用戶，需要有不同的引導方式

新用戶場景下，首先提示用戶，歡迎使用新手引導，2秒后，展示新手引導彈窗；

而老用戶場景下，僅提示用戶，歡迎查看常見問題，當點擊常見問題時，向機器人發問獲取知識；

在每個環節中，我們都是通過url來產生動作，但是怎么串起來呢？

在我們的定義中，url可以被串聯順序執行，也可以加上@if，條件執行，還可以加上@delay延時執行，這樣就可以將所有一系列的url組織成一個url，并在兩種場景去分別觸發。

三 復雜邏輯解法

接下來要面對更難的一個問題，復雜邏輯，通過策略編排生成邏輯代碼。

方案的核心目標，是將所有的交互邏輯從ProCode開發，轉為低/無代碼配置，但這個核心目標的前提并不是要用低代碼來替代procode，而是因為procode寫復雜邏輯很難，所以要使用簡單的低代碼實現。

在我們實際業務的實踐中有一例典型的高復雜度表單，一個表單三種場景，每種場景的各個字段都有聯系，一共有33個狀態，82條邏輯規則。當時是以procode開發，到第5個工作日時就因為各種錯漏返工無法繼續了，而轉用策略編排，我們用了近2個工作日就解決了這些邏輯寫作問題。

這聽起來有些不可思議，但是這種方案其實是可以高效的替代常規編碼的。

1 思路

先認識下我們要面對的問題。

復雜邏輯帶來的是高驗證成本、高研發成本、邏輯黑盒以及返工風險等。

而問題的本質和解法有三點：

狀態多難以預測和驗證：我們的解法是，要確定狀態的來源，明確狀態為什么改變了，還要能快速驗證這個狀態的來龍去脈。

聯動多 / 條件多：我們需要一個高效的方法論指導，可以管理每個狀態的聯動及條件

技術更迭，代碼腐化問題：如果代碼是由規則生產出來的，那就沒有問題了

綜上，復雜交互邏輯的問題，已經被轉變為了復雜條件、復雜聯動下的狀態管理問題

2 決策編排

先看一下決策編排是怎么解決復雜條件的：

這是以ProCode實現的一個三角形類型的判斷邏輯，是一個經典的if...else嵌套結構。
這可以幾乎等價的使用流程編排方式來完成，可以看到使用這種方式，其實是沒有得到化簡的目的的，因為編排這個流程本質上跟編碼沒有區別。

如果換一種寫法，將ProCode轉為衛述句式，雖然有了一些冗余，但是整體code結構變得很清楚，那這種方式，可以使用決策表來表達，也就是偏重復雜邏輯表達的方式。
通過這種決策表編排的方式，我們是可以完成復雜條件編排的，但是邏輯不僅僅是條件還有聯動，聯動是有觸發條件的，但決策表僅能描述條件關系，那么接下來來看聯動部分是怎么編排解決的。

這里給出的是一個經典的聯動邏輯，可以轉換為2張等價的決策表，這里，我們進一步將決策表轉換為等價的決策樹表示，并為決策樹標識出了接受聯動事件的節點，這樣我們就通過決策樹同時完成了聯動及條件邏輯的編排。

再以一例來說明，這是一個貸款利率計算器：

我們將貸款類型、還款方式、貸款利率、貸款期數和累計利息作為不同的對象，將這些對象的狀態，如賦值、可選值等，組織成為三顆決策樹。當貸款類型的值變更時、還款方式的可選值以及貸款利率的取值都會發生變化，點擊計算時，手動調用第三顆決策樹計算出結果。

以上就是通過決策樹的編排來解決復雜邏輯問題的方案思路。

3 實踐

那么具體的實踐是怎樣的呢？

首先，需要定義出策略編排的對象：

以表單為例，通常這些對象是表單中一個個的字段，字段有不同的狀態，比如可見、只讀、賦值等等，而這些都可以從后端接口定義中獲取，當然也可以自行定義。

第二步，按照決策樹編排方案，將所有對象狀態的邏輯關系、聯動關系分治、編排出來，這樣所有邏輯都成為決策樹了；

第三步，將元數據生成模擬表單。

這樣我們可以實時的驗證出決策樹中的狀態是否符合預期；而策略規則也可以轉換為測試用例腦圖，方便看到各個邏輯case。

最后一步，有了元數據可以生成類型定義，有了決策樹，可以生成邏輯代碼。

這兩樣相結合，我們可以得到非常專業注釋詳細的代碼，這份代碼可以托管在git倉庫擁有高延續性，也可以直接編譯直接執行，或者發布到npm/cdn被各個業務引用，甚至可以作為api跨越技術棧。

四 總結

再回頭去看兩個方案，一個是面向復雜交互，另一個是面向復雜邏輯，其實這兩個問題每個都能單獨拿出來深入去聊，聯系并不那么緊密，而在實踐上也確是被分為兩個平臺去單獨求解，割裂感比較重，無法為同一個業務提供統一的解決方案。所以接下來，我們打算是尋求一種方式能夠將兩種方案結合起來，作為一個整體去服務同一個業務。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的面向中后台复杂场景的低代码实践思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。