什么是低代碼，它的平臺又是怎樣的？

這篇內容我們來說一說低代碼，與某種具體技術不同，對于低代碼的概念，業界至今沒有達成一致意見（我估計以后也不會，這是低代碼被賦予的職能決定的）。

但作為低代碼的接觸著，甚至是架構者，我們需要對低代碼平臺到底是什么有一個清晰且深入的了解。這篇內容里，我會通過對低代碼平臺進行歸類帶你厘清低代碼的概念，并帶你分析當前低代碼的發展現狀，讓你在腦海里建立起對低代碼的直觀印象。

在這里所說的內容都側重于低代碼的架構、策略和技術的實現。所以，對低代碼是啥理解得越清楚，相應地，你就越容易理解我所作出的架構和策略的選擇，以及為啥要采用特定的技術實現選型。反之，在概念理解有誤的情況下，后續的內容有可能使你陷入目標與執行相互矛盾的困境，難以自拔。

什么是低代碼？

要講清楚一個模糊的概念，一個有效的手段就是先應該嘗試對它，以及相關的概念進行歸類，然后比對，從比對中得出關鍵差異。

但要對低代碼做分類，并不容易。由于低代碼概念和內涵未達成一致，業界對它進行歸類的方式也多種多樣。這里，我以我理解的低代碼的幾個重要特征作為維度，對低代碼進行歸類，同時你也能通過這些分析，了解我們這門課要實現的低代碼平臺到底是啥樣的。

按代碼量的維度來分類

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

這三者有著巨大的差別，我們需要非常準確地將它們分開。純代碼是這個維度下的一個基準概念，它指的是傳統的手工編碼的模式開發應用。而低代碼和無代碼比較容易搞混。

從中英文字面上說，無代碼意味著 App 的開發過程沒有代碼的參與。但是這樣的理解比較粗淺，為了獲取更加權威的理解，我嘗試從頭部分析機構 Forrester 和 Gartner 所發布的報告中，查找與無代碼相關的調查報告，但一無所獲，不知道是不是這些頭部機構并不認可無代碼這個概念。

低代碼模式下的 App 開發過程是需要有代碼參與的，特別是面對一些復雜的業務邏輯，通過表達式或者直接編碼的方式來表達，反而更加清晰。而無代碼模式開發 App 的全過程，沒有任何代碼的參與，不僅是從開發者角度看是這樣的，從無代碼內部的實現方式看，也是這樣的。

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

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

在代碼量這個維度下，我們專欄所說的低代碼是指這 3 個分類中的“低代碼（Low Code）”這一類。

按適用范圍的維度來分類

這個維度下，低代碼平臺可以分為專用型和通用型兩種。

所謂通用，指的是開發平臺不事先假設自身只能應用在特定的場景、業務、行業，而是具有廣泛的適用范圍。

具有這樣特征的開發平臺往往需要有一個通用的底座。這個底座是純技術性的，它不依賴于特定的業務功能，而只與業界廣泛使用的標準協議、技術標準產生耦合。不過，這個時候，我們只有深入平臺架構實現的細節，才能判斷平臺到底是低代碼還是無代碼，這就導致平臺的使用者難以甄別。（注意，我這里的目的不是想告訴你如何甄別，而是為了告訴你這里所說的低代碼平臺具有的特征）

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

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

這個維度下，這門課所說的低代碼指的是通用型開發平臺，它具有一個通用性非常高的底座，和一個相對完善的插件機制。

按輸出的 App 的類型來分類

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

盡管我們這門課所說的低代碼指的是“通用型”這一類，但這并不影響我們看看現在業界其他低代碼平臺都可以輸出哪些類型的 App，大概有流程驅動型、表單驅動型、模型驅動（ORM）型、BI 分析類型這幾種，具體你可以看看這張表格（5 星為滿分）：

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

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

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

按使用者的類型來分類

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

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

根據 Gartner 的研究：41% 的員工可以被稱為業務技術人員，不過這一比例在不同的行業可能存在很大的差異。例如在政府部門等技術密集度較低的行業，這一比例接近 25%，但在能源等 IT 密集型行業，這一比例接近 50%。

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

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

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

這個維度下，這里所說的低代碼是以專業技術人員為主要用戶群的一類平臺。不過，在寫這篇文稿的時候，我負責的低代碼平臺正在努力將業務技術員納入到它的用戶群中，但是這項工作才剛起步不久，當前尚沒有特別成熟的經驗可以分享。但這是一個動態專欄，在未來幾年會保持更新，我會在合適時機，及時把我在拓展更多用戶群方面的經驗分享給你。

現在我們來總結一下，這篇內容要實現的低代碼平臺到底是怎么樣的。它是一個以專業技術人員為主要用戶群的通用型低代碼平臺，它會有一個通用性非常高的底座，和一個相對完善的插件機制。

我這里還要再解釋一下，在后續的內容中，我可能還會提到低代碼工具和低代碼平臺，對于這兩個概念，我所指的內涵是一致的，區別就在于規模和成熟度。低代碼工具指代規模較小、成熟度較低的低代碼實現，而低代碼平臺則指代規模較大、功能較完善、程度較高的低代碼實現。

了解了行業內對低代碼的幾個分類，以及我們這門課的低代碼平臺的定義后，我們再來簡單看看低代碼的歷史演進和現狀，讓你對低代碼和低代碼行業有更進一步的理解。

低代碼的發展

在低代碼的發展上，我們可以從基礎設施的演進、時間和地域，以及中臺的演進這三個方面一探究竟。

我們先從基礎設施演進看低代碼的發展，你可以先看看下面這張圖：

長久以來，軟件的基礎設施都是純物理設備，自當虛擬技術被引進，IaaS（基礎設施即服務）時代就開始了。緊隨著虛擬技術繼續蓬勃發展，沒過多久，軟件技術便歷經了 PaaS（平臺即服務）時代、SaaS（軟件即服務）時代。關于這幾個概念更具體的解釋，你可以看下補充材料的內容。

SaaS 類產品高度封裝的軟件服務為行業提供了巨大便利的同時，人們也漸漸發現這種形式的短板：定制性太弱。因此在 SaaS 的基礎上，又演進出了一種被稱為 aPaaS 的軟件服務體系。

根據 Gartner 的說法，aPaaS 是應用程序平臺即服務的縮寫，它是一種云服務，可為應用程序服務提供開發和部署環境。aPaaS 平臺提供的功能包括：迭代構建應用程序、即時提供應用軟件、按需擴展應用程序，以及集成應用程序與其他服務。

很明顯，Gartner 把這里的 a 作為 application 理解了。但我個人認為，這里的 a 當做 ability 來理解更為恰當，借用文言文的使動用法，將它翻譯為賦能。因為很明顯的，aPaaS 體系相比其他架構就是多出來了一個開發和部署應用程序的能力，即 aPaaS 賦予了原來的軟件服務體系開發和部署的能力。

我們再換個角度，從時間和地域來看低代碼的發展。

下面這張來自艾瑞咨詢的圖片總結了這個過程，圖中信息量比較大，你可以點開仔細閱讀。

我們可以從這組比對數據中明顯看到，國內的低代碼平臺要落后于美國一個時代。現在低代碼頭部解決方案中已經有類似 OutSystem、Microsoft 這樣的通用型低代碼巨無霸，而國內多數提供商還在探索如何有效地為某個垂直行業、細分領域提供低代碼服務。但這對你我這樣的低代碼人來說，實際上是一個好事，這仍是一片藍海，大有可為。

第三種角度就是從中臺演進來看低代碼的發展。這里你可能會覺得很奇怪，為啥低代碼又和中臺扯到一起了呢？

這是因為，低代碼可以將多個“煙囪系統”歸整為一個集大成者，更靈活敏捷地創建中臺架構。在傳統的企業系統中，每個部門有不同的系統需求，于是會各自采購自己的系統。但這些系統彼此孤立，獨立運作，導致企業采購的軟件系統冗雜。而低代碼平臺能讓絕大部分部門的業務系統都能在一個平臺里搭建，彼此聯系，打破信息系統孤島，同時降本增效，提升內部生產力。

低代碼有助于橫向打破傳統企業的煙囪系統，將它們串聯到一起，這與中臺的目標不約而同。此外，低代碼對外賦能的職能，也是中臺建設目標之一。因此中臺的發展過程，有相當一部分線路與低代碼是重合的，二者可以起到相互促進，良性共生的關系。所以，如果你所在的企業同時在架構中臺和低代碼這兩者，不妨嘗試將他們放到一起來考慮。

行業狀態速讀

了解了低代碼的發展和演進之后，作為低代碼的研究者，我們總得關心下當前低代碼的行業現狀吧？

不過，網上這方面的信息實在太多了，多數說的有鼻子有眼，但不知道真假，所以我只看專業調查機構輸出的報告。其中我主要關注 Forrester 和 Gartner，以及國內的艾瑞咨詢，相關的報告鏈接我都統一附在了文末的補充材料中。

在這么多報告里面，我首先要向你推薦的就是 Gartner 繪制的關于低代碼的魔力四象限報告，關鍵部分就是下面這張圖，概括性非常強。

作為低代碼的實現者，一般看這種報告都是以競品調研為目的的，因此我們一般只研究 Leader 象限里的提供商就可以了。Leaders 這個象限顯示的是技術能力較強、對未來的規劃很清晰的廠商，其產品被市場廣泛認可，對我們有極強的參考價值。

其次我想向你推薦的是 Forrester 的 Forrester Wave 報告。與分析 Garter 的魔力四象限相似，我們仍以 Leader 這一波里的廠家作為我們的調研對象。與魔力四象限的結果比對，你發現了啥？

兩家機構對低代碼的 Leaders 給出了幾乎一樣的結論，對吧？在 Leaders 里，頭部機構取得了一致意見。這兩份報告為我們低代碼平臺的競品調研給出了一個非常明確的指引，所以如果你現在還在頭疼不知道如何下手做調研的話，他們就是極佳的研究和參考對象。

那么國內的廠商是啥樣的狀態呢？

我同樣有兩份報告可以推薦給你：一個來自 Forrester 的報告《The State Of Low-Code Platforms In China》（下文簡稱中國報告），另一個來自艾瑞咨詢的《艾瑞咨詢 -2021 年低代碼行業研究報告》（下文簡稱艾瑞報告），你可以在這一講的補充材料中找到原文。

在《中國報告》中，Forrester 第一次將視角聚焦在中國，它認為，低代碼目前在國內主要應用于銀行、保險、零售、醫療、政府、制造、電信和建筑行業。Forrester 認為，國內低代碼目前主要集中在如下 9 個領域，分別有：

而《艾瑞報告》的信息量就更大了，主要包含了概念界定、應用場景、競爭要素、市場規模、趨勢洞察四大塊的內容。下圖是《艾瑞報告》繪制的低代碼廠商圖譜，非常概要地整理出了國內外低代碼廠商的分類。

大體上，《艾瑞報告》把低代碼廠商分成了通用型和垂直型兩種，垂直型和我前文所說的專用型是類似的，均指只能應用在某個業務領域的低代碼解決方案，無法運用到其他領域。

無論你是要做競調，還是打算采購，這個圖都可以提供不錯的指引。

大小廠商這么多，也從一個側面反映了低代碼在國內的發展仍處于早期的狀態，按照“慣例”，風口褪去后，各個廠商會快速聚集，要么大魚吃小魚、要么抱團取暖，形成寡頭化的局面，當前還處于“百花齊放”的狀態，說明低代碼仍處于投資風口，風投時不時來“奶”上一口，所以大家都還能堅持得住。