基于經典的可視化和模型驅動理念，結合最新的云原生與多端體驗技術，低代碼能夠在合適的業(yè)務場景下實現大幅度的提效降本，為專業(yè)開發(fā)者提供了一種全新的高生產力開發(fā)范式（Paradigm Shift）。另一方面，低代碼還能讓不懂代碼的業(yè)務人員成為所謂的平民開發(fā)者（Citizen Developer），彌補日益擴大的專業(yè)人才缺口，同時促成業(yè)務與技術深度協作的終極敏捷形態(tài)（BizDevOps）。那什么是低代碼呢？

Wikipedia定義

從Wiki的這段定義中，我們可以提煉出幾個關鍵信息：

低代碼開發(fā)平臺（LCDP）本身也是一種軟件，它為開發(fā)者提供了一個創(chuàng)建應用軟件的開發(fā)環(huán)境?？吹健伴_發(fā)環(huán)境”幾個字是不是很親切？對于程序員而言，低代碼開發(fā)平臺的性質與IDEA、VS等代碼IDE（集成開發(fā)環(huán)境）幾乎一樣，都是服務于開發(fā)者的生產力工具。

與傳統代碼IDE不同的是，低代碼開發(fā)平臺提供的是更高維和易用的可視化IDE。大多數情況下，開發(fā)者并不需要使用傳統的手寫代碼方式進行編程，而是可以通過圖形化拖拽、參數配置等更高效的方式完成開發(fā)工作。

Forrester定義

順著Wiki的描述還能發(fā)現，原來“Low-Code”一詞早在2014年就由Forrester提出了，它對低代碼開發(fā)平臺的始祖級定義是這樣的：

相比Wiki的版本，這個定義更偏向于闡明低代碼所帶來的核心價值：

低代碼開發(fā)平臺能夠實現業(yè)務應用的快速交付。也就是說，不只是像傳統開發(fā)平臺一樣“能”開發(fā)應用而已，低代碼開發(fā)平臺的重點是開發(fā)應用更“快”。更重要的是，這個快的程度是顛覆性的：根據Forrester在2016年的調研，大部分公司反饋低代碼平臺幫助他們把開發(fā)效率提升了5-10倍。而且我們有理由相信，隨著低代碼技術、產品和行業(yè)的不斷成熟，這個提升倍數還能繼續(xù)上漲。

低代碼開發(fā)平臺能夠降低業(yè)務應用的開發(fā)成本。一方面，低代碼開發(fā)在軟件全生命周期流程上的投入都要更低（代碼編寫更少、環(huán)境設置和部署成本也更簡單）；另一方面，低代碼開發(fā)還顯著降低了開發(fā)人員的使用門檻，非專業(yè)開發(fā)者經過簡單的IT基礎培訓就能快速上崗，既能充分調動和利用企業(yè)現有的各方面人力資源，也能大幅降低對昂貴專業(yè)開發(fā)者資源的依賴。

低代碼核心能力

基于上述的定義和分析，不難總結出如下這3條低代碼開發(fā)平臺的核心能力：

全?？梢暬幊蹋嚎梢暬瑑蓪雍x，一個是編輯時支持的點選、拖拽和配置操作，另一個是編輯完成后所及即所得（WYSIWYG）的預覽效果。傳統代碼IDE也支持部分可視化能力（如早年Visual Studio的MFC/WPF），但低代碼更強調的是全棧、端到端的可視化編程，覆蓋一個完整應用開發(fā)所涉及的各個技術層面（界面/數據/邏輯）。

全生命周期管理：作為一站式的應用開發(fā)平臺，低代碼支持應用的完整生命周期管理，即從設計階段開始（有些平臺還支持更前置的項目與需求管理），歷經開發(fā)、構建、測試和部署，一直到上線后的各種運維（e.g. 監(jiān)控報警、應用上下線）和運營（e.g. 數據報表、用戶反饋）。

低代碼擴展能力：使用低代碼開發(fā)時，大部分情況下仍離不開代碼，因此平臺必須能支持在必要時通過少量的代碼對應用各層次進行靈活擴展，比如添加自定義組件、修改主題CSS樣式、定制邏輯流動作等。一些可能的需求場景包括：UI樣式定制、遺留代碼復用、專用的加密算法、非標系統集成。

不只是少寫代碼

回到最初那個直擊心靈的小白問題：Low-Code中的“Low”，到底是啥意思？答案已經顯而易見：既不是指抽象程度很低（相反，低代碼開發(fā)方式的抽象程度要比傳統編程語言高一個level），也不是指代碼很low（也相反，低代碼所生成的代碼一般都經過精心維護和反復測試，整體質量強于大部分手寫代碼），而是單純的“少寫代碼” —— 只在少數需要的情況下才手寫代碼，其他大部分時候都能用可視化等非代碼方式解決。

再往深一點兒看，低代碼不只是少寫代碼而已：代碼寫得少，bug也就越少（正所謂“少做少錯”），因此開發(fā)環(huán)節(jié)的兩大支柱性工作“趕需求”和“修bug”就都少了；要測的代碼少了，那么測試用例也可以少寫不少；除了開發(fā)階段以外，平臺還覆蓋了后續(xù)的應用構建、部署和管理，因此運維操作也更少了（Low-Code → Low-Ops）。

然而，少并不是最終目的：如果單純只是想達到少的效果，砍需求減人力、降低質量要求也是一樣的。低代碼背后的哲學，是少即是多（Less is More），或者更準確說是多快好?。―o More with Less） —— 能力更多、上線更快、質量更好，成本還更省，深刻踐行了阿里“既要，又要，還要”的價值觀精髓。

國內的低代碼概念，主要集中在“快速開發(fā)”和“降低門檻”上，這樣很多企業(yè)軟件產品基本上都能套上“低代碼”的光環(huán)！

區(qū)別到底在哪兒呢？結合Gartner報告總結幾個核心的要點：

1、開發(fā)完整性

提供一個低代碼的IDE，來完成設計、開發(fā)、數據和部署的過程；也就是可以對應用進行“全生命周期管理”。

國內現狀：提供多個SaaS產品，沒有統一的IDE界面；數據開發(fā)能力相對缺乏，很多只是“表格”，甚至沒有數據庫的能力。

2、應用獨立性（按這條多數國內產品都是“偽低代碼”）

所開發(fā)出來的應用，可以不依賴原系統獨立運行；（就看開發(fā)出來應用是否可以導出，單獨運行？）

國內現狀：多數平臺所開發(fā)出來的應用，只能在平臺內運行，是沒有辦法脫離平臺，也就是說并不是可以“獨立的應用”。例如：明道開發(fā)的應用無法在氚云上運行，宜搭、輕流、簡道、紅圈等也是如此；這些應用其實都是走的CRM和CMS“內部應用”的路子，在國外Zoho、Salesforce（Salesforce是另一款lightning App Builder被Gartner低代碼收錄）一開始也是這么做的。但嚴格意義來講這些產品確實不算是低代碼產品，至少Gartner是進不去的。

3、邏輯完備性

支持設計應用的前后臺的數據邏輯和業(yè)務邏輯；（包括存儲，不依賴第三方工具或平臺）

國內現狀：多數是支持表格邏輯，類似Excel的在線版本（其實功能趕不上Excel），而非數據庫邏輯，一些后臺甚至都不是采用數據庫來支持。做的比較好的，支持數據庫的連接和查看（取回數據），能支持控制數據庫，生成SQL語句的那就鳳毛麟角了。對于業(yè)務邏輯，除了兩三家，幾乎都是通過Blocks的方式來配置解決的，不能夠直接控制編寫業(yè)務邏輯，或直接生成業(yè)務邏輯代碼。

4、可接入：對API支持良好，可以接入外部API，也可以提供服務API供外部接入；可接入外部多種數據庫，可以顯示、管理、命令控制；

國內現狀：國內多數產品，都支持API的連接，這個大多數都可以支持。

5、可集成：可以集成現有前端后端的各種庫、框架、SDK，能共同編譯或直接使用；（例如Element UI，Echart，JDK…等）

國內現狀：這個要求比較高，能夠支持引入外部庫的系統就不多，也基本是前端JS庫為主，支持動態(tài)引入JDK好像還沒有。

6、可重用：低代碼本身的組件化和模塊化能力，抽象再抽象，封裝再封裝，重用再重用。

國內現狀：基本都有自身的組件系統，但是用戶可以自己開發(fā)組件插入的不多；通過現有低代碼開發(fā)平臺，生產可重用的模塊的就更少了。

特別重要——付費方式

另外，大家可以關注一下付費的方式，如果是按最終用戶數來進行收費的，從模式上講都沒有擺脫SaaS的影子，也說明應用是無法完全“獨立運行”的！只有按“開發(fā)者數量”收費，或“開發(fā)應用數量”收費，或云資源進行收費，才具有PaaS特征，我覺得才算是開發(fā)平臺?。ǚ駝t就是一個SaaS）

如果按以上能力要求，做了一個表格，大家自己看（把重點的抽象出來了）：

宜搭云、氚云、明道、輕流：都類似SaaS開發(fā)框架，不支持導出單個應用；也就是開發(fā)出來的應用都只能運行在它們系統內部，類似早起的CRM/CMS/ERP系統的路數。

云表：更老一點兒，還是C/S的架構的表格ERP/表格系統。

引邁信息：需要下載安裝的ERP開發(fā)框架，和odoo類似。

作者：元宇宙開發(fā)者及CSDN博主「阿里云技術」
鏈接：https://www.zhihu.com/question/458172659/answer/1872723468

https://blog.csdn.net/weixin_43970890/article/details/109743956
來源：知乎，CSDN