之前總聊微服務，今天換一個話題---低代碼。低代碼這個詞也是最近這幾年很火的概念，尤其是遇到大環境下行，很多大廠和互聯網那個公司也在慢慢在低代碼方向發力，當然，對於傳統項目交付型的軟體公司，低代碼也具有相當大的吸引力。 ...
之前總聊微服務，今天換一個話題---低代碼。
低代碼這個詞也是最近這幾年很火的概念，尤其是遇到大環境下行，很多大廠和互聯網那個公司也在慢慢在低代碼方向發力，當然，對於傳統項目交付型的軟體公司，低代碼也具有相當大的吸引力。
如何理解低代碼
用一個通俗易懂的說法，就是少寫代碼，並且降低開發門檻的方式，可以讓平民開發者（可以理解為並不一定具有軟體技術素質的人員）也能高效快速的構建應用程式。
如果基於這個思路，是不是大家覺得有一些類比？
當電腦剛起步的時候，大家還用打孔卡片來跑程式的時候，這時候一個牛逼的彙編語言可以說就是那個時代的低代碼；再到後來C語言的普及，那對於彙編語言來說，C語言簡直就是低代碼…..以此類比，在我們這個時代，當面向對象的開發語言成為主流的時候，大家不可避免的在思考，是不是可以通過簡單的可視化配置或者邏輯圖就能實現編程呢？比如產品經理把產品設計好，時序圖畫好，自動就可以編程可以跑得程式。
命令式 vs 描述式
對於傳統的軟體開發，我們需要定義數據結構，定義變數，通過一行行命令式的代碼，來精準的控制電腦執行每一步操作。這個過程中，對於開發者要求是比較高的，要有電腦運行的基本知識，要有演算法的基本能力，而且時常要從電腦角度觸發邏輯思考，包括線程池管理，記憶體管理等問題。這些，無疑都增加了開發者的門檻，同時也會增加工作量。
那低代碼的目標就是減少工作量和對底層邏輯的關係，從此目標出發，我們可以構建一種描述式的編程方式。
所謂描述式的編程，就是把業務需求標準化，配置化，最優方案是可視化的配置的方式實現快速開發，這個過程中，開發人員不用關心電腦底層邏輯，只需要描述好數據模型，業務流程即可。
現在已經有很多成熟的低代碼平臺，比如Mendix這種，對於業務不複雜的情況，能夠實現程式的快速構建。但對於很多程式員來說，還是很不適應這種編碼方式。對於大多數程式員來說，一個好的低代碼框架，反而是更香的那個麵包，對於解決眼前的饑餓能夠起到立竿見影的效果。
說一下我們熟悉的一些業務場景，包括 工作流引擎，前端頁面裝修等，這些業務場景已經有了很成熟的低代碼框架幫我們解決。比如工作流引擎，當你處理流程審批的業務場景的時候，如果沒有工作流引擎，你可能還需要自己用狀態機來硬編碼你的程式，有了工作流引擎，我們可以實現業務配置化。
而業務編排思想，其實就是從命令式走向描述式的一次探索，所有低代碼框架的核心思想就是業務編排能力，通過打造不同的原子，和原子之間的排列組合，從而實現業務能力。
低代碼實現路徑---業務編排
業務編排思想核心還是業務單元模塊化，這個在某種程度跟微服務思想有點不謀而合。通過模塊化去解耦複雜業務系統，化繁為簡。下麵貼一個簡單的業務編排架構圖：
1. 核心組件說明
a. 流程引擎，規則引擎和決策表。
這些概念在activiti這種框架中也是耳熟能詳的，所以可以看出，業務編排也是依靠流程驅動實現的。只不過activiti關心的是橘色任務流轉，比如OA審批流這種，而業務編排關心的事一個複雜業務本身中的業務粒度拆分和裝配，例如下單流程，價格規則等等。
b. 上下文管理。
這個也是很重要的，在一個複雜的業務編排過程中，每個獨立組件之間不可避免會有數據交互，而這些都交給了上下文處理。對於上下文管理，也有兩種方式，一種是流程串聯中的上下文傳輸，類似水流中的小紙船，他會在流程中通過業務控制實現上下文的傳遞，當然這種在實現和理解上都會更複雜一些。
還有一種方式類似工作台，這裡可以做一個類比：n個工人按照一定順序圍繞一張工作台進行零件生產，每個工人都可以從工作臺上拿去資源生產自己的零件，而每個工人會將自己生產的零件放在工作臺上，同時也可以從工作臺上領取別的工人做好的零件。而這個工作台就是上下文， 所有的資源和零件在這個工作台之上是共用的。這種共用上下文的設計思想會讓業務實現和理解變得簡單，但它的問題在於組件的安全性和約束性，因為資源共用，所以每個組件都可以對資源進行修改，在軟體開發中，有時候失去約束性，會在系統迭代的過程中出現變質，這就類似於面向對象編程中的封裝性。
2. 案例講解
這裡舉個業務編排的例子，我們以商品詳情查看為例：
通過上圖可以看出，在商品詳情查看這個介面中，包含了商品基本信息查詢，庫存查詢，售後查詢，可售性查詢等流程，然後最終才得到返回值。
你可以將瀑布流式的代碼，轉變成以組件為核心概念的代碼結構，這種結構的好處是可以任意編排，組件與組件之間是解耦的，組件可以用腳本來定義，組件之間的流轉全靠規則來驅動。
可能有的同學會說，這個業務用瀑布是寫也問題不大嘛。那我再換一個更複雜一些的業務流程，大家是不是就可以看出業務編排的優勢，下麵給大家一個商城搜索介面的業務邏輯圖：
上面的案例是筆者在採靈通系統開發中真實的一個案例，筆者最開始是採用瀑布方式實現的該搜索關鍵字處理邏輯。但之後進行了重構，通過引入開源框架liteFlow的業務編排框架，極大的簡化的業務複雜度。基本可以實現流程圖即代碼的程度。具體代碼就不貼在此處了，如果大家該興趣，可以去研究一下liteflow這個業務編排開源框架。
從業務編排晉升為低代碼框架
從業務編排晉升為低代碼框架，需要改進幾個地方，第一個就是流程節點的Node， 在業務編排中，Node節點是一個可以自定義的業務模塊，可以由程式員自行寫業務邏輯。業務編排做到的是把複雜的業務變成簡單的業務，但簡單的業務也是需要開發的。如果我們把簡單的業務也原子化和配置化，那麼就可以成為一個入門級的低代碼框架了，那麼，我們的架構該如何調整呢？
首先我們需要將Node節點晉升為微流程節點，同時需要元數據模型支持。在微流程節點內，我們可以自定義CRUD模塊，也可以自定義動作和發佈時間，所有的緩存，查詢都會定義為一個個的微流程節點，當微流程節點豐富度可以覆蓋我們的業務代碼需求時，我們就可以是先業務開發的配置化。然後在配合部署管理模塊，實現代碼的一鍵發佈，這樣就實現了一個簡單的低代碼框架。而這也是所有主流的商用低代碼框架的思路。
總結
業務編排是實現低代碼的路徑之一，但不是唯一路徑。尤其是當我看到ChartGPT4.0出來之後，人工智慧，可以通過一個網頁草圖自動生成html代碼時，我覺得，這可能才是低代碼的最終歸宿吧。
作者：京東物流 趙勇萍
內容來源：京東雲開發者社區
