1. 前言

過去的 2021 ，世界依然被 COVID-19 肆虐導致線上業務需求激增，低代碼平臺在此節點上進一步爆發，并在疫情防控及諸如醫療、餐飲、金融、制造的多個行業領域得到應用推廣。

回想 2020 疫情暴發初期，為了更好地追蹤人員流動、新冠病毒肺炎感染者與接觸者的情況，阿里釘釘聯動阿里云、支付寶、達摩院、政務釘釘、宜搭等團隊，在短短一天時間內就搭建出浙江省新型肺炎公共服務與管理平臺，并緊接著在湖北、湖南、貴州、河南等 28 省、自治區、直轄市協助搭建了 數字防疫系統 。在同一時間段，北京市海淀區也通過與致遠互聯合作，只用了一天時間即上線 海淀防疫上報管理平臺 。

一款應用得以及時配合疫情防控情勢實現快速上線，除了各方協力配合，低代碼平臺也在其中發揮了重要作用。簡單來說，低代碼指的是利用更少的手工編碼來完成軟件開發，主要是通過將普遍的、共性的代碼能力封裝為一個個可視化組件，搭建者可根據自己的需要進行選擇，從而自主開發出相關應用。疫情防控應用之所以能短時間搭建完成，背后就是企業通過自身的應用定制平臺來完成 組裝 。

隨后 低代碼 便接力 中臺 成為新的 IT 熱點，引發了眾多業內人士的論戰。其中有兩種極端的觀念，一種是 偽需求：通過 自降身價 、低端炒作 迎合資本，吸引更多的資本進入這個行業來滿足資本逐利的需要；另一種是 顛覆行業 ：利用低代碼平臺快速、靈活的特點只能實現簡單、基礎功能的搭建，通過供給并不是用戶真正的業務需求， 期間讓更多非專業人士能夠參與到開發當中。

2. 概念對比

低代碼平臺 （A low-code development platform） LCDP。于 1982 年，美國科羅拉多大學波德分校的教授 James Martin 出版了一本名為《沒有程序員參與的應用開發》的著作，書中提及，每臺電腦所匹配的程序員的數量在迅速減少，以至于未來大多數計算機需要在沒有程序員的情況下投入工作。后來經過 Forrester 完善概念和定義，最終形成我們當下的理論基礎。

wikipedia定義LCDP

Low-Code 給人感覺就是代碼很丑而且還很 Low ，這里只能在 維基百科 重新找到定義，具有四個特點：

• Low-Code 仍然是一種軟件平臺
• 提供可用于通過圖形用戶界面創建應用軟件的開發環境，而不是傳統的手工編碼計算機編程
• 低編碼平臺可能會生成完全可操作的應用程序，看根據需要進行額外編碼
• 低代碼開發平臺減少傳統手工編碼量、加速業務應用交付、降低軟件設置、培訓、部署和維護的初始成本

2.1. 專業代碼/定制代碼 Pro-Code / Custom-Code

傳統的以代碼為中心 Code-Centric 的開發模式。

2.2. 零代碼 Zero-Code / No-Code

從分類的完備性角度來看，有 純代碼 自然也應該有完全相反的 零代碼 （也稱為 無代碼 ）。 零代碼 就是完全不需要寫代碼的應用開發平臺，但這并不代表 零代碼 就比 專業代碼/定制代碼 更高級和先進，它只是做了一個更極端的選擇而已：徹底擁抱簡單的圖形可視化，完全消滅復雜的文本代碼。選擇背后的原因是， 零代碼 開發平臺期望能盡可能降低應用開發門檻，讓人人都能成為開發者（注意：開發 ≠ 寫代碼），包括完全不懂代碼的業務分析師、用戶運營，甚至是產品經理（不懂裝懂可不算懂）。

3. 特點

通過上述的概念比對，我們認知到 低代碼 ，主要面向設計編程，目標都是為了快速輸出原型成果、快速部署測試，滿足這一點就足夠，他們都具有三類核心特點：

• 全棧可視化編程：可視化包含兩層含義，一個是編輯時支持的點選、拖拽和配置操作，另一個是編輯完成后所及即所得（ WYSIWYG ）的預覽效果。傳統代碼 IDE 也支持部分可視化能力（如早年Visual Studio的 MFC/WPF ），但低代碼更強調的是全棧、端到端的可視化編程，覆蓋一個完整應用開發所涉及的各個技術層面（界面/數據/邏輯）。
• 全生命周期管理：作為一站式的應用開發平臺，低代碼支持應用的完整生命周期管理，即從設計階段開始（有些平臺還支持更前置的項目與需求管理），歷經開發、構建、測試和部署，一直到上線后的各種運維（監控報警、應用上下線）和運營（數據報表、用戶反饋）
• 低代碼擴展能力：使用 低代碼 開發時，大部分情況下仍離不開代碼，因此 低代碼 平臺必須能支持在必要時通過少量的代碼對應用各層次進行靈活擴展，比如添加自定義組件、修改主題 CSS 樣式、定制邏輯流動作等。一些可能的需求場景包括：UI 樣式定制、遺留代碼復用、專用的加密算法、非標系統集成。

4. 分類

按照當前國內同行業對 低代碼 的認知，習慣于按照設計思想的不同，將 低代碼 又劃分為 模型驅動 和 表單驅動 兩種類型，這是 低代碼 的兩個技術方向，側重點也不同。

4.1. 表單驅動

表單驅動 設計思路本質就是將頁面的 表單 和 數據存儲 結構合二為一，以 BPM 作為輔助在軟件系統中運轉業務流程，從而達到滿足設定業務的需求。在當下主流業界的通行觀點中 表單驅動 優勢就是門檻低，所以不需要太專業的知識和技能背景，導致采用這類模型設計的產品很多，商業模式上都在 短 、平 、快 的基礎上推進，主要面對的客戶群就是從沒實施過信息化的小微企業，能有一個應用系統提交數據就滿足實際需要，都沒有大規模業務且簡單業務場景簡單的需求，例如最常見的就是一些用于個人信息收集的輕量級應用。

表單驅動平臺受制于自身設計缺陷，自帶一個弊端就是觸碰到信息化集成設計中一個非常敏感且忌諱的 "三孤"，即流程孤島、系統孤島、數據孤島。

國內某產品

而且這塊的產品都自帶一個特性，非常明顯的互聯網思維，結合 SaaS 低成本 的方式運作，這就導致此類的產品大家都長的差不多、功能相互借鑒、操作性無差別，總之各方面都趨同，這種 低代碼 平臺就已經等同 簡單的數據表單錄入與流轉系統 ，特強調技術而缺乏對業務的理解，因此這類產品的應用都存在一個局限性更高，也就只能干點不帶業務功能的應用，遇到一點復雜的業務沒法落地，很難用在企業級應用的開發過程中。

4.2. 模型驅動

模型驅動 的設計則是用 可視化建模技術 來定義 數據關系、業務邏輯 、 構建人機交互 以及智能化集成，能夠實現數據的同步交換和共享，使開發和業務都能夠快速生成可交付的應用程序，而不需要代碼。

OutSystems

這里只借用 OutSystems 作為案例說明，其他 模型驅動 類產品類似， 模型驅動 總結下來更像是集前端、邏輯和數據層分離設計的綜合 IDE 型的產品，這類產品前端有專業的頁面設計、事件觸發，有專業的邏輯層可視化開發能力及內嵌專業代碼片段的擴展能力，邏輯還可以區分前后端，數據層有專業的實體定義及操作能力。這樣的設計令沒有開發背景的業務人員望而卻步，對沒有技術支撐的企業使用上有一定的難度，但對開發來說確感覺比較熟悉，容易上手，也易于樹立對平臺能力的信心。

模型驅動平臺一般系統架構清晰，表單和數據模型均可獨立開發與維護；同時此類系統拓展性好，既可以內部橫向擴展也可以對接外部系統容易，個別產品甚至能直連其他系統的數據庫。

小結，上述主要為大家說明 表單驅動 、 模型驅動 的區別以及各自產品的特點，這些特點的差異都是基于不同的設計思路導致的，雖然這兩類產品都有一定局限性，在取舍合理的情況下，也都能產生一定的商業價值，也希望這些總結可以為想涉足此類產品的公司或者個人提供一些片面的參考意見。

5. 機會與挑戰

事實上， 低代碼 圖形化的開發模式存在至少已有 20 年歷史了，最早的國外低代碼平臺 Mendix 、OutSystems 都已成為新興的獨角獸企業；當前國內大量傳統軟件廠商、新興 SaaS 廠商也都在紛紛進駐該領地，大家都將目光指向那些沒有 IT 能力的業務、行政、運營人員，希望通過將一些行業相對標準的應用模板化，直接滿足業務團隊 80% 的基本需求，再通過一些可配置、編輯工具輔助，讓業務團隊在標準基礎上進行小幅定制，再解決 20% 特異化需求，最終達成業務需求直接落地成為在線工具的目的。還可以幫助小微企業省去高額的 SaaS 采購、管理軟件外包及聘請 IT 人員的費用。

5.1. 機會

這類市場當具有 市場規模巨大 、 解決 業務復用 問題 以及 不尋求改變開發環境即可完成企業效率提升。

5.1.1. 市場規模巨大

國際權威機構認為全球低代碼市場的潛力應該在 150 億美元，未來將有 75% 的企業應用是通過低代碼的方式搭建完成的。 而 Serverless 云原生技術的出現，為一站式應用開發提供了技術可能。另一方面， SaaS 市場伴隨現代企業管理發展了幾十年，無數場景從被新興發掘，到商業模式與管理工具相互塑造，到現在逐漸標準化。將這部分標準化的部分提取出來進行多種形式的復用，是商業化市場發展的必然結果。從這個角度看，低代碼的產品方向是蘊含巨大潛力的。

5.1.2. 業務復用

回歸信息化的本質，就是企業需要標準化、自動化，反應到 IT 根據業務需求、編寫應用，通過軟件服務的形式，提高業務信息、數據流轉的標準化和自動化，才會不斷催生業務方提出新需求、產品分析需求、設計產品、開發編碼、最終業務使用的完整鏈路。

這個鏈路的節點涉及多方，在協同、組織上很考驗建設方本身的能力水平和統籌協調能力，此時再要提高運作效率上，一方面提升每一個節點自身的效率，這樣整體效率也會跟著提升；再一方面就是對這個鏈路做減法，通過縮短或簡化鏈路來達到既定目的，而 低代碼 產品就是在鏈路上的實現是最短的，最終實現 低代碼 產品的辦公軟件化的終極目標，這也是業務復用為 低代碼 所打開的廣闊市場。

5.1.3. 能效高

業界通行觀點中，任何通過所謂在線 IDE 的形式，試圖給程序員提供一個完整的在線開發環境，但效果都不很理想，主要受如下條件約束：

• 受制于瀏覽器的性能問題及渲染邏輯，很難替代本地 IDE 工具；
• IDE 軟件開源生態是商業化產品所無法達到的，因此任何改變 IT 人員原有工作流的產品本身就存在很大的局限；
• IT 團隊采購低代碼產品一般來講目標非常簡單，就是降本，砍掉一些程序員，降低 IT 投入，而最有效的途徑就是 不重復 編碼。

5.1.4. 成本增益快

提供開箱即用的解決方案，可以為企業更加低成本的信息化運營，不論是信息化建設還是信息運維方面都節約下來很大一部分成本，靈活滿足客戶需求

小結，當下正好市場數智化轉型的良好契機， 低代碼 取代 SaaS 。自新冠疫情爆發以來，滋生大量需求， 低代碼 提供大量標準化應用模板，相比以往的選擇采購 SaaS ，可以讓企業以最低成本接入應用，同時 低代碼 的趨勢將是辦公軟件化，直達實際需求，向用戶屏蔽抽象的對象轉化，自動完成業務模型構建，打造完整應用。

5.2. 挑戰

• 市場孕育：經過這幾年探索，國內 低代碼 市場已度過創新階段，開始覆蓋業務。但是如何吸引市場上 SaaS 產品的用戶群體轉而關注能力更通用的低代碼平臺，是需要資本和從業者不得不考慮的問題。
• 挑戰傳統： 低代碼 有一站式解決方案，提升效率、降低使用門檻，但是會對傳統企業的流程及規范形成新的挑戰，而且在內部采用低代碼開發平臺可能會導致影子 IT 構建不受支持的應用程序增加。
• 技術局限：當前的低代碼平臺產品形態基本以 Web 端產品為主，技術上受限于瀏覽器性能，交互上需要妥協于瀏覽器技術，增加了向用戶屏蔽技術細節的難度。
• 升級改造困難：低代碼平臺是作為業務創新的起點，到應用全生命周期的托管，而對于一些技術棧老舊、設計思維老舊、經過多年迭代的存量系統的升級迭代問題顯得有些力不從心。
• 職業角色缺失：低代碼將會孵化出一個行業中的全新角色—— 業務信息官BIO ，立足于業務，有較高的抽象思維能力，能夠將業務場景工具化。

6. 適用場景

上述著重介紹 低代碼 的分類以及將市場應用，但是 低代碼 也不是萬金油，不可能覆蓋現實世界所有業務，任何一個事情都有其存在的局限性和獨特性，了解這個我們下面來介紹當前認知情況下還無法運用 低代碼 的所能解決的應用：

• 算法和數據結構復雜且要求高：與之相比業務邏輯復雜反而會容易處理一點，無非利用可能在時間上做個取舍或者設計上做妥協，但是算法邏輯復雜才是真正的問題，無法通過 低代碼 予以解決，如搜索引擎類。
• 高復雜架構的應用：用戶量巨大且性能要求非常高，如 B2C 類電商、門戶網站等，他們的前后臺技術架構非常復雜。
• OLAP/OLTP 及智能化應用：分析類應用自然應該用更專業的 BI 工具，智能化應用也應該用更專業的機器學習平臺等工具。
• 視聽交互行業：比如游戲或抖音、云音樂這樣的社交娛樂型的應用。 低代碼 平臺可不擅長做專業媒體類文件的解析和酷炫的界面。
• 專業性很強軟件：類似 Adobe Photoshop 、Auto CAD 等高度專業性軟件 低代碼 是替代不了的。

7. 結語

低代碼 開發不僅僅是將一項枯燥的工作交由軟件完成、降低程序開發難度，降低企業的投資成本，使其擁有真正的信息系統資本是一項技術支撐下的創變，而更重要的則是讓熟知 現狀與需求 的人直接參與進來，來加快科技賦能的實效性，提高企業解決問題的效率。關注企業在數字化演進過程中的真實需求，為其找到真正的價值，賦能于它們， 讓其成長、發展、壯大，在過程中共臝，這才是今天科技企業的使命。我們反對銷售技術“恐懼”，我希望技術“向善”，歷史演進的長河不斷在說明，只有真正把握住人類福祉的變革，才是真正偉大的變革。偉大的技術，不是破壞、顛覆一個行業，而是賦能一個行業。

同時在 低代碼 模式選擇的路上，需要注意是選擇 模型驅動 還是 表單驅動 這會影響你將來的服務改造能力和業務拓展能力，一個卓越的低代碼開發平臺，一定是最懂代碼開發的，只有這樣才有可能把代碼幵發過程中的復雜度降低，以更加簡單的一面呈現給業務用戶。