導(dǎo)語(yǔ)：現(xiàn)實(shí)中，業(yè)務(wù)場(chǎng)景多，迭代頻繁，變化快到跟不上，規(guī)則可能由多人掌握，無(wú)法通過(guò)一個(gè)人了解全貌；還有業(yè)務(wù)所在行業(yè)固有的復(fù)雜度和歷史包袱，這些問(wèn)題都會(huì)讓我們感到痛苦。除了邏輯問(wèn)題，我們還關(guān)注易用性交互開(kāi)發(fā)的問(wèn)題。

一 中后臺(tái)前端研發(fā)復(fù)雜度背景

做中后臺(tái)前端開(kāi)發(fā)，會(huì)經(jīng)常碰到復(fù)雜交互和復(fù)雜邏輯問(wèn)題：

你負(fù)責(zé)的業(yè)務(wù)中，規(guī)則是不是很多？是不是會(huì)不自覺(jué)的試圖用if...else解決一切問(wèn)題，邏輯是不是在迭代過(guò)程中變得越來(lái)越亂？最后徹底變成一個(gè)看不懂改不動(dòng)的黑盒子，沒(méi)有人能搞清楚黑盒子里面到底發(fā)生了什么。

現(xiàn)實(shí)中，業(yè)務(wù)場(chǎng)景多，迭代頻繁，變化快到跟不上，規(guī)則可能由多人掌握，無(wú)法通過(guò)一個(gè)人了解全貌；

還有業(yè)務(wù)所在行業(yè)固有的復(fù)雜度和歷史包袱，這些問(wèn)題都會(huì)讓我們感到痛苦。

除了邏輯問(wèn)題，我們還關(guān)注易用性交互開(kāi)發(fā)的問(wèn)題。

試想，在中后臺(tái)系統(tǒng)中，沒(méi)有說(shuō)明、沒(méi)有指引，那該有多難用？所以通過(guò)內(nèi)容運(yùn)營(yíng)，增加指引提升易用性是十分必要的，但對(duì)于前端開(kāi)發(fā)來(lái)說(shuō)，又像是下了一道魔咒。為什么這么說(shuō)呢？

易用性交互的形式很多，不但會(huì)放大整體功能開(kāi)發(fā)難度，而且很容易干擾到業(yè)務(wù)功能，讓本來(lái)已經(jīng)很復(fù)雜的開(kāi)發(fā)工作更加復(fù)雜，加速了整體腐化。

本身排期就已經(jīng)低于功能需求了，再加上這些問(wèn)題，導(dǎo)致大家都不愛(ài)去做，長(zhǎng)此下去，平臺(tái)越來(lái)越難用。

那么問(wèn)題逐漸顯現(xiàn)，如何面對(duì)中后臺(tái)復(fù)雜場(chǎng)景中最深刻的兩個(gè)問(wèn)題：即復(fù)雜交互、復(fù)雜邏輯。

二 復(fù)雜交互解法

1 思路

首先是使用動(dòng)態(tài)標(biāo)注生成交互界面，來(lái)解決復(fù)雜交互問(wèn)題：

這是一個(gè)典型的后臺(tái)功能配置頁(yè)：這里面有列表有詳情，加入了很多指引。這里相當(dāng)一部分交互的繁瑣編碼工作，其實(shí)是以一種簡(jiǎn)潔高效的低代碼方式去解決的。

首先我們需要把頁(yè)面劃分為業(yè)務(wù)功能交互以及輔助內(nèi)容交互，所謂業(yè)務(wù)功能交互，即脫離了這部分交互業(yè)務(wù)就不再完整了，而輔助內(nèi)容交互則是沒(méi)有這部分交互系統(tǒng)也能用，但是可能會(huì)很難用。

那么我們方案的核心目標(biāo)就是：將業(yè)務(wù)功能交互，還是由前端通過(guò)procode開(kāi)發(fā)完成，而這些輔助內(nèi)容交互，就可以由低代碼配置去完成了。

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

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

2 實(shí)踐

接下來(lái)是實(shí)戰(zhàn)部分：

第一步，我們要找到輔助類的交互，哪些是必須要procode的業(yè)務(wù)關(guān)鍵能力，哪些是非必須的。在我們的實(shí)踐經(jīng)驗(yàn)中，像這些輔助類交互都是可以抽象成組件復(fù)用的。

第二步，我們將這些組件，通過(guò)動(dòng)態(tài)標(biāo)注的方式，渲染到界面上。

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

當(dāng)匹配這些行為時(shí)，找到組件插入或更新的位置，然后渲染出來(lái)，這個(gè)時(shí)候組件會(huì)按預(yù)設(shè)的規(guī)則動(dòng)態(tài)的標(biāo)注到頁(yè)面指定位置上。

比如，當(dāng)用戶進(jìn)入某個(gè)頁(yè)面時(shí)（行為是URL改變），我們給指定區(qū)域（可能是一個(gè)選擇器指定的），插入一張流程圖。

第三步，這些組件可能互相之間是有交互的，比如點(diǎn)擊問(wèn)號(hào)按鈕的時(shí)候出現(xiàn)彈窗，點(diǎn)擊好用不好用的時(shí)候要感謝反饋等等，這個(gè)我們是通過(guò)一種自定義協(xié)議的url來(lái)完成的，這里給出了一些例子來(lái)展示下我們正在使用的動(dòng)作，如：

向機(jī)器人提問(wèn)、提交工單、顯示消息、打開(kāi)彈窗、復(fù)制內(nèi)容等等

通過(guò)給組件配置url來(lái)完成不同的動(dòng)作

這樣就完成整個(gè)易用性交互的標(biāo)注和動(dòng)作過(guò)程。

3 相關(guān)問(wèn)題

那么問(wèn)題來(lái)了，現(xiàn)在都是一些動(dòng)態(tài)渲染技術(shù)，狀態(tài)變了那么頁(yè)面結(jié)構(gòu)可能也變了呀，那組件也丟失了。沒(méi)有關(guān)系，當(dāng)DOM變化的時(shí)候，我們?nèi)匀皇窃诒O(jiān)聽(tīng)的，只要檢測(cè)到DOM樹(shù)變化或關(guān)鍵屬性變化，我們就重新執(zhí)行一次渲染。

第二個(gè)問(wèn)題是，這些規(guī)則都太專業(yè)了，CSS選擇器、XPath，這些對(duì)于非技術(shù)同學(xué)來(lái)說(shuō)使用成本非常高，而且可能因?yàn)橐粋€(gè)很小的頁(yè)面改動(dòng)就會(huì)導(dǎo)致配置失效。

這類問(wèn)題我們的實(shí)踐方案是，可以通過(guò)視覺(jué)特征的相似度去做模糊匹配，使用者只要去勾選出相應(yīng)的特征和偏差范圍，就可以自動(dòng)生成腳本去做匹配，這里我們是通過(guò)擴(kuò)展了XQuery形成了自己的模糊查詢方式。

4 復(fù)雜交互動(dòng)作

標(biāo)注的問(wèn)題解決了，但是復(fù)雜的交互動(dòng)作怎么做呢？這里有個(gè)例子說(shuō)明一下：

試想一個(gè)場(chǎng)景，一個(gè)系統(tǒng)，對(duì)于新用戶、老用戶，需要有不同的引導(dǎo)方式

而老用戶場(chǎng)景下，僅提示用戶，歡迎查看常見(jiàn)問(wèn)題，當(dāng)點(diǎn)擊常見(jiàn)問(wèn)題時(shí)，向機(jī)器人發(fā)問(wèn)獲取知識(shí)；

在每個(gè)環(huán)節(jié)中，我們都是通過(guò)url來(lái)產(chǎn)生動(dòng)作，但是怎么串起來(lái)呢？

在我們的定義中，url可以被串聯(lián)順序執(zhí)行，也可以加上@if，條件執(zhí)行，還可以加上@delay延時(shí)執(zhí)行，這樣就可以將所有一系列的url組織成一個(gè)url，并在兩種場(chǎng)景去分別觸發(fā)。

而老用戶場(chǎng)景下，僅提示用戶，歡迎查看常見(jiàn)問(wèn)題，當(dāng)點(diǎn)擊常見(jiàn)問(wèn)題時(shí)，向機(jī)器人發(fā)問(wèn)獲取知識(shí)；

在每個(gè)環(huán)節(jié)中，我們都是通過(guò)url來(lái)產(chǎn)生動(dòng)作，但是怎么串起來(lái)呢？

在我們的定義中，url可以被串聯(lián)順序執(zhí)行，也可以加上@if，條件執(zhí)行，還可以加上@delay延時(shí)執(zhí)行，這樣就可以將所有一系列的url組織成一個(gè)url，并在兩種場(chǎng)景去分別觸發(fā)。

三 復(fù)雜邏輯解法

接下來(lái)要面對(duì)更難的一個(gè)問(wèn)題，復(fù)雜邏輯，通過(guò)策略編排生成邏輯代碼。

方案的核心目標(biāo)，是將所有的交互邏輯從ProCode開(kāi)發(fā)，轉(zhuǎn)為低/無(wú)代碼配置，但這個(gè)核心目標(biāo)的前提并不是要用低代碼來(lái)替代procode，而是因?yàn)閜rocode寫復(fù)雜邏輯很難，所以要使用簡(jiǎn)單的低代碼實(shí)現(xiàn)。

在我們實(shí)際業(yè)務(wù)的實(shí)踐中有一例典型的高復(fù)雜度表單，一個(gè)表單三種場(chǎng)景，每種場(chǎng)景的各個(gè)字段都有聯(lián)系，一共有33個(gè)狀態(tài)，82條邏輯規(guī)則。當(dāng)時(shí)是以procode開(kāi)發(fā)，到第5個(gè)工作日時(shí)就因?yàn)楦鞣N錯(cuò)漏返工無(wú)法繼續(xù)了，而轉(zhuǎn)用策略編排，我們用了近2個(gè)工作日就解決了這些邏輯寫作問(wèn)題。

這聽(tīng)起來(lái)有些不可思議，但是這種方案其實(shí)是可以高效的替代常規(guī)編碼的。

1 思路

先認(rèn)識(shí)下我們要面對(duì)的問(wèn)題。

復(fù)雜邏輯帶來(lái)的是高驗(yàn)證成本、高研發(fā)成本、邏輯黑盒以及返工風(fēng)險(xiǎn)等。

而問(wèn)題的本質(zhì)和解法有三點(diǎn)：

1.狀態(tài)多難以預(yù)測(cè)和驗(yàn)證：我們的解法是，要確定狀態(tài)的來(lái)源，明確狀態(tài)為什么改變了，還要能快速驗(yàn)證這個(gè)狀態(tài)的來(lái)龍去脈。

2.聯(lián)動(dòng)多 / 條件多：我們需要一個(gè)高效的方法論指導(dǎo)，可以管理每個(gè)狀態(tài)的聯(lián)動(dòng)及條件

3.技術(shù)更迭，代碼腐化問(wèn)題：如果代碼是由規(guī)則生產(chǎn)出來(lái)的，那就沒(méi)有問(wèn)題了

綜上，復(fù)雜交互邏輯的問(wèn)題，已經(jīng)被轉(zhuǎn)變?yōu)榱藦?fù)雜條件、復(fù)雜聯(lián)動(dòng)下的狀態(tài)管理問(wèn)題

2 決策編排

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

這是以ProCode實(shí)現(xiàn)的一個(gè)三角形類型的判斷邏輯，是一個(gè)經(jīng)典的if...else嵌套結(jié)構(gòu)。

這可以幾乎等價(jià)的使用流程編排方式來(lái)完成，可以看到使用這種方式，其實(shí)是沒(méi)有得到化簡(jiǎn)的目的的，因?yàn)榫幣胚@個(gè)流程本質(zhì)上跟編碼沒(méi)有區(qū)別。

如果換一種寫法，將ProCode轉(zhuǎn)為衛(wèi)述句式，雖然有了一些冗余，但是整體code結(jié)構(gòu)變得很清楚，那這種方式，可以使用決策表來(lái)表達(dá)，也就是偏重復(fù)雜邏輯表達(dá)的方式。

通過(guò)這種決策表編排的方式，我們是可以完成復(fù)雜條件編排的，但是邏輯不僅僅是條件還有聯(lián)動(dòng)，聯(lián)動(dòng)是有觸發(fā)條件的，但決策表僅能描述條件關(guān)系，那么接下來(lái)來(lái)看聯(lián)動(dòng)部分是怎么編排解決的。

這里給出的是一個(gè)經(jīng)典的聯(lián)動(dòng)邏輯，可以轉(zhuǎn)換為2張等價(jià)的決策表，這里，我們進(jìn)一步將決策表轉(zhuǎn)換為等價(jià)的決策樹(shù)表示，并為決策樹(shù)標(biāo)識(shí)出了接受聯(lián)動(dòng)事件的節(jié)點(diǎn)，這樣我們就通過(guò)決策樹(shù)同時(shí)完成了聯(lián)動(dòng)及條件邏輯的編排。

再以一例來(lái)說(shuō)明，這是一個(gè)貸款利率計(jì)算器：

我們將貸款類型、還款方式、貸款利率、貸款期數(shù)和累計(jì)利息作為不同的對(duì)象，將這些對(duì)象的狀態(tài)，如賦值、可選值等，組織成為三顆決策樹(shù)。當(dāng)貸款類型的值變更時(shí)、還款方式的可選值以及貸款利率的取值都會(huì)發(fā)生變化，點(diǎn)擊計(jì)算時(shí)，手動(dòng)調(diào)用第三顆決策樹(shù)計(jì)算出結(jié)果。

以上就是通過(guò)決策樹(shù)的編排來(lái)解決復(fù)雜邏輯問(wèn)題的方案思路。

3 實(shí)踐

那么具體的實(shí)踐是怎樣的呢？

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

以表單為例，通常這些對(duì)象是表單中一個(gè)個(gè)的字段，字段有不同的狀態(tài)，比如可見(jiàn)、只讀、賦值等等，而這些都可以從后端接口定義中獲取，當(dāng)然也可以自行定義。

第二步，按照決策樹(shù)編排方案，將所有對(duì)象狀態(tài)的邏輯關(guān)系、聯(lián)動(dòng)關(guān)系分治、編排出來(lái)，這樣所有邏輯都成為決策樹(shù)了；

第三步，將元數(shù)據(jù)生成模擬表單。

這樣我們可以實(shí)時(shí)的驗(yàn)證出決策樹(shù)中的狀態(tài)是否符合預(yù)期；而策略規(guī)則也可以轉(zhuǎn)換為測(cè)試用例腦圖，方便看到各個(gè)邏輯case。

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

這兩樣相結(jié)合，我們可以得到非常專業(yè)注釋詳細(xì)的代碼，這份代碼可以托管在git倉(cāng)庫(kù)擁有高延續(xù)性，也可以直接編譯直接執(zhí)行，或者發(fā)布到npm/cdn被各個(gè)業(yè)務(wù)引用，甚至可以作為api跨越技術(shù)棧。

四 總結(jié)

再回頭去看兩個(gè)方案，一個(gè)是面向復(fù)雜交互，另一個(gè)是面向復(fù)雜邏輯，其實(shí)這兩個(gè)問(wèn)題每個(gè)都能單獨(dú)拿出來(lái)深入去聊，聯(lián)系并不那么緊密，而在實(shí)踐上也確是被分為兩個(gè)平臺(tái)去單獨(dú)求解，割裂感比較重，無(wú)法為同一個(gè)業(yè)務(wù)提供統(tǒng)一的解決方案。所以接下來(lái)，我們打算是尋求一種方式能夠?qū)煞N方案結(jié)合起來(lái)，作為一個(gè)整體去服務(wù)同一個(gè)業(yè)務(wù)。