低代码的定义与发展历程
低代碼是一種軟件開發技術，可以大幅提升軟件開發效率，縮短軟件項目的交付周期。和許多軟件開發技術一樣，低代碼也不是“憑空產生”的，而是軟件開發技術發展的必然產物。在軟件技術發展史的尺度下觀察低代碼的誕生過程，能夠幫我們更深入地理解低代碼的定義。
一、低代碼的前序技術
低代碼技術是一種軟件開發技術，在高級語言的基礎上發展而來，集中體現了軟件開發技術的發展趨勢。從高級語言誕生到2010年代，軟件開發技術尤其是企業軟件開發技術呈現出組件化、框架化和可視化的發展趨勢，這些趨勢以及后續的“聲明式開發”、“程序合成”、“可視化編程”會對軟件開發帶來哪些改變？
1.1 高級語言開發的新探索
編程語言是每一位專業開發者最熟悉的概念，也是軟件技術發展史的重要見證者。
計算機誕生于1946年，計算機的核心部件是中央處理器（CPU）。計算機之所以能夠工作，是因為我們給CPU輸送工作指令。這里的工作指令就是機器語言，是由0和1組成的二進制串。機器語言可以被機器直接識別，但對人很不友好，非常繁瑣也容易出錯。在計算機誕生后不久，人們就發明了匯編語言。匯編語言參考了人類語言的符號，用助記符號代替二進制串。程序在執行前需通過編譯程序將匯編語言還原成機器語言，再輸送給CPU執行。匯編語言比機器語言更容易理解和編寫，但是它仍然高度依賴于機器語言，與CPU體系架構一一對應，不同的CPU都需要不同的匯編語言和指令集（CPU能夠識別的操作，如SSE指令集中用于比較字符串的pcmpistr，無法運行在不支持SSE的CPU上）。
隨后，語言發展到第三個階段：高級語言。在1957年，計算機專家發明了第一個高級編程語言Fortran語言，隨后陸續發明了BASIC、C語言、C++語言、Java語言等。高級語言是指面向用戶的語言，它與人類的語言規則更接近，比如，C語言當中有If … then … else …；Basic語言中的While … do等。這樣的語法和人類的語言表達方式基本相同。直到今天，新的語言仍然層出不窮，全球已經累計有幾千種高級編程語言。
從機器語言到高級語言，編程語言越來越接近人類的語言，學習和理解的難度逐漸降低，隨之而來的，還有編程工作效率的顯著提升。可以說，高級語言的生產力已今非昔比。在高級語言的基礎上，為了進一步提升軟件開發的效率，軟件開發行業做了很多有益的嘗試與探索，其中最成功的，當屬可視化、組件化和框架化三個方向。
1.1.1 組件化
組件（Components）伴隨著高級語言產生，它的本質是可重復使用的代碼。
當一段代碼可以在一個軟件中使用，也能成為另外一個軟件的一部分時，就可以被抽象成一個組件。組件的價值不僅僅在于提高代碼的復用性、提高開發效率，還通過組件化的設計，也降低了整個系統的耦合度，提高了系統的可維護性。
目前組件化的開發方式非常成熟，覆蓋面從文字輸入等基礎功能、統計函數等數據處理到報表等復雜應用場景。組件中涉及用戶交互的最為常見，也被稱作“控件”（Controls）。比如，開發者在前端頁面中開發類似Excel交互體驗的表格時，可以直接使用葡萄城提供的SpreadJS表格控件，而無需從零開始編碼處理表格繪制、公式計算、格式化等。
1.1.2 框架化
組件讓開發者可以復用代碼，而框架（Framework）則通過提升軟件的規范性來復用最佳實踐。
框架是指可被應用開發者定制的應用骨架。就類似人類的骨骼系統一樣，框架規定了應用的體系結構，闡明了整體設計、協作構件之間的依賴關系、責任分配和控制流程。
對于開發團隊，框架化的價值在于提供軟件的總體架構，簡化了設計工作，降低對軟件架構師的能力依賴，使得開發團隊即使沒有高水平的架構師，也可以讓軟件有一個很好的架構。同時，框架通過抽出非功能需求，讓開發者能更加專注于業務邏輯的實現，提升了開發效率?？傊?，框架本身就是最佳實踐的一個提煉和綜合，基于專業的框架進行開發可以有效保障大型軟件的處理能力、擴展性和可維護性。
1.1.3 可視化
“可視化開發”是上個世紀90年代軟件界最大的熱點之一，基于組件化和框架化發展而來。
最初的可視化專注于用戶界面開發領域，可以讓開發者通過拖拽的方式快速構建出用戶界面，一些成熟的產品甚至可以做到“所見即所得”。即便與最先進的高級語言對比，使用可視化設計開發圖形界面的生產率也能高出許多。
在品嘗到可視化的“甜頭”后，可視化開發的技術和工具迎來了大發展，其應用場景早已不僅僅應用于用戶界面設計。如今的可視化開發已經涵蓋了數據庫設計、工作流設計、業務邏輯設計等各個領域。
全局來看，可視化開發在提高開發效率的同時，還降低了開發的技術門檻，這就讓軟件開發團隊的構成有了更多的優化空間，如讓美工參與構建用戶界面，讓業務人員設計業務流程等。新的團隊構成除了能降低總體開發成本，還能通過減少溝通環節，提升軟件團隊的協同能力，加快軟件交付速度。
1.2 聲明式開發
上述三個探索方向的背后，是企業軟件開發技術的發展趨勢，即接受一定的性能開銷，換取軟件開發全生命周期的效率提升。如果將這些技術上的探索提升到工程層面，我們會發現其背后展現出的趨勢可以清晰地概括為一條：面向結果而不是過程。這一變化深刻地重構了軟件開發的模式，優化了從業務到計算機程序之間的“翻譯路徑”。
早期的高級語言編程以接近人類自然語言為設計目標，但實際執行中卻依然存在較大偏差。以“從一個名為list的數組中查詢name屬性為ping的元素，并將符合條件元素的value屬性添加到result數組中”這種范圍明確、邏輯簡單的場景為例，高級語言（Javascript）是這樣開發的：
for (var i= 0; i < list.length ; i++) { if(list[i].name=="ping"){ result.push(list[i].value); } }
上面的代碼是那些從后端編程語言轉行過來的開發者中常見的寫法，還有一些熟練的前端開發人員會這么寫：
list.forEach((d)=>{if(d.name=="ping") result.push(d.value)})
以上兩種做法，都可以在JavaScript的運行時中實現這個簡單需求。但這種做法“簡單粗暴”地定義了這一過程的每一步，包括與需求描述本身無關的臨時變量i，以及想result數組中添加元素的push、forEach方法以及Lamada風格的函數表達式。所以，我們將這種開發方式稱為“命令式開發”，覆蓋了從C到C++、C#、Java和Python等幾乎所有的高級編程語言。
但是，在需要長期維護的中大型企業軟件開發中，這種開發方式會遭遇如下挑戰，亟待新的開發方式來應對：
學習門檻：開發人員需要學習和理解更多的計算機原理知識，如循環、變量等和大量的語法、類庫和機制
平臺相關：這些技術細節與平臺高度相關，需要開發人員學習和掌握平臺的特性才能開發出更高效的代碼
規范性：不同開發人員對于計算機原理知識和平臺特性的理解不同、邏輯思維能力也存在差異，導致不同的開發人員為相同需求編寫出的代碼差異很大，規范性不強，人事風險高
可移植性：當平臺需要升級或更換時，大量的代碼無法直接復用，帶來更高的成本投入和項目風險
1970年代，隨著數據庫技術的提出和逐步成熟，一種全新的編程語言帶來的新開發方式受到企業軟件開發者的關注：結構化查詢語言（SQL）。以剛才的查詢為例，使用SQL的開發者中99%都是這樣寫的：
SELECT value FROM list WHERE name='ping';
相比于命令式開發，SQL語言屏蔽了除了需求之外的大量細節，僅需要描述出我們需要數據庫需要實現的“效果”即可驅動計算機完成這項工作。這種面向結果而不是過程的開發方式，被稱為“聲明式開發”。與命令式開發相比，聲明式開發最大的技術優勢是通過隔離技術細節，在降低開發者學習門檻的同時，實現了更廣泛的跨平臺，包括同一平臺的升級和兼容平臺間的切換。此外，在管理層面，聲明式開發還通過提升規范性來管控開發者間編碼習慣的差異，降低維護成本和人事變動帶來的風險。
1.3 程序合成
聲明式開發除了在技術層面提升了軟件全生命周期的開發與維護效率，更重要的是為企業軟件開發技術領域開啟了新的方向：程序合成（Program Synthesis）。
中國第一批軟件專業博士生導師徐家福教授為軟件開發技術的發展方向指出了明確的發展方向，即“軟件自動化是提升軟件生產率的根本途徑”。而軟件自動化的本質是程序合成，即從根據特定的規約自動生成可運行的程序。
從這張圖片中我們不難看出，程序合成存在三個重大課題：（1）規約：以某種形式規約表達的用戶意圖。（2）程序：以某種程序語言表達的程序空間。（3）合成器：在程序空間中運用某種搜索技術找到符合用戶意圖的程序，整個程序合成領域就是圍繞著這三個維度展開研究。具體落地時，我們發現其中最關鍵的挑戰是規約很可能是模糊的、不完備的，質量難保障。
1.3.1 演繹合成
在程序合成的早期，我們為了確?！耙幖s”的質量，采用了演繹合成（Deductive Synthesis）的方式，即要求開發者用一種完整的邏輯形式規約的方式編寫用戶意圖，然后轉換為程序。這里的規約可以是“命令式開發”中的邏輯語言，這種做法可以類比于翻譯工作，即將一種編程語言轉義為另一種語言最終生成程序，就像開發者使用Visual Studio編寫C#代碼，然后將其編譯成IL最終組裝成運行在.NET運行時上的程序，給最終用戶使用；也可以是“聲明式開發”中的描述語言，就像上文中介紹到的SQL一樣，開發者編寫SQL語言（即數據查詢的規約），由數據庫承擔合成器的職責將SQL解析并執行，最終形成一個程序，給最終用戶提供數據查詢的能力。
不論是哪種規約，這種做法讓我們獲得了更高層的封裝和復用，相比于針對特定平臺的C++編碼，效率有所改善，但這種做法的自動化程度偏低，有很大的提升空間。
1.3.2 歸納合成
2000年后的程序合成開啟了歸納合成（Inductive Synthesis）的方式。輸入不再是完整表達邏輯的形式規約，替代為用戶友好的輸入輸出示例（I/O examples）、非完整的邏輯規約（僅表達輸入輸出之間關系，不表達內部邏輯）等。從演繹合成到歸納合成，代表用戶意圖的規約從完整、清晰變得模糊，因此演繹推導的合成方法不再適用，我們需要使用搜索技術在有限程序空間中合成一個滿足規約的程序。然而通用的高級程序語言（GPL）非常復雜，近乎是一個無限大的程序空間，這大大降低了搜索的效率。為了縮小程序空間，程序合成領域進行了大量嘗試，最終，領域專用語言（DSL）方案勝出。
DSL方案中，我們首先需要針對不同的領域設計差異化的DSL，DSL中僅包含有當前領域的內容，在具體形式上，大部分DSL充分借鑒了聲明式開發的設計思想，比如網頁呈現領域的HTML還有上文中提到的數據查詢領域的SQL都是如此。在基于DSL的歸納生成方案中，我們需要做的事情是基于DSL的特性設計出更簡化的規約，并為之匹配合成器，完成從規約到DSL的轉換。最終DSL將作為元數據，被程序加載和運行，實現程序合成的最終目標。
截止2020年代，歸納合成主要應用在DSL相對成熟的數據分析和界面原型構建中，而在業務邏輯和動態策略等領域依然處在研究階段。在研的技術路線中，AIGC更值得行業關注。部分學者認為，AIGC在業務邏輯和工作流等領域，即將具備DSL方案的落地能力，甚至在GPL方案中也有一些可喜的成果。
1.4 可視化編程語言（VPL）
程序合成技術的落地需要新一代的人機交互方式，充分利用聲明式開發的優勢，幫助開發者用更高的效率完成規約的編寫工作。可視化編程語言（VPL）應運而生。但是針對不同的細分場景，可視化編程的實現方式也各有不同，但大部分都采用了“演繹合成”的范式，即開發者在可視化開發環境中用VPL完整描述規約，合成器根據這些規約將其轉義為GPL或DSL，最終生成可運行的程序。
1.4.1 通用性業務邏輯的可視化開發
通用性業務邏輯包含了頁面交互的響應、數據校驗、數據生成、數據交換、統計計算等場景。從原理上講，基于高級語言的可視化開發本質上是代碼生成器，即將用戶可視化設計的規約直接“翻譯”成通用高級語言（GPL），采用的是程序合成中的“演繹合成”范式。在DSL并不夠成熟、或通用性較強的領域內，這種技術方案無可厚非。即便采用演繹合成，相比于傳統的編碼開發，可視化開發也能展現出足夠的易讀性、規范性等優勢。
考慮到企業軟件中業務邏輯本身對正確性、完整性、可讀性、可維護性的高要求，演繹合成范式更值得開發者信賴，雖然這種可視化開發方式依然需要受過編程訓練的專業人員來操作。
1.4.2 工作流的可視化開發
在企業軟件中，最典型的業務邏輯是單據流轉、審批生單等工作流。針對這種廣泛的需求，面向工作流領域的DSL：BPMN誕生并沉淀成為行業標準。很快，這種DSL被引入到可視化編程中，并成為了VPL中影響最廣的類型之一。
值得一提的是，BPMN采用了“聲明式”的設計思想，與自然語言更貼近，學習門檻也顯著低于高級語言（這也是大部分DSL相較于GPL的重要優勢）。目前，BPMN通常由IT專業人員或受過培訓的非IT人員使用可視化開發工具，以拖拽的方式完成開發。另一方面，行業正在積極嘗試引入AIGC，以自然語言對話的方式完成程序生成過程，即從“演繹生成”升級為“歸納生成”，取得了一些成果但距離落地還有諸多挑戰。
1.4.3 用戶界面的可視化開發
用戶頁面的可視化開發是可視化開發的“傳統領域”，我們在高級語言開發的技術探索中重點介紹了可視化開發的應用成果。這里不再贅述。
用戶界面的可視化開發通?；谔囟ńK端或跨終端的DSL，如Web瀏覽器的HTML、Windows桌面應用的xaml等。這些DSL均為聲明式設計思想的產物，在設計時優先考慮頁面設計人員而不是開發人員的使用習慣，如將頁面劃分為行、列，并通過各種排列規則來完成頁面元素的整體布局。這種設計對“所見即所得”式開發非常友好，學習門檻比上文中的BPMN更低，相比于高級語言開發所呈現出的效率優勢也更明顯。
1.4.4 其他細分領域的可視化開發
截止目前，可視化編程語言已經覆蓋了企業軟件的全部模塊，除了上述三種，還有以下類型值得關注：
數據流：可視化定義數據處理管道中各環節的操作邏輯，通常用于數據治理
狀態機：定義某一個狀態到下一個狀態的轉換策略，通常用于自動控制
時間線：定義關鍵幀和關鍵幀之間的轉換效率，通常用于界面動畫
1.5 小節
在高級語言誕生后的數十年里，采用“聲明式開發”的“可視化編程語言”，正在逐步將“程序合成”的理念，從學術變成現實，大幅提升了軟件的開發生產力。
這一切都在孕育著軟件開發技術領域的一次重大變革。
二、低代碼的定義演化
低代碼的概念提出于2014年，但是從技術層面上看，這并不是一項全新的軟件開發技術；同樣冠以“低代碼”，開發技術的實現路徑與應用場景也不相同。
2.1 低代碼是一個商業概念
與“程序合成”這種學術概念、“可視化編程語言”這種技術概念不同，“低代碼”是一個商業概念，是對若干軟件開發技術的總結與歸納。低代碼概念最早出現與Forrester Research發表于2014年6月的一篇行業研究報告《New Development Platforms Emerge For Customer-Facing Applications》，作者在報告中將通過顯著降低手工編碼來提升應用交付效率的新平臺稱為“低代碼”?；氐?014年，低代碼對應的技術概念是可視化編程語言（降低手工編碼）和程序合成，均為相對成熟的技術和明確的發展方向。將成熟的技術冠以一個全新的商業概念，吸引投資界的關注和公眾的目光，最終達成推動該技術成熟和普及的目標，低代碼無疑是有一個成功案例。
2018年，葡萄牙的低代碼廠商Outsystems獲得了KKR和高盛3.6億美元的投資并將估值推高到10億美元后，低代碼這個企業軟件下軟件開發技術細分領域的的“黑馬”終于走到了臺前，可以和互聯網領域的新秀同場競技。2018年也被稱為低代碼的“奇點”，從這一年起，低代碼概念下出現了大量的高估值、大投資新聞，吸引海量廠商進入，堪稱軟件開發技術甚至企業軟件的高光時刻。
2020年，在互聯網投資的推動下，國內的低代碼開始井噴。除了傳統的軟件開發工具廠商和新創建低代碼廠商外，ERP、OA、BI甚至云服務商都推出了自己的低代碼產品，開始跑馬圈地。
2021年底，低代碼概念的提出者Forrester Research甚至在其官網“Low-Code Platform”詞條下加入買家警示：低代碼行業存在嚴重炒作的描述，并且基于對中國低代碼市場的調研提出了兩種路線、九大廠商類型的賽道細分，對買家選型提供指導和幫助。
本文重點關注低代碼技術領域，僅針對兩種技術路線做展開介紹，兩者的主要差異是可視化編程語言的覆蓋度。
2.2 低代碼：模型驅動路線
模型驅動的低代碼又稱面向業務開發者的低代碼開發平臺，數據與邏輯完全分離、各自獨立，是可視化開發技術發展的產物，體驗上承襲了傳統軟件開發的生命周期，也被稱為“狹義的低代碼”。
模型驅動的低代碼專注于構建完整的企業軟件，與高級語言開發形成一定的替代關系。在技術上，可視化編程語言覆蓋了數據庫、工作流、業務邏輯、用戶交互、系統集成等全部類型，尤其是在復雜業務邏輯的可視化構建上有顯著優勢。
典型代表有西門子（Mendix）、Outsystems、葡萄城（活字格）、ClickPaaS。本賽道的產品研發門檻較高，商業模式對知識產權付費環境的要求高，目前以國外廠商為主，國內廠商數量較少。
2.3 無代碼：表單驅動路線
將數據與業務邏輯合一的表單驅動低代碼，衍生于ERP、OA中廣泛使用的可配置化技術，使用體驗類似于成品軟件的實施。從市場宣傳角度看，大部分表單驅動的低代碼開發平臺采用了“無代碼”的宣傳口號（本站部分頁面以“無代碼”代指“表單驅動的低代碼平臺”）。
無代碼專注于構建簡單的企業軟件，填補高成本軟件的空白。在技術上，可視化編程語言主要覆蓋表單、工作流兩種類型，應用場景以OA審批、數據填報等輕應用為主。如果需要構建復雜的業務邏輯和用戶交互，則需要通過高級語言編碼開發來實現。
典型代表調有捷德（Joget DX）、輕流。本賽道與“互聯網思維”貼合度高，深受國內互聯網投資機構歡迎，廠商和數量占優勢，但經營持續性風險較高。
2.4 小節
低代碼最初定位于可視化編程語言、程序合成等技術概念的商業化封裝。這種商業化運作為低代碼乃至整個企業軟件開發技術領域帶來了海量的投資和資源，很大程度上推動了該技術的快速發展。隨著互聯網投資的進入，低代碼行業分化明顯，形成低代碼和無代碼兩條主要技術路線。低代碼和無代碼面向不同的應用場景，不存在演化關系，也沒有絕對的優劣可言。
但因為低代碼與無代碼的差異性較大，國際主要的研究機構在研究和評估低代碼與無代碼技術時采取了不同的方法。中國信通院針對這兩種技術分別設定了行業標準，強調了它們之間的差異。在低代碼開發平臺方面，模型驅動被視為基礎要求。此外，針對低代碼平臺，區分了面向業務開發者的表單驅動平臺和面向專業開發者的模型驅動平臺。
三、低代碼的技術能力現狀
經過數十年的發展，低代碼的技術能力已逐步清晰，主流的低代碼產品在產品能力和設計體驗上也有趨同的傾向。
3.1 系統組成
低代碼開發平臺通常由4部分構成：
可視化設計器：具備可視化定義UI，工作流和數據模型的設計器，且在必要時可以支持手寫代碼。
服務器程序：承載可視化設計器構建的應用，供最終用戶通過多終端訪問，具體形式如私有化部署的服務程序、運行在云端的容器或服務等。
各種后端或服務的連接器：能夠自動處理數據結構，存儲和檢索。有些低代碼開發平臺將其集成到了可視化設計器中。
應用程序生命周期管理器：用于在測試、暫存、構建、調試、部署和維護應用程序的自動化工具。
3.2 核心能力
經過多年的發展，超百家廠商推出了大量的低代碼開發平臺產品?？v觀這些低代碼平臺，除了都具有這些基本要素以外，沒有兩個產品是完全相同的。有些工具作用非常有限，更類似于與數據庫配套的前端界面，如90年代的FoxPro；有些工具則僅專注于小眾的業務需求，如客戶檔案管理；甚至有一些專用工具只是用低代碼的術語來描述，但與實際的應用程序開發幾乎沒有關系。為了與其他軟件開發技術進行區分，避免對IT決策者帶來誤導，Gartner將低代碼的概念具體化，提出了低代碼開發應用范圍（構建包含有用戶界面、業務邏輯、工作流和數據服務的完整軟件應用）。針對企業級軟件開發，Gartner還提出了低代碼開發平臺所需的必備功能。
Not be used only or mainly for building specific industry applications, and it must not be only a product bundled within some other solution or platform. 不能僅用于或主要應用構建特定行業的應用，不能僅限于在依賴其他解決方案或平臺上運行
Support development and deployment of applications by professional developers in both central IT and line of business — not just for citizen developers. 需要能提供給IT技術人員使用，不能只給平民開發者使用
Develop, version, test, deploy, execute, administer, monitor and manage the applications and their relevant artifacts. 全生命周期：覆蓋應用和相關資源的開發、版本管理、測試、部署、執行、管制、監控和管理的全生命周期
Embed data storage features without relying on additional procured services (i.e., includes a database). 內建數據存儲：內建數據存儲機制，不能依賴其他的數據庫等存儲服務
Support the design of data schema and application logic. 數據與邏輯設計：支持用來設計數據結構和應用邏輯
Create rich application UIs (i.e., not only a forms builder or building an administration UI). 完整的界面設計：支持創建完整的應用界面，不能僅支持創建表單或管理界面
Enable the invocation of external third-party services via APIs or event topics. 第三方集成：支持引入第三方API或事件驅動機制
Support some automation of platform patching and versioning. 自動運維：提供自動化的應用升級和版本管理機制
Provide single-step deployment across environments (development, test, staging, production). 多環境部署：支持針對多環境的一鍵部署，包括開發環境、測試環境、驗證環境和生產環境
Access a platform repository or marketplace for sharing components, modules, connectors and templates 社區共享：提供可供訪問的應用市場，用來共享組件、模塊、連接器和模板