對於低代碼早有耳聞，一直沒更進一步花時間瞭解，藉着這次探討學習的機會，翻了些資料再試用了幾個平臺，淺顯談談對低代碼的理解，熟悉這塊的朋友，可以一起討論。
![]()
[ From unsplash ]
太陽低下沒有新鮮事，低代碼或者零代碼也不是新事務，只不過用一種新概念來包裝加工一些舊的工具或系統，比如Dreamweaver、在線建站系統等，透過拖拽就可以完成一些網站頁面的開發，比如一些PASS平臺，通過成熟的中間件或組件，快速搭建一個分佈式系統等等。至於低代碼、零代碼或無代碼的差別，從名稱上大概也可以猜出一二來。
聽慣了PaaS、IaaS、SaaS、BaaS，這裏再提及一個：aPaaS，是PaaS的一個分支，全稱爲應用程序平臺即服務。在國外也都有比較成功的案例，國內也有一些廠商在從事這塊業務，目的就是讓非技術人員也可以參與進來，進行業務系統的研發。這也是當下雲計算、信息化、數字化必然涉及到的一塊業務，總存在一些企業信息化能力很弱，沒有專職的研發團隊來進行軟件開發，交由專業的廠商來做似乎是一個明智的選擇。
近兩年也出現一批業務流程管理類的低代碼平臺，相比aPaaS而言，上手入門門檻更低，短時間就可以搭建一套適用於企業業務管理系統，相比傳統的研發模式，不僅省時間成本，研發團隊崗位、硬件投入成本也大量減少，對中小企業而言，何樂而不爲。
低代碼再好也不是銀彈，無法解決所有問題，在試用了國內BPM類型幾個低代碼平臺後，簡單梳理了下優缺利弊。
利
-
無須依賴開發人員，懂一定的基礎即可上手開發業務系統
-
功能覆蓋數據收集、報表、流程審覈等常見的功能，提供通用應用模板
-
無須弄懂應用的運轉邏輯、服務器運維等，全由平臺負責
-
與支持的第三方應用授權綁定實現數據同步，如釘釘、teambition等
-
-
-
在同一套低代碼平臺內部，各個子系統間的數據互通，降低了數據孤島的可能性
弊
-
需要一定的邏輯抽象能力，並非面向所有人員都可以輕鬆上手使用
-
系統運行限定在低代碼平臺的雲服務上，主要面向企業內部的管理系統爲主，雖然少部分可以私有化部署
-
無法完美與自研系統融合，對外提供API有限，不能直接讀取底層數據庫
-
複雜的場景無法支持，一旦使用後出現無法滿足需求的情況，只能捨棄需求
-
面向C端用戶的功能應用適用性不高，與當下的小程序業態融合不夠友好
一些研發過程中常見的管理系統腳手架，也被包裝成低代碼/無代碼平臺，進行對外銷售。這也說明概念不斷推陳出新，蹭個熱度更有助於打開銷售局面，提高市場佔有率。
在有一定研發能力，業務場景並非簡單的增刪查改的情況下，通過編碼的方式會更好。時下形態下的低代碼已經可以幫不少中小微企業解決實際的問題，特別是傳統企業的數字化轉型，是一個值得嘗試的方向。
本文分享自微信公衆號 - 碼聞強識（mavenTalk）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
