1. 低代碼的概念由來

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

如果有研究過計算機程序語言發展史的同學，應該有聽聞第一代編程語言 （1GL）到最新的第六代編程語言（6GL）的藍圖，每一代升級都是生產力的提升，到了第四代其實初見“低代碼”的端倪。但是還沒有正真提出“低代碼”這一概念。

低代碼概念需要借助低代碼開發平臺這一工具實現。維基百科將低代碼平臺定義為一種提供開發環境的軟件，基于低代碼平臺開發者不需要使用傳統的手寫代碼的方式進行編程，而是可以通過低代碼平臺圖形化的用戶界面和參數設置來創建應用軟件。

低代碼平臺面向的用戶群體是無需專業開發能力的企業業務人員和一部分專業開發人員。HR 、財務、銷售等業務人員完全可以自己或者在技術 人員的指導下開發出更符合特定業務工作需求的應用程序，而專業技術人員則可通過可視化、流程化的開發方式，實現相比于純代碼模式更高效的開發。

單純從這些公開的信息，其實也無法直觀的了解啥是低代碼，在筆者看來低代碼不是一項具體的技術名稱，它是一個技術領域的統稱，是屬于其中一種程序開發模式。

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

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

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

純代碼（Pro Code）純代碼開發是指使用傳統編程語言（如Java、Python、C#等）進行軟件開發的方式。開發者需要具備編程技能，能夠手動編寫代碼來實現功能。它的特點具有：靈活性 - 開發者可以完全控制代碼的每一個細節，能夠實現復雜的業務邏輯和功能；可擴展性 - 可以根據需求進行高度定制，適合大型和復雜的項目；學習曲線 - 需要較高的技術門檻，開發者需要掌握編程語言、框架和工具；維護性 - 代碼的可讀性和可維護性依賴于開發者的編碼習慣和團隊的規范。Pro Code 和 No Code 實際上都很好理解，一個是純代碼，一個是無代碼。假設 Pro Code 的代碼量是 100，那 No Code 就是 0，所以 Pro Code 和 No Code 是截然不同的，甚至你可以認為這兩者毫無關系。No Code 的最典型形態莫過于 SaaS 類的產品了。

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

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

    A，Arrangement in graphical，圖形化編排，基于圖元或其他形式的節點信息，通過連接、排布等方式表達流程、時序等信息。

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

低代碼的構成公式

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

無代碼的構成公式

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

嚴格來說，把采用無代碼模式生成程序的過程稱為開發是不恰當的，因為它只是對已有原子業務能力進行二次組合，形成具有特定功能的新業務而已。因此從這個角度來說，低代碼和無代碼完全不是一種東西，切不可將這兩者混為一談。

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

Low Code 是采用無邏輯的結構化數據來描述業務的，對于相同業務，Low Code 的描述能力要弱于有邏輯的 Pro Code。所以，Pro Code 都做不到的事情，Low Code 當然也做不到。如何有效解決強邏輯場合下的可視化配置方法，這是 Low Code 采用無邏輯的結構化數據描述業務常見的重要短板。

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

所謂通用，指的是開發平臺不事先假設自身只能應用在特定的場景、業務、行業，而是具有廣泛的適用范圍。具有這樣特征的開發平臺往往需要有一個通用的底座。這個底座是純技術性的，它不依賴于特定的業務功能，而只與業界廣泛使用的標準協議、技術標準產生耦合。不過，這個時候，我們只有深入平臺架構實現的細節，才能判斷平臺到底是低代碼還是無代碼，這就導致平臺的使用者難以甄別。

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

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

2.3. 按業務類型來分類

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

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

這里，主要區分一下表單驅動型和模型驅動型這兩個類型，因為它們比較容易混淆。

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

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

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

如果按照使用者的類型進行分類，我們可以將開發平臺的使用者分為 3 類：專業技術人員，業務技術員，相關無專業技能人員。

這里所說的業務技術員是一種正在興起的角色，它是指構建供內部和外部業務使用的技術或分析功能的非 IT 部門員工。他們擔任著裝備和賦能非 IT 資源以構建數字化能力的戰略角色。

多數的無代碼開發平臺將業務技術員作為主要的用戶群，為他們提供對已有業務的二次組合為主的基礎開發能力，一般具有專業技能的開發人員是不會使用無代碼開發平臺的，因為專業技能者要面對的問題域已經大大超出了無代碼平臺的能力范圍。

而低代碼開發平臺一般會將專業技術人員和業務技術員同時作為他們的客戶群，并以專業技術人員為主要用戶群，業務技術員為次要用戶群。

隨著低代碼開發平臺的成熟度上升，業務技術員用戶群的占比會有所上升。因為成熟度高的低代碼平臺，不僅有各式各樣的可視化工具來降低業務研發的難度和代碼量，同時對業務研發生命周期各個環節的覆蓋也會越來越完整。從開發到測試，從測試到上線，再到高容錯運行時自動化部署 / 恢復、運行時自動化運維等各個環節的可視化、自動化完成，這為無 IT 技能的業務技術員獨立開發提供了可能性。同時，越發完善的可視化自動化能力不僅會牢牢抓住已有的專業技能用戶，還會吸引更多的專業技能用戶的加入。

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

總結以上分類，我們的大致脈絡圖如下：

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

3、低代碼的構成

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

3.1、阿里低代碼平臺

按照阿里低代碼白皮書的描述，低代碼的架構構成自下而上分別是協議 - 引擎 - 生態 - 平臺

• 底層協議棧定義的是標準，標準的統一讓上層產物的互通成為可能。

• 引擎是對協議的實現，同時通過能力的輸出，向上支撐生態開放體系，提供各種生態擴展能力。

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

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

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

3.2、無極低代碼

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

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

3.3、MOKA低代碼

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

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

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

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

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

• Level 4：插件系統與生態，編譯器必須再次抽象才能實現插件系統。

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

4、 樸素的程序開發三步驟

看完以上這些在各個業務領域比較有典型的低代碼組成架構，其實也不難發現，低代碼平臺的構成其實沒有明確的定義，如果真的要確定必要構成的元素，可以回歸到程序設計的最樸素的三大步奏：布局、交互、數據

4.1、布局

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

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

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

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

4.2、交互

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

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

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

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

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

4.3、數據

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

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

5、更好的低代碼平臺

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

即使在低代碼平臺成熟之后，使用純代碼作為一種兜底策略，依然是一種非常好的選擇。因為任何事情都逃脫不了二八原則，低代碼的可視化模式再好，也只能適用于 80% 的場景。剩余的那 20% 邊邊角角的場景，如果硬上可視化模式，反而可能吃力不討好，所以我們把那剩下的 20% 的場景留給純代碼來兜底，是一種很明智的選擇。

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