簡介：現實中，業務場景多，疊代頻繁，變化快到跟不上，規則可能由多人掌握，無法通過一個人了解全貌； 還有業務所在行業固有的複雜度和曆史包袱，這些問題都會讓我們感到痛苦。 除了邏輯問題，我們還關注易用性互動開發的問題。
作者 | 偏左
來源 | 阿裡技術公衆号
一 中背景前端研發複雜度背景
做中背景前端開發，會經常碰到複雜互動和複雜邏輯問題：
你負責的業務中，規則是不是很多？是不是會不自覺的試圖用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個工作日就解決了這些邏輯寫作問題。
這聽起來有些不可思議，但是這種方案其實是可以高效的替代正常編碼的。
先認識下我們要面對的問題。
複雜邏輯帶來的是高驗證成本、高研發成本、邏輯黑盒以及返工風險等。
而問題的本質和解法有三點：
- 狀态多難以預測和驗證：我們的解法是，要确定狀态的來源，明确狀态為什麼改變了，還要能快速驗證這個狀态的來龍去脈。
- 關聯多 / 條件多：我們需要一個高效的方法論指導，可以管理每個狀态的關聯及條件
- 技術更疊，代碼腐化問題：如果代碼是由規則生産出來的，那就沒有問題了
綜上，複雜互動邏輯的問題，已經被轉變為了複雜條件、複雜關聯下的狀态管理問題
2 決策編排
先看一下決策編排是怎麼解決複雜條件的：
這是以ProCode實作的一個三角形類型的判斷邏輯，是一個經典的if...else嵌套結構。
這可以幾乎等價的使用流程編排方式來完成，可以看到使用這種方式，其實是沒有得到化簡的目的的，因為編排這個流程本質上跟編碼沒有差別。
如果換一種寫法，将ProCode轉為衛述句式，雖然有了一些備援，但是整體code結構變得很清楚，那這種方式，可以使用決策表來表達，也就是偏重複雜邏輯表達的方式。
通過這種決策表編排的方式，我們是可以完成複雜條件編排的，但是邏輯不僅僅是條件還有關聯，關聯是有觸發條件的，但決策表僅能描述條件關系，那麼接下來來看關聯部分是怎麼編排解決的。
這裡給出的是一個經典的關聯邏輯，可以轉換為2張等價的決策表，這裡，我們進一步将決策表轉換為等價的決策樹表示，并為決策樹辨別出了接受關聯事件的節點，這樣我們就通過決策樹同時完成了關聯及條件邏輯的編排。
再以一例來說明，這是一個貸款利率電腦：
我們将貸款類型、還款方式、貸款利率、貸款期數和累計利息作為不同的對象，将這些對象的狀态，如指派、可選值等，組織成為三顆決策樹。當貸款類型的值變更時、還款方式的可選值以及貸款利率的取值都會發生變化，點選計算時，手動調用第三顆決策樹計算出結果。
以上就是通過決策樹的編排來解決複雜邏輯問題的方案思路。
3 實踐
那麼具體的實踐是怎樣的呢？
首先，需要定義出政策編排的對象：
以表單為例，通常這些對象是表單中一個個的字段，字段有不同的狀态，比如可見、隻讀、指派等等，而這些都可以從後端接口定義中擷取，當然也可以自行定義。
第二步，按照決策樹編排方案，将所有對象狀态的邏輯關系、關聯關系分治、編排出來，這樣所有邏輯都成為決策樹了；
第三步，将中繼資料生成模拟表單。
這樣我們可以實時的驗證出決策樹中的狀态是否符合預期；而政策規則也可以轉換為測試用例腦圖，友善看到各個邏輯case。
最後一步，有了中繼資料可以生成類型定義，有了決策樹，可以生成邏輯代碼。
這兩樣相結合，我們可以得到非常專業注釋詳細的代碼，這份代碼可以托管在git倉庫擁有高延續性，也可以直接編譯直接執行，或者釋出到npm/cdn被各個業務引用，甚至可以作為api跨越技術棧。
四 總結
再回頭去看兩個方案，一個是面向複雜互動，另一個是面向複雜邏輯，其實這兩個問題每個都能單獨拿出來深入去聊，聯系并不那麼緊密，而在實踐上也确是被分為兩個平台去單獨求解，割裂感比較重，無法為同一個業務提供統一的解決方案。是以接下來，我們打算是尋求一種方式能夠将兩種方案結合起來，作為一個整體去服務同一個業務。
原文連結
本文為阿裡雲原創内容，未經允許不得轉載。