低代碼格局和來龍去脈
低代碼產(chǎn)品來源主要有三個渠道，如果不算廣義的CRM、ERP系產(chǎn)品（Wix、WordPress、Odoo…這些），這些產(chǎn)品構(gòu)成了現(xiàn)在低代碼的主要格局。
渠道一：從MADP/MXDP演進而來：
MADP代表“移動應用開發(fā)平臺”，其實就是做原生APP可視化開發(fā)的平臺；MXDP代表“混合多體驗開發(fā)平臺”，實際上就是在移動原生APP開發(fā)平臺基礎(chǔ)上增加了對Web App的支持?，F(xiàn)在有了GPT，我直接把GPT4的描述寫在下面，大家就很清楚了。
?
大家會發(fā)現(xiàn)最主要的廠商都在上面… Mendix Outsystems PowerApps 等。
這類低代碼產(chǎn)品的特定也非常清晰：多數(shù)做企業(yè)服務（會有一套完整系統(tǒng)安裝到企業(yè)內(nèi)部），有相對復雜的IDE，功能上也相對比較完整，研發(fā)的周期也比較長，大部分都在10年以上。這類型產(chǎn)品，主要其實也是給研發(fā)人員使用的，或者他們叫“CitizenDeveloper”，但是真正的業(yè)務人員很難學會。
渠道二：之前做“SaaS”、“BPM”以及“Bi”為主的廠商
這里面比較有名的是 ZoHo Creator、Salesforce、Airtable、AppShee、Appian 、Tableau、PowerBi等，國內(nèi)有很多廠商都是從這個領(lǐng)域介入低代碼研發(fā)的。這類型演變過來的低代碼產(chǎn)品，往往場景比較明確（主要是“BI場景”、“工作流BPM場景”、“在線表格場景”、“在線表單場景”這四種），通常是多個“引擎”和“模型”驅(qū)動的，基本都可以給業(yè)務人員直接使用，感覺上就像是很多SaaS 用戶 權(quán)限管理，開發(fā)全新場景時，靈活性會受到一些限制。
渠道三：也是重點想介紹的——代碼生成平臺
這類平臺國內(nèi)比較少，而且主要專注于“通用程序開發(fā)”，是一種底層通用技術(shù)（上面提到的更傾向于“應用開發(fā)框架”），因此也不會限制只用于“企業(yè)服務”。
國外的代碼生成平臺主要包括以下這些：
前端代碼生成平臺：WebFlow Wappler PineGrow ReactStudio
后端代碼生成平臺：Backendless Firebase (by Google) Stapi
數(shù)據(jù)庫代碼生成平臺：Prisma DbDesigner SQLDBM QuickDBD
具有統(tǒng)一的前后臺代碼生成能力的就比較少了，主要有： Bubble Appgyver (By SAP) Retool ，國內(nèi)就只有 iVX 一家。
有了這些基礎(chǔ)知識，那下面介紹起來就比較輕松了。接下來….
如何評價低代碼平臺？
我列出了最核心的三項，以及我覺得重要的評分項，供大家參考。
核心能力一：功能和性能 ？（詳細見后面列表）
（大白話就是：不寫代碼能做什么？做得怎么樣？）這個重要性不言而喻，有些低代碼平臺說自己“接代碼”什么都能實現(xiàn)，這句話當沒說。核心還是一句，不寫代碼能做什么！這個地方我覺得可以補充一下，就是“低代碼編程”和“代碼編程”的關(guān)系，我們覺得最佳實踐就是“充分非必要！”，即“什么代碼都可以用，但是不用也都行”。
核心能力二：是否鎖定 ？
我先解釋一下，什么叫不鎖定？最佳狀態(tài)就是“和手寫代碼一個樣”，最好“調(diào)試方式和代碼管理”都可以繼承。這里面分幾個層面：例如“低代碼平臺”生成的代碼可以被現(xiàn)有的代碼形式“直接接受”，意味著原有的開發(fā)項目直接可以以插入的方式使用。另外，以前端為例，可以直接在低代碼平臺中直接導入以前開發(fā)“組件或代碼”那是更好。其實開發(fā)者不一定需要在“二開”的時候，直接修改“低代碼平臺”導出的源代碼（如果可以導出），而是需要這種“修改的能力”！這是一種“安全感”，這一點其實非常重要，當然難度也是最大的。
坦率的講，想在絕大多數(shù)的低代碼平臺都存在鎖定用戶的問題，即無法實現(xiàn)“應用代碼導出和獨立部署”，有些是可以打包導出一個加殼文件，最后還是要導入到特定環(huán)境中運行的。大概如下圖所示：
情形一：所有應用都在框架內(nèi)部，無法導出獨立部署
?
情形二：應用可以導出，例如導出成 mpk或osp文件，但是只能導入到自身平臺環(huán)境運行
?
核心能力三：產(chǎn)品整合能力 ？
我研究過很多低代碼產(chǎn)品，很多產(chǎn)品從“開源”魔改而來，“功能堆疊和拼接感”嚴重，看上去吧好像這個也有，那個也支持，但是用起來完全不是那么一會事兒。說白了就是“其實開發(fā)一個應用有可能比寫代碼還費勁”。從一個側(cè)面反映就是，窗口數(shù)量眾多、操作層級特別深、邏輯和管理混亂，有些邏輯控制甚至有多個入口。道理其實也很簡單，現(xiàn)在無論大廠小廠要開發(fā)一個產(chǎn)品時，先就找對應的開源產(chǎn)品和框架，然后開始組裝和拼接，但是其實開源產(chǎn)品可能設計初衷并不是為了“低代碼”，而且拼接越多，整個產(chǎn)品就越笨重，越難以駕馭。
以下是我總結(jié)的低代碼產(chǎn)品的基本評分項，并以 iVX 為例進行了描述。有什么新的評分項，大家還可以補充，我們不整虛的，行就是行，不行就是不行，希望低代碼生態(tài)可以越來越健康。
低代碼能力評分項（詳細版，附帶iVX評價結(jié)果）
|
評價項 | 評價說明 | iVX產(chǎn)品評價結(jié)果 |
平臺會鎖定用戶嗎？ | 分幾種情況：1. 直接生成外部環(huán)境可以運行源代碼，無鎖定；2. 生成只能在平臺內(nèi)部環(huán)境運行的應用，鎖定；3. 平臺生成應用，應用可以以某種平臺特定格式導出，但是必須在平臺環(huán)境才能導入，為部分鎖定。例如mendix/outsystems 就輸入部分鎖定。Power Apps也只能在Azure中運行也是這種部分鎖定。 | 可以完整導出前端、后臺、數(shù)據(jù)庫代碼，可以在任何環(huán)境運行，無鎖定 |
平臺收費方式？ | 分幾種情況或組合：1. 平臺免費，使用使用云計算服務時，收取云計算費用；2. 根據(jù)最終應用的用戶數(shù)量進行收費；例如一個應用最終是100人還是100萬人，價格差距很大；這種往往是上面提到的“鎖定”或“部分鎖定”模式造成的；3. 根據(jù)開發(fā)者數(shù)量進行收費；4. 根據(jù)開發(fā)的應用數(shù)量和類型進行收費； | IDE和平臺免費，如果使用到了云計算，云計算收費；如果不使用云計算，應用可以免費導出平臺，自行部署； |
支持整個平臺支持對外部署？ | 這里不是指平臺內(nèi)部應用導出部署，而是說整個平臺在公網(wǎng)或局域網(wǎng)內(nèi)部部署 | 支持 |
應用導出支持的部署方式？ | 例如包括：單機部署（Linux/Windows）、云端虛擬機部署、Docker K8S部署 | 都支持 |
是否支持導出應用一鍵部署？ | 例如會幫用戶安裝MySQL和redis如果用戶服務器或虛擬設備上沒有安裝，然后一鍵完成部署，只需要填寫一些IP 用戶名和密碼等 | 支持一鍵部署 |
對ARM或國產(chǎn)芯片/麒麟系統(tǒng)支持？ | 整個平臺支持ARM環(huán)境？生成的應用支持ARM環(huán)境？整個平臺支持在麒麟等國產(chǎn)系統(tǒng)中部署？生成應用支持在過程麒麟等系統(tǒng)中部署？ | 全部都支持 |
平臺或工具/IDE的開發(fā)環(huán)境？ | 是Web環(huán)境的B/S架構(gòu)，還是C/S架構(gòu)的產(chǎn)品？ | B/S架構(gòu) |
平臺使用者一定要會某種代碼嗎？ | 對于絕大多數(shù)應用來說，由于平臺描述邏輯方式的限制，或者沒有完備描述前后臺邏輯的方法，因此，必須引入代碼。或者由于組件不完備，必須引入代碼。 | 無需懂代碼 |
如果要懂代碼，平臺需要懂哪種代碼？ | 一般包括SQL、JS（包括框架react/vue等一種）、Java、Python、Node.js、PHP、.net代碼 | 一種都不是必須的 |
開發(fā)者使用平臺能生成大概代碼比例？ | 主要根據(jù)平臺“無代碼邏輯表達能力”以及“組件多少和架構(gòu)”來確定，例如，如果前后臺都需要大量代碼的，工具或IDE只是輔助，那么生成代碼量一般小于30%；如果需要輸入代碼不多，但是一定需要代碼才能完成的，一般代碼量在60～70%，如果完全不需要代碼，大部分應用都可以完成的，自動生成代碼量可以大于95%。 | 通常生成代碼超過應用總代碼量95%； iVX和代碼關(guān)系為“充分非必要” |
平臺能夠支持的開發(fā)的應用類型？ | 包括其中一種或幾種：WebApp、iOS/Android原生應用、Win/Mac/Linux原生應用、微信小程序、或Google或FB平臺內(nèi)的應用格式 | 支持WebApp、iOS/Android原生應用、Win/Mac/Linux原生應用、微信小程序 |
平臺支持的應用的場景有哪些？ | 包括：1. 全場景，無論個人應用還是B端應用，無論游戲、電商、各種企業(yè)場景、iot、各類系統(tǒng)都可以開發(fā)；類似編程語言，本身沒有什么限制；2. 主要支持BI場景（根據(jù)數(shù)據(jù)作圖）、在線表單場景（用于快速填寫，快速提交）、在線表格場景（類似在線的excel或Google sheet）、BPM（流程圖、審批流場景），用戶可以根據(jù)這些場景再延伸，以及做近似的二次開發(fā)，產(chǎn)生新的相似應用或場景；3. 主要支持BI場景（根據(jù)數(shù)據(jù)作圖）、在線表單場景（用于快速填寫，快速提交）、在線表格場景（類似在線的excel或Google sheet）、BPM（流程圖、審批流場景），但是就是給業(yè)務人員使用的，操作和使用更簡單，但是靈活性較差。 | 1. 全場景 |
支持應用或生成代碼的范圍？ | 1. 生成整個應用，以及全部代碼；2. 生成整個應用，不生成代碼；3. 生成整個應用，生成部分代碼或生成代碼不能脫離平臺；4. 只生部分代碼，例如只生成前端/后臺/數(shù)據(jù)庫中一部分，不能單獨使用； | 1. 生成整個應用，以及全部代碼 |
代碼邏輯可視化的方式？ | 現(xiàn)階段大體分5種：1. 流程圖模式，類似mendix/outsystems這樣的要化流程圖的；2. Scratch模式，就像Scratch一樣，一塊塊積木，拼接出來表達邏輯；3. iVX模式，事件面板模式，是一個面板，有一點像construct2/3，但是設計更好，全部都是數(shù)據(jù)點選，所有組件都面向?qū)ο笤O計，可以在事件面板中操作，也可以加“if” “for” “function” 等事件塊，完成整個邏輯表達，且是圖靈完備的；4. 公式表達式模式：例如Power Apps采用類似Excel的公式表達式來表達邏輯；5. 函數(shù)式模式，例如SAP的Appgyver，把函數(shù)的出參和入?yún)⒂镁€連起來表達邏輯。 | 3. iVX的事件面板模式 |
組件的架構(gòu)？ | 具體包括：組件一層架構(gòu)還是多層架構(gòu)？例如iVX就有3層組件架構(gòu)，以平衡靈活和效率；是否區(qū)分了前臺和后臺組件？ | iVX三層組件架構(gòu)：微組件（不可見）、基礎(chǔ)組件（100 ）、小模塊（1000 ）；前后臺組件分離 |
組件是否支持自定義組件？ | 支持自定義前端組件？支持自定義后臺或數(shù)據(jù)組件？ | 前后臺都支持自定義組件 |
是否用word/excel/ppt兼容的組件？ | 主要是為了在企業(yè)辦公中可以整合現(xiàn)有離線文檔 | 全部都有 |
支持前后臺的API組件或方法？ | API是一種基礎(chǔ)的應用內(nèi)部和系統(tǒng)直接提供服務的方法，對現(xiàn)有系統(tǒng)的整合至關(guān)重要 | 通過前后臺API組件支持 |
支持Socket方法？ | 例如支持websocket | 通過Socket組件支持 |
組件中是否有變量組件？ | 變量作為組件可以充分保證邏輯實現(xiàn)的靈活性，有了變量組件可以跟接近編程語言體驗 | 有 |
前端采用什么框架？ | vue、react、bootstrap、jquery、自研框架等，例如iVX使用自研框架類似vue結(jié)構(gòu)效率和react相當；例如牛刀低代碼使用WeX5框架； | 自研框架，類vue，很容易看懂生成代碼 |
前端是否支持自定義CSS？自定義JS函數(shù)？ | 在IDE中，前端可以插入JS函數(shù)和自定義CSS樣式 | 都支持 |
前端生成的代碼可以在什么框架下重用？ | 前端生成的代碼時候可以在老的系統(tǒng)中重用，作為其中一個部分。例如iVX可以生成支持vue和react的component，并嵌入到原有的vue/react項目中進行使用。 | 可以在vue/react中作為component使用 |
前端是否支持原有組件？ | 例如前端可以導出vue或react組件，包括AntD elementUI或自有組件 | 支持全部react組件導入 |
前端是否支持響應式布局？ | 拖拽之后，內(nèi)容會跟隨改變，例如可以同時支持手機和PC瀏覽，一次開發(fā) | 支持 |
是否支持絕對定位和相對定位？ | 一般絕對定位在動畫或游戲界面中常用，而相對定位在應用和網(wǎng)頁設計中常用 | 都支持 |
所有后臺資源直接使用云計算廠商服務？（即serverless支持？） | 即實現(xiàn)平臺只生成后臺代碼本身，和運行時需要后臺資源解耦，并發(fā)、數(shù)據(jù)、安全、存儲由云計算產(chǎn)品來負責。 | 完全解耦，直接可以連云計算廠商產(chǎn)品； |
對接的云計算廠商產(chǎn)品是否有開源產(chǎn)品對應？ | 目的是：不要被云計算廠商鎖定，如果所有產(chǎn)品都有開源產(chǎn)品對應的話。 | 所有產(chǎn)品都有對應的開源產(chǎn)品，可以在任何云或私有環(huán)境部署導出應用 |
后臺支持哪些語言代碼生成？ | 一般包括其中一種或幾種：Java、C#、Node.js、PHP、Go、WASM等 | Java和Node.js |
支持哪些語言的SDK上傳？ | 為了更好支持對原有代碼的集成，最好能支持SDK上傳 | 支持 Java/Node/Android/Javascript SDK 上傳 |
支持微服務？ | 一切為了重用和管理，微服務是重要的手段 | 支持微服務 |
支持數(shù)據(jù)庫情況？ | mysql/SQL server/PostgreSQL/Redis/ClickHouse/neo4j/Mongo DB/ES/MQ/國產(chǎn)數(shù)據(jù)庫 | 全部支持 |
數(shù)據(jù)庫支持能力如何？ | 是否支持數(shù)據(jù)庫常見功能，例如：索引、join、事物、存儲過程（存儲過程基本都建議不用） | 支持索引、join、事物 |
支持RBAC進行用戶訪問和權(quán)限管理？ | RBAC是基于角色的訪問控制，是一種訪問控制方法，可根據(jù)最終用戶在組織中的角色為其分配權(quán)限。RBAC提供了細粒度的控制，提供了一種簡單、可管理的訪問管理方法，與單獨分配權(quán)限相比，這種方法更不容易出錯。這可以降低網(wǎng)絡安全風險，保護敏感數(shù)據(jù)，并確保員工只能訪問信息并執(zhí)行他們完成工作所需的操作。這被稱為最小特權(quán)原則。RBAC的實現(xiàn)方法包括：定義角色、定義權(quán)限、將角色分配給用戶、將權(quán)限分配給角色、將用戶分配給角色。 | 支持 |
支持權(quán)限管理和控制？ | 通常包括以下部分一種或幾種：1. 數(shù)據(jù)庫字段用戶訪問權(quán)限和控制；2. 微服務用戶訪問權(quán)限和控制；3. 前端顯示和操作的用戶訪問權(quán)限和控制；4. 對數(shù)據(jù)表行進行訪問控制管理；（4這條好像只有活字格產(chǎn)品支持了，但是好像并沒有必要，開銷很大） | 支持1、2、3三種情況； |
支持各種數(shù)據(jù)傳輸加密？ | 加密方式為傳輸加密或提供加密組件（可以配置加密方法） | 默認傳輸加密和加密組件都提供 |
前端防注入和SQL防注入？ | 防止SQL注入：使用預編譯語句、使用存儲過程、使用參數(shù)化查詢、對輸入進行過濾和驗證、限制用戶輸入長度、限制用戶輸入類型等。防止JS注入：對用戶輸入進行過濾和驗證、使用轉(zhuǎn)義字符、使用正則表達式等。 | 都嚴格檢查 |
是否有詳細的后臺日志生成？ | 后臺日志主要用來記錄和Debug后臺的程序和服務 | 有非常詳細，而且是可視化的 |
支持多人開發(fā)和版本管理？ | 多人開發(fā)，例如Git類似的開發(fā)機制 | 支持多人同時開發(fā)，和各種形式的無限版本管理 |
整理撰寫不易，希望對大家加深對低代碼平臺的理解，以及對開發(fā)低代碼平臺的同學有幫助。
?
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權(quán)，不承擔相關(guān)法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。