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