面向中後臺複雜場景的低程式碼實踐思路

語言: CN / TW / HK

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

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

一 中後臺前端研發複雜度背景

做中後臺前端開發,會經常碰到複雜互動和複雜邏輯問題:

你負責的業務中,規則是不是很多?是不是會不自覺的試圖用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 思路

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

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

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

  1. 狀態多難以預測和驗證:我們的解法是,要確定狀態的來源,明確狀態為什麼改變了,還要能快速驗證這個狀態的來龍去脈。
  2. 聯動多 / 條件多:我們需要一個高效的方法論指導,可以管理每個狀態的聯動及條件
  3. 技術更迭,程式碼腐化問題:如果程式碼是由規則生產出來的,那就沒有問題了

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

2 決策編排

先看一下決策編排是怎麼解決複雜條件的:

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

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

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

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

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

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

3 實踐

那麼具體的實踐是怎樣的呢?

首先,需要定義出策略編排的物件:

以表單為例,通常這些物件是表單中一個個的欄位,欄位有不同的狀態,比如可見、只讀、賦值等等,而這些都可以從後端介面定義中獲取,當然也可以自行定義。

第二步,按照決策樹編排方案,將所有物件狀態的邏輯關係、聯動關係分治、編排出來,這樣所有邏輯都成為決策樹了;

第三步,將元資料生成模擬表單。

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

最後一步,有了元資料可以生成型別定義,有了決策樹,可以生成邏輯程式碼。

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

四 總結

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

原文連結

本文為阿里雲原創內容,未經允許不得轉載。