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