#頭條創作挑戰賽#

選型指標

低代碼最近也非常火爆，

很多企業和項目的運營或者管理者們，

看到了低代碼系統的價值。

現在低代碼系統市場魚龍混雜，

那么如何規避風險，

選擇合適自己的低代碼系統呢？

以下是作為一名在低代碼領域深耕十幾年的從業者的建議。

選擇低代碼系統的關鍵還是在自身，

大家需要整理出自己當前和未來幾年對應用系統的需求。

然后再對低代碼系統進行詳細的調研。

低代碼系統是降本增效的利器，

但是不管是低代碼系統配置出來的，

還是使用原生代碼編碼開發出來的應用系統，

作用只有一個：支撐業務。

任何支撐不了業務的應用軟件，

都可以說是沒有價值的。

當前的低代碼系統核心特點大概分為兩類：

1. 元數據驅動；
2. 表單驅動。

低代碼系統對于新模塊的業務實現又分為兩類：

代碼生成和非代碼生成。

代碼生成是指：低代碼系統配置的新功能模塊，需要生成代碼。

一、應用系統的復雜程度

應用系統復雜程度這個指標，

在很多時候沒有一個明確的標準。

籠統一點可以理解為數據交互的復雜程度。

OA、CRM這類系統可以歸為復雜程度較低的系統。

供應鏈、生產管理這類可以歸為復雜程度較高的系統。

那什么是數據交互呢？

舉個例子：

典型采購流程

上圖是一個典型的采購流程。

采購部門創建采購申請單之后，

關聯生成采購訂單(金蝶ERP中成為：下推)，

采購負責人與供應商聯系，

確定貨物配送的具體事宜，

同時關聯生成采購入庫單，

當需要采購的貨物到達倉庫時，

倉庫根據實際情況，完成采購入庫單。

同時財務部門會收到一個應付單。

上圖中當其中一個節點發生變化時，

需要和上下游流程進行數據處理，

也就是圖中標注的反寫。

當然數據的交互不只是關聯生成和反寫，

還有值更新、超額檢查、關單等各種操作。

上圖中的業務在一個企業里是非常常見，

也是非常典型業務。

當前市面上的絕大部分，

以表單驅動的低代碼系統是支持不了的，

除非再次做二次開發。

只能是元數據驅動的低代碼系統可以很好地支持。

如果需要做大量二次開發才能支撐起業務，

那么這種低代碼系統價值就不高了，

只能將其定位為：快速開發平臺，

和某種語言的開發框架屬于一個層次。

二、是否有大量計算任務

大量的計算任務是指什么呢？

舉個例子：

我們的ERP系統中的MRP(物資需求計劃)，和生產計劃排程。

要完成這兩類數據，

系統需要進行大量的數據運算，

而且大多數情況下，運算時間比較長。

低代碼系統基本上是由靜態類型語言開發的，

靜態語言開發的系統，

如果需要更新，就需要重啟服務。

如果有我們的業務系統正在跑計算任務，

而系統由于更新被重啟了服務，

那就不可避免地會中斷計算，

而且產生了大量的臟數據，

這就是一場災難。

所以，如果業務系統有這種大量運算的場景，

基于代碼生成的低代碼系統就不適合了。

低代碼

到此，我們已經簡單地說明了低代碼系統選型的主要標準。

OA、CRM等這類系統可以使用表單驅動的低代碼系統，

而供應鏈、生產管理等這類系統需要使用元數據驅動的低代碼系統。

復雜系統盡量避免使用代碼生成模式的低代碼系統。

根據我們對國內低代碼系統市場的背調。

絕大部分低代碼系統是使用的Java或者C#開發，

一個動態表單模塊，

配合工作流引擎（Flowable、Activiti等）

再加一個數據大屏，

就算一個低代碼系統了。

當然如果是支撐類似OA、CRM這類系統，是沒問題等。

較復雜應用系統，

當前只能是基于元數據驅動的低代碼系統才能支撐。

如果您覺得本文對您有用，建議收藏；

如果您覺得對您的朋友有幫助，請分享給他們；

如果您能點個贊，那就是對作者最大的支持。

更多精彩內容發布于公眾號：代碼乾坤 （CoderLand）