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

Wikipedia定義

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

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

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

Forrester定義

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

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

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

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

低代碼核心能力

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

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

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

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

不只是少寫代碼

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

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

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

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

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

1、開發(fā)完整性

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

國內(nèi)現(xiàn)狀：提供多個SaaS產(chǎn)品，沒有統(tǒng)一的IDE界面；數(shù)據(jù)開發(fā)能力相對缺乏，很多只是“表格”，甚至沒有數(shù)據(jù)庫的能力。

2、應(yīng)用獨立性（按這條多數(shù)國內(nèi)產(chǎn)品都是“偽低代碼”）

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

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

3、邏輯完備性

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

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

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

國內(nèi)現(xiàn)狀：國內(nèi)多數(shù)產(chǎn)品，都支持API的連接，這個大多數(shù)都可以支持。

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

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

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

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

特別重要——付費方式

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

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

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

云表：更老一點兒，還是C/S的架構(gòu)的表格ERP/表格系統(tǒng)。

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

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

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