1. 低代碼的概念由來

低代碼的由來可以追溯到軟件開發(fā)的演變過程。隨著信息技術(shù)的快速發(fā)展，企業(yè)對軟件應(yīng)用的需求不斷增加，傳統(tǒng)的手工編碼方式逐漸顯得效率低下，難以滿足快速變化的市場需求。

如果有研究過計(jì)算機(jī)程序語言發(fā)展史的同學(xué)，應(yīng)該有聽聞第一代編程語言 （1GL）到最新的第六代編程語言（6GL）的藍(lán)圖，每一代升級都是生產(chǎn)力的提升，到了第四代其實(shí)初見“低代碼”的端倪。但是還沒有正真提出“低代碼”這一概念。

低代碼概念需要借助低代碼開發(fā)平臺這一工具實(shí)現(xiàn)。維基百科將低代碼平臺定義為一種提供開發(fā)環(huán)境的軟件，基于低代碼平臺開發(fā)者不需要使用傳統(tǒng)的手寫代碼的方式進(jìn)行編程，而是可以通過低代碼平臺圖形化的用戶界面和參數(shù)設(shè)置來創(chuàng)建應(yīng)用軟件。

低代碼平臺面向的用戶群體是無需專業(yè)開發(fā)能力的企業(yè)業(yè)務(wù)人員和一部分專業(yè)開發(fā)人員。HR 、財(cái)務(wù)、銷售等業(yè)務(wù)人員完全可以自己或者在技術(shù) 人員的指導(dǎo)下開發(fā)出更符合特定業(yè)務(wù)工作需求的應(yīng)用程序，而專業(yè)技術(shù)人員則可通過可視化、流程化的開發(fā)方式，實(shí)現(xiàn)相比于純代碼模式更高效的開發(fā)。

單純從這些公開的信息，其實(shí)也無法直觀的了解啥是低代碼，在筆者看來低代碼不是一項(xiàng)具體的技術(shù)名稱，它是一個技術(shù)領(lǐng)域的統(tǒng)稱，是屬于其中一種程序開發(fā)模式。

2. 不同類型的“低代碼”

2.1. 按代碼量的維度來分類

這個維度下，程序的開發(fā)模式可以分為三種：純代碼（Pro Code）、低代碼（Low Code）、無代碼（No Code）

純代碼（Pro Code）純代碼開發(fā)是指使用傳統(tǒng)編程語言（如Java、Python、C#等）進(jìn)行軟件開發(fā)的方式。開發(fā)者需要具備編程技能，能夠手動編寫代碼來實(shí)現(xiàn)功能。它的特點(diǎn)具有：靈活性 - 開發(fā)者可以完全控制代碼的每一個細(xì)節(jié)，能夠?qū)崿F(xiàn)復(fù)雜的業(yè)務(wù)邏輯和功能；可擴(kuò)展性 - 可以根據(jù)需求進(jìn)行高度定制，適合大型和復(fù)雜的項(xiàng)目；學(xué)習(xí)曲線 - 需要較高的技術(shù)門檻，開發(fā)者需要掌握編程語言、框架和工具；維護(hù)性 - 代碼的可讀性和可維護(hù)性依賴于開發(fā)者的編碼習(xí)慣和團(tuán)隊(duì)的規(guī)范。Pro Code 和 No Code 實(shí)際上都很好理解，一個是純代碼，一個是無代碼。假設(shè) Pro Code 的代碼量是 100，那 No Code 就是 0，所以 Pro Code 和 No Code 是截然不同的，甚至你可以認(rèn)為這兩者毫無關(guān)系。No Code 的最典型形態(tài)莫過于 SaaS 類的產(chǎn)品了。

低代碼跟無代碼概念容易混淆，如果按照公式來表達(dá)的話: 

    C，Configuration in graphical，圖形化配置，這是大家對低代碼最直觀的認(rèn)知部分。通過各類常規(guī)的UI手段，如窗口、對話框、文本框、下拉框等編輯器等UI交互形式引導(dǎo)用戶表達(dá)信息。

    A，Arrangement in graphical，圖形化編排，基于圖元或其他形式的節(jié)點(diǎn)信息，通過連接、排布等方式表達(dá)流程、時(shí)序等信息。

    T，Textual DSL，文本型的DSL，借助某種文本化形式的特定領(lǐng)域語言做描述表達(dá)，可能為表達(dá)式或其他計(jì)算機(jī)語言，一般談“低代碼”中的代碼指的主要是這部分內(nèi)容。

低代碼的構(gòu)成公式

Low-Code（低代碼） =  50% C + 5% A + 45% T

無代碼的構(gòu)成公式

Low-Code（無代碼） =  50% C + 45% A + 5% T

嚴(yán)格來說，把采用無代碼模式生成程序的過程稱為開發(fā)是不恰當(dāng)?shù)?，因?yàn)樗皇菍σ延性訕I(yè)務(wù)能力進(jìn)行二次組合，形成具有特定功能的新業(yè)務(wù)而已。因此從這個角度來說，低代碼和無代碼完全不是一種東西，切不可將這兩者混為一談。

但有一個情況非常容易混淆低代碼和無代碼。當(dāng)?shù)痛a的成熟度到一定高度時(shí)，在某些細(xì)分場合下也可以實(shí)現(xiàn)零代碼開發(fā)。在這個情況下，從程序開發(fā)過程的表現(xiàn)看，這二者差異微小，此時(shí)最容易將兩者混淆。當(dāng)然，我們也不排除一些低代碼解決方案提供商為了夸大其低代碼的效果，故意將二者混為一談，把無代碼當(dāng)作一個噱頭來宣傳。實(shí)際上，低代碼模式要將一個場景做到零代碼，難度非常大，并且有諸多業(yè)務(wù)前提。

Low Code 是采用無邏輯的結(jié)構(gòu)化數(shù)據(jù)來描述業(yè)務(wù)的，對于相同業(yè)務(wù)，Low Code 的描述能力要弱于有邏輯的 Pro Code。所以，Pro Code 都做不到的事情，Low Code 當(dāng)然也做不到。如何有效解決強(qiáng)邏輯場合下的可視化配置方法，這是 Low Code 采用無邏輯的結(jié)構(gòu)化數(shù)據(jù)描述業(yè)務(wù)常見的重要短板。

低代碼平臺可以分為專用型和通用型兩種

所謂通用，指的是開發(fā)平臺不事先假設(shè)自身只能應(yīng)用在特定的場景、業(yè)務(wù)、行業(yè)，而是具有廣泛的適用范圍。具有這樣特征的開發(fā)平臺往往需要有一個通用的底座。這個底座是純技術(shù)性的，它不依賴于特定的業(yè)務(wù)功能，而只與業(yè)界廣泛使用的標(biāo)準(zhǔn)協(xié)議、技術(shù)標(biāo)準(zhǔn)產(chǎn)生耦合。不過，這個時(shí)候，我們只有深入平臺架構(gòu)實(shí)現(xiàn)的細(xì)節(jié)，才能判斷平臺到底是低代碼還是無代碼，這就導(dǎo)致平臺的使用者難以甄別。

但是，通用是有代價(jià)的，越通用就往往意味著在特定業(yè)務(wù)場景下的效率越低，越通用就意味著默認(rèn)配置里的個性化信息越少，為形成某個具體場景所需的配置量就越大，從這個具體場景的角度看，效率相應(yīng)也就越低。

所以通用型的低代碼平臺往往伴生著這個特征：有相對完善的有插件（或類似）機(jī)制。這一點(diǎn)相對來說比較好識別，相對高通用性的技術(shù)底座來說，插件是廉價(jià)的，因此通用性低代碼平臺往往會有數(shù)量眾多的插件。這些插件可以定制出各式各樣具體的業(yè)務(wù)場景，通過插件的定制化和擴(kuò)展性來解決效率問題。

2.3. 按業(yè)務(wù)類型來分類

其實(shí)，在一個具有較高通用適用范圍的低代碼平臺來說，按照業(yè)務(wù)類型分類幾乎是沒有意義的。之所以不得不按輸出程序類型分類，是因?yàn)殚_發(fā)平臺的通用性不足，而在有了足夠高的通用適用性之后，支持開發(fā)各種類型 App 的問題，就不在于能不能了，而只是時(shí)間問題。

按照業(yè)務(wù)類型區(qū)分大概有流程驅(qū)動型、表單驅(qū)動型、模型驅(qū)動（ORM）型、BI 分析、組件驅(qū)動類型這幾種，具體你可以看看這張表格（5 星為滿分）：

這里，主要區(qū)分一下表單驅(qū)動型和模型驅(qū)動型這兩個類型，因?yàn)樗鼈儽容^容易混淆。

所謂模型驅(qū)動型 App，它的模型指的是數(shù)據(jù)模型，或是數(shù)據(jù)關(guān)系。而這里所說的關(guān)系，指的就是符合三范式的關(guān)系型數(shù)據(jù)庫的關(guān)系，也就是你數(shù)據(jù)庫中各個數(shù)據(jù)表之間的關(guān)系，比如表 1 的 a 字段和表 2 的 a 字段是相同的，但與表 3 中的 a 字段沒有關(guān)系。在正確配置了各種數(shù)據(jù)關(guān)系之后（這個過程一般稱為數(shù)據(jù)建模），頁面上就可以很容易創(chuàng)建各種 CRUD（增刪改查）類頁面了。

表單類頁面則是僅以數(shù)據(jù)為中心，創(chuàng)造各種表單來收集或呈現(xiàn)數(shù)據(jù)。這里的關(guān)鍵點(diǎn)在于，這類頁面并不關(guān)注數(shù)據(jù)之間的關(guān)系。所以表單類的頁面非常容易形成數(shù)據(jù)孤島，并存在大量冗余數(shù)據(jù)，以及大量數(shù)據(jù)不一致性等問題。如果我們將表單類頁面做得比較完善的話，實(shí)際上它就會逐漸轉(zhuǎn)型成模型驅(qū)動類頁面了。在完成數(shù)據(jù)建模之后，我們就分不清楚它到底是模型驅(qū)動還是表單驅(qū)動了，差異只是前端是用表單展示，還是表格展示而已。

2.4、按使用者的類型來分類

如果按照使用者的類型進(jìn)行分類，我們可以將開發(fā)平臺的使用者分為 3 類：專業(yè)技術(shù)人員，業(yè)務(wù)技術(shù)員，相關(guān)無專業(yè)技能人員。

這里所說的業(yè)務(wù)技術(shù)員是一種正在興起的角色，它是指構(gòu)建供內(nèi)部和外部業(yè)務(wù)使用的技術(shù)或分析功能的非 IT 部門員工。他們擔(dān)任著裝備和賦能非 IT 資源以構(gòu)建數(shù)字化能力的戰(zhàn)略角色。

多數(shù)的無代碼開發(fā)平臺將業(yè)務(wù)技術(shù)員作為主要的用戶群，為他們提供對已有業(yè)務(wù)的二次組合為主的基礎(chǔ)開發(fā)能力，一般具有專業(yè)技能的開發(fā)人員是不會使用無代碼開發(fā)平臺的，因?yàn)閷I(yè)技能者要面對的問題域已經(jīng)大大超出了無代碼平臺的能力范圍。

而低代碼開發(fā)平臺一般會將專業(yè)技術(shù)人員和業(yè)務(wù)技術(shù)員同時(shí)作為他們的客戶群，并以專業(yè)技術(shù)人員為主要用戶群，業(yè)務(wù)技術(shù)員為次要用戶群。

隨著低代碼開發(fā)平臺的成熟度上升，業(yè)務(wù)技術(shù)員用戶群的占比會有所上升。因?yàn)槌墒於雀叩牡痛a平臺，不僅有各式各樣的可視化工具來降低業(yè)務(wù)研發(fā)的難度和代碼量，同時(shí)對業(yè)務(wù)研發(fā)生命周期各個環(huán)節(jié)的覆蓋也會越來越完整。從開發(fā)到測試，從測試到上線，再到高容錯運(yùn)行時(shí)自動化部署 / 恢復(fù)、運(yùn)行時(shí)自動化運(yùn)維等各個環(huán)節(jié)的可視化、自動化完成，這為無 IT 技能的業(yè)務(wù)技術(shù)員獨(dú)立開發(fā)提供了可能性。同時(shí)，越發(fā)完善的可視化自動化能力不僅會牢牢抓住已有的專業(yè)技能用戶，還會吸引更多的專業(yè)技能用戶的加入。

純代碼到無代碼甚至自驅(qū)式的開發(fā)，對平臺的成熟度要求越來越高，同時(shí)也能降低使用者的門檻。

總結(jié)以上分類，我們的大致脈絡(luò)圖如下：

總體而言，其實(shí)低代碼沒有定性的分類，除了這些分類，其實(shí)也可以按照其它維度進(jìn)行分類，這樣分類只是讓讀者能更加清楚低代碼包含的領(lǐng)域，有些客觀上的認(rèn)知

3、低代碼的構(gòu)成

講這塊內(nèi)容的時(shí)候，我們通過三個典型的公開可接觸到的平臺進(jìn)行舉例，分別是：阿里低代碼平臺、無極低代碼平臺、魔方低代碼平臺。

3.1、阿里低代碼平臺

按照阿里低代碼白皮書的描述，低代碼的架構(gòu)構(gòu)成自下而上分別是協(xié)議 - 引擎 - 生態(tài) - 平臺

• 底層協(xié)議棧定義的是標(biāo)準(zhǔn)，標(biāo)準(zhǔn)的統(tǒng)一讓上層產(chǎn)物的互通成為可能。

• 引擎是對協(xié)議的實(shí)現(xiàn)，同時(shí)通過能力的輸出，向上支撐生態(tài)開放體系，提供各種生態(tài)擴(kuò)展能力。

• 生態(tài)就好理解了，是基于引擎核心能力上擴(kuò)展出來的，比如物料、設(shè)置器、插件等，還有工具鏈支撐開發(fā)體系。

• 最后，各個平臺基于引擎內(nèi)核以及生態(tài)中的產(chǎn)品組合、銜接形成滿足其需求的低代碼平臺。

每一層都明確自身的定位，各司其職，協(xié)議不會去思考引擎如何實(shí)現(xiàn)，引擎也不會實(shí)現(xiàn)具體上層平臺功能，上層平臺的定制化均通過插件來實(shí)現(xiàn)。

3.2、無極低代碼

走了另一條截然不同的道路，從數(shù)據(jù)源開始，做表單配置映射，再到可視化拖拽，由數(shù)據(jù)模型驅(qū)動。雖然沒有從底層開始就定義協(xié)議，但是它由強(qiáng)大的數(shù)據(jù)基底作為架構(gòu)基石，再迭代到更靈活的可視化拖拽，也很自然且平穩(wěn)。而且由于數(shù)據(jù)源有足夠沉淀的基底，所以它在數(shù)據(jù)模型這塊能處理的事情會更多，除了簡單的數(shù)據(jù)CRUD，鏈表查詢，事務(wù)處理，SQL自定義查詢等能力眾多低代碼平臺的設(shè)計(jì)中也是比較靠前的。所以它能支撐的業(yè)務(wù)場景能更加復(fù)雜，且更加靈活。

但是作為偏科toB的平臺，在交互動畫方面相對就比較薄弱，且為了兼容大量的內(nèi)置事件以及數(shù)據(jù)聯(lián)動，它也犧牲了部分性能。所以回過頭來，我們在看看C端活動平臺的低代碼架構(gòu)設(shè)計(jì)。

3.3、MOKA低代碼

Moka低碼活動平臺是基于魔方編輯器進(jìn)行二次開發(fā)改造，而魔方編輯器官方提供的能力其實(shí)沒有代碼生成器這一說法，它的編輯產(chǎn)物是定義的DSL，再通過DSL生成頁面配置描述文件，最后描述文件給到固定的runtime版本進(jìn)行渲染。我們團(tuán)隊(duì)進(jìn)行移植后，增加了獨(dú)立的代碼生成模塊，能夠?qū)㈨撁娴恼w體積進(jìn)一步縮小，減少冗余的依賴。但其實(shí)做得還不夠，如果按照理想中編輯器跟代碼生成器的四個等級進(jìn)行劃分。

代碼生成器與編輯器之間的關(guān)系，可以大致分為這幾個層次：

•  Level 1：沒有代碼生成器的概念，或者極其粗糙；

• Level 2：有相對獨(dú)立的模塊用于生成代碼，但該模塊與編輯器耦合嚴(yán)重；

• Level 3：代碼生成器與編輯器基本相互獨(dú)立，具有同等地位；

• Level 4：插件系統(tǒng)與生態(tài)，編譯器必須再次抽象才能實(shí)現(xiàn)插件系統(tǒng)。

目前魔方處于Level1階段，還有很大的進(jìn)步空間。筆者所處團(tuán)隊(duì)通過結(jié)合阿里低碼的出碼模塊，已經(jīng)對內(nèi)部版本支持升級改造到Level2。但是距離Level3跟Level4依舊有不小的差距。

4、 樸素的程序開發(fā)三步驟

看完以上這些在各個業(yè)務(wù)領(lǐng)域比較有典型的低代碼組成架構(gòu)，其實(shí)也不難發(fā)現(xiàn)，低代碼平臺的構(gòu)成其實(shí)沒有明確的定義，如果真的要確定必要構(gòu)成的元素，可以回歸到程序設(shè)計(jì)的最樸素的三大步奏：布局、交互、數(shù)據(jù)

4.1、布局

布局就是按照 UI 設(shè)計(jì)稿或需求說明書里的草圖，把需要的組件逐個放到界面上，并按照要求排列整齊，形成程序雛形的過程。Pro Code 開發(fā)模式下的布局過程是極抽象的過程，開發(fā)人員需要把形象化的 UI 設(shè)計(jì)稿轉(zhuǎn)換為一行行抽象的指令，同時(shí)在腦海里想象這些指令的渲染效果。而在低代碼模式下，布局過程是非常形象的過程。我們可以利用低代碼編輯器的布局器，通過畫布上的拖拉拽，可視化地完成這一過程。而且，由于新手初次嘗試低代碼開發(fā)所做的事兒就是布局，所以拖拉拽往往成了大家對低代碼模式的第一印象。我們知道，不同類型的 程序，布局方式迥異，即使相同的程序在不同開發(fā)階段也有不同的布局需求。筆者認(rèn)為布局器最主要需要滿足兩方面的訴求，一是通用性，二是效率。

通用性是我們在低代碼編輯器研發(fā)早期主要關(guān)注的維度，隨著低代碼編輯器越發(fā)成熟，對效率的追求就逐漸超越了對通用性的追求。

流式布局器和絕對布局器都具有很好的通用性。但在布局初始階段，顯然采用流水的方式效率高，而在布局的后期，使用絕對布局器進(jìn)行精細(xì)化布局的效率更高。那么，我們將這兩種布局方式組合使用，就可以得到一個既高效又通用的布局器了。

組合聽似簡單，實(shí)際上非常依賴協(xié)議的實(shí)現(xiàn)。目前比較好的方式實(shí)現(xiàn)各種布局器的相互嵌套使用?？梢詫⒉季制靼b成了一種容器。容器也是一種組件，它具有組件的任何特性，但具備一個普通組件沒有的能力：它能裝得下其他組件或容器。目前市面上絕大部分低代碼其實(shí)都兼容該方式的做法。

4.2、交互

可視化編程解決的是應(yīng)用開發(fā)三部曲（布局、交互、數(shù)據(jù)）中的交互環(huán)節(jié)，簡單的交互可以理解為組件跟組件間的聯(lián)動，組件跟業(yè)務(wù)邏輯的聯(lián)動。常見的方式可以通過事件驅(qū)動，為UI組件設(shè)置事件（如點(diǎn)擊、懸停、輸入等），并定義在這些事件發(fā)生時(shí)要執(zhí)行的操作。例如，點(diǎn)擊按鈕后可以觸發(fā)數(shù)據(jù)提交或頁面跳轉(zhuǎn)。條件邏輯根據(jù)用戶的輸入或選擇來決定后續(xù)的操作。例如，用戶選擇某個選項(xiàng)后，可以顯示或隱藏特定的UI組件。這些都是基于組件級別的交互，那如果是邏輯層的交互如何做呢？

可視化邏輯編排，編碼時(shí)的流程邏輯是通過一行行代碼自上而下來體現(xiàn)，可視化邏輯編排需要對邏輯有不同的組織方式。一種比較常見的邏輯可視化組織方式是流程圖，通過流程圖的形式來表達(dá)一個邏輯過程是非常自然的想法。

下面這個流程圖，描述了一個訂單審批的過程，看上去邏輯是比較清晰的：

簡單的流程圖里包含了代碼邏輯的三種基本控制結(jié)構(gòu)：循環(huán)結(jié)構(gòu)、選擇結(jié)構(gòu)、順序結(jié)構(gòu)，并且這三種結(jié)構(gòu)在圖中的呈現(xiàn)和融合都非常自然。關(guān)鍵是，BOHM & Jacopini 早在 1966 年就從理論上證明了，只要能同時(shí)支持這 3 種結(jié)構(gòu)的流程，就可以表達(dá)任何復(fù)雜的程序邏輯。

通過可視化邏輯編排，實(shí)際上生成的代碼可能如下所示：

4.3、數(shù)據(jù)

程序開發(fā)中還有一個重要的環(huán)節(jié)，組件如何獲取和渲染數(shù)據(jù)。信息采集，就是要定義一個收集開發(fā)者配置信息的視圖。獲取數(shù)據(jù)的各個動作，需要采集的信息都大不相同，不同的個性化數(shù)據(jù)需要采集的信息也各不一樣。因此，在基礎(chǔ)動作中，這部分是抽象的，我們無法知曉具體該繪制啥樣的 UI，但可以約束具體動作采用什么方法來繪制 UI

子類可以將處理 UI 的所有邏輯，都封裝到動態(tài)渲染器中。信息保存是可以在基礎(chǔ)動作中直接實(shí)現(xiàn)的，只需要在基類中提供讀寫數(shù)據(jù)的 API 給子類使用即可

5、更好的低代碼平臺

最后講講如何做一個好的低代碼平臺，兜底能力也是很重要的。低代碼平臺不可能面面俱到，它總有能力邊界，但這個能力邊界不能束縛業(yè)務(wù)團(tuán)隊(duì)的探索。業(yè)務(wù)需要緊隨市場甚至引領(lǐng)市場，而市場是千變?nèi)f化的，任何公司都無法決定，所以要把“業(yè)務(wù)提出低代碼平臺能力之外的需求”當(dāng)做一種常態(tài)。此時(shí)，低代碼平臺需要有一種策略幫助應(yīng)用快速實(shí)現(xiàn)需求，哪怕直接上手編碼乃至 Hack。這樣的策略就是兜底策略。

即使在低代碼平臺成熟之后，使用純代碼作為一種兜底策略，依然是一種非常好的選擇。因?yàn)槿魏问虑槎继用摬涣?/span>二八原則，低代碼的可視化模式再好，也只能適用于 80% 的場景。剩余的那 20% 邊邊角角的場景，如果硬上可視化模式，反而可能吃力不討好，所以我們把那剩下的 20% 的場景留給純代碼來兜底，是一種很明智的選擇。

此外還有一些增值功能，包括 UI 設(shè)計(jì)規(guī)范自動對齊、提供 UI 設(shè)計(jì)稿轉(zhuǎn)代碼（D2C）能力、頁面的可維護(hù)性、頁面的埋點(diǎn) & 數(shù)據(jù)采集、程序的開源合規(guī)治理、程序的安全漏洞治理、程序的性能等等。簡單來說，這些都是低代碼平臺的亮點(diǎn)能力，并且是拉開與 Pro Code 差距的重要能力。