前言

相信過去幾年在投資領域除了硬核高科技芯片、自動駕駛等之外，低代碼絕對屬于一股清流。2018年6月，低代碼賽道跑出了超10億美元估值的獨角獸OutSystems，一時風頭無兩。

彼時，海外巨頭企業(yè)AWS、Google、Microsoft、Oracle、西門子等也紛紛推出低代碼開發(fā)平臺或通過收購布局低代碼。

BAT等巨頭的紛紛入局更是用實際行動地表達了對低代碼開發(fā)這一領域的看好，不僅參與投資低代碼企業(yè)（如阿里戰(zhàn)略投資奧哲網(wǎng)絡，騰訊投資低代碼廠商道一云等），而且還推出自己的明星產(chǎn)品（如阿里內部孵化的宜搭、百度推出的愛速搭、騰訊云推出云開發(fā)低代碼平臺等）。

同時，阿里釘釘?shù)痛a聚合平臺“釘釘搭”還聯(lián)合8家主流低代碼廠商，共同宣布成立業(yè)界首個低代碼聯(lián)盟。

同期的國內市場同樣戰(zhàn)績頻頻，從2018-2020年，中國無/低代碼領域總體投融資事件共16起。

在總融資規(guī)模上，國內無/低代碼平臺商共獲融資近15億人民幣，歷史融資輪次共50輪，平均單次融資規(guī)模3000萬人民幣，融資企業(yè)總估值近70億元。

據(jù)海比研究院數(shù)據(jù)表明，2021年中國低代碼市場達到28.5億元。未來五年，中國低代碼市場復合增長率為49.5%，2022年達到42.6億元，2025年達到142.2億元。

筆者近半年時間一直在參與SRM SaaS這塊產(chǎn)品的工作，期間也涉及到了表單引擎、審批流、權限等基礎設施產(chǎn)品的設計與開發(fā)，近期也對整個低代碼產(chǎn)品、技術、市場做了一些調研分析，正好昨天閱讀了艾瑞咨詢2021年的低代碼分析報告，今天就寫一篇關于低代碼相關的文章，接下來和大家聊一下我對整個低代碼平臺的一些思路與想法，歡迎一起交流與學習。

低代碼起源

實早在很久之前，低代碼的概念就已經(jīng)出現(xiàn)了，只不過它以前一直處于不溫不火的狀態(tài)。直到近兩年，大量IT巨頭和資本的加入，才引起了越來越多的人關注。

這個故事，還得從上世紀八十年代說起。1980年，IBM的快速應用程序開發(fā)工具（RAD）被冠以新的名稱——低代碼，由此，低代碼的概念首次面向大眾。低代碼是英文“Low Code”的翻譯，它意指一種快速開發(fā)的方式，使用最少的代碼、以最快的速度來交付應用程序。

而Forrester，一家國際知名的技術和市場調研公司，敏銳地發(fā)現(xiàn)了這一問題，并在2014年首次提出低代碼和零代碼的概念：只需用很少甚至幾乎不需要代碼就可以快速開發(fā)出系統(tǒng)，并可以將其快速配置和部署的一種技術和工具。隨后在2018年，Gartner提出aPaaS（應用平臺即服務）和iPaaS（集成平臺即服務）的概念。

在這兩個概念出現(xiàn)并逐漸傳播的時間里，國外軟件廠商就陸續(xù)發(fā)布出低代碼或零代碼開發(fā)平臺，探索并證明了這類產(chǎn)品成功的可能性。基于外國的成功初探，中國市場也掀起了“低代碼/零代碼”的熱潮，并在近兩年逐步形成完整的產(chǎn)品生態(tài)體系。

具體我們可以看下低代碼概念衍生的歷程！

什么是低代碼

首先看一下百度百科對低代碼的定義：

低代碼開發(fā)平臺（LCDP）是無需編碼（0代碼）或通過少量代碼就可以快速生成應用程序的開發(fā)平臺。通過可視化進行應用程序開發(fā)的方法（參考可視編程語言），使具有不同經(jīng)驗水平的開發(fā)人員可以通過圖形化的用戶界面，使用拖拽組件和模型驅動的邏輯來創(chuàng)建網(wǎng)頁和移動應用程序。 [1] 低代碼開發(fā)平臺（LCDP）的正式名稱直到2014年6月才正式確定，整個低代碼開發(fā)領域卻可以追溯到更早前第四代編程語言和快速應用開發(fā)工具。

百度百科

其次看下Wikipedia對于低代碼定義：

從Wiki的這段定義中，我們可以提煉出幾個關鍵信息：

• 低代碼開發(fā)平臺（LCDP）本身也是一種軟件，它為開發(fā)者提供了一個創(chuàng)建應用軟件的開發(fā)環(huán)境。看到“開發(fā)環(huán)境”幾個字是不是很親切？對于程序員而言，低代碼開發(fā)平臺的性質與IDEA、VS等代碼IDE（集成開發(fā)環(huán)境）幾乎一樣，都是服務于開發(fā)者的生產(chǎn)力工具。

• 與傳統(tǒng)代碼IDE不同的是，低代碼開發(fā)平臺提供的是更高維和易用的可視化IDE。大多數(shù)情況下，開發(fā)者并不需要使用傳統(tǒng)的手寫代碼方式進行編程，而是可以通過圖形化拖拽、參數(shù)配置等更高效的方式完成開發(fā)工作。

按維基百科的說法，低代碼這個稱呼是 Forrester 在 2014 年提出的，指那些用可視化方式創(chuàng)建應用的平臺，特點是代碼量比傳統(tǒng)開發(fā)少得多，甚至無代碼，所以能顯著提升開發(fā)效率。

這個定義比較模糊，使得低代碼平臺有各種各樣的形式，我見到的就有以下幾種：

1. 在線 IDE 和編輯器，界面方面雖然有可視化設計，但需要二次開發(fā)才能用。
2. 提供一站式開發(fā)平臺，提供了持續(xù)集成、部署和運維等功能，包含開發(fā)全流程。
3. 簡化前端開發(fā)，界面方面可以做到不用寫 JavaScript。
4. 簡化后端開發(fā)，可以在線設計數(shù)據(jù)結構，并實現(xiàn)增刪改查功能。
5. 徹底簡化前后端開發(fā)，甚至變成無代碼平臺，什么都可視化編輯，易用性好，但犧牲了靈活性，這里面有很多子分類，比如 BPM、OA 系統(tǒng)、APP 開發(fā)等。
6. 圍繞某個成熟產(chǎn)品擴展功能，比如 CRM、ERP 之類的SaaS產(chǎn)品，為了滿足定制需求，提供定制開發(fā)功能。

低代碼應用場景

低代碼作為軟件開發(fā)工具之一，可覆蓋制造業(yè)、金融、醫(yī)療、房地產(chǎn)、零售、餐飲、航空等眾多行業(yè)的不同應用場景，但 根據(jù)場景類型和復雜程度大致可以劃分為4類應用，分別是通用型業(yè)務場景、企業(yè)綜合型管理系統(tǒng)、企業(yè)個性化場景應用 和中小企業(yè)細分應用場景。通用型場景相對其他場景通常行業(yè)屬性較低，可以實現(xiàn)跨領域、跨企業(yè)應用，滿足企業(yè)共性場 景需求。綜合型管理系統(tǒng)通常用于中大型企業(yè)整個內部管理，屬于企業(yè)級應用，場景相對復雜。通常會根據(jù)企業(yè)需求并利 用低代碼平臺提供定制化解決方案。企業(yè)個性化應用區(qū)別于綜合型管理系統(tǒng)，可服務于各類型企業(yè)的個性化需求場景，并根據(jù)企業(yè)類型和行業(yè)屬性的不同有所側重。中小企業(yè)細分應用場景在低代碼應用熱度中后勁很足，或將成為行業(yè)應用中的 熱門場景。

低代碼在不同企業(yè)中模塊的覆蓋率不同。中小企業(yè)由于應用復雜度低、業(yè)務流程相對簡單等原因，95%的應用場景均可用低代碼來完成。且低代碼產(chǎn)品靈活性高，便于企業(yè)應用功能拓展，能適應中小型企業(yè)快速發(fā)展中頻繁的功能迭代需求，讓 創(chuàng)新更快落地。中大型企業(yè)中低代碼目前可覆蓋70%的應用場景，中大型企業(yè)通常需要建立新系統(tǒng)時與企業(yè)原系統(tǒng)進行信息聯(lián)通，或是對原有系統(tǒng)進行二次開發(fā)，其中的邏輯設計和結構較為復雜。低代碼有大量場景應用模塊和行業(yè)插件，可以幫助中大型企業(yè)進行個性化應用的搭建，打通企業(yè)內部數(shù)據(jù)連接。音視頻、即時通信等垂直領域，在低代碼搭建應用的基 礎上還需要其他插件進行功能補充，目前在垂直應用場景照片那個低代碼的功能可覆蓋約50%。

低代碼平臺驅動模式

低代碼平臺主要有表單驅動和模型驅動兩種模式

表單驅動

表單驅動是傳統(tǒng)BPM的典型標志，為了實現(xiàn)某個業(yè)務目標，利用計算機在多個參與者之間按某種預定規(guī)則自動傳遞文檔、信息或者任務。

低代碼平臺主要實現(xiàn)工作過程管理的自動化、智能化和整合化。最主要的特征就是可以靈便的實現(xiàn)數(shù)據(jù)整合和數(shù)據(jù)統(tǒng)計，消除信息孤島;低代碼雖然看起來操作模式像BMP，實際上基于流程進行驅動的數(shù)據(jù)、數(shù)據(jù)格式、數(shù)據(jù)來源已經(jīng)發(fā)生了根本變化。BPM是典型的表單驅動只能做企業(yè)內部工作流，而基于aPaaS的后端模式與MADP前端模式加上BPM，三者結合形成了低代碼的一種展現(xiàn)，即是通過模型驅動進行實現(xiàn)。

模型驅動

模型驅動使用可視化建模技術來定義數(shù)據(jù)關系、流程邏輯和構建用戶界面，使開發(fā)人員和業(yè)務用戶能夠快速交付應用程序，而不需要代碼。

模型驅動的具體優(yōu)勢包括:

1. 通過去掉重新生成、重新構建、重新測試和重新部署步驟，可以更快地執(zhí)行功能更改
2. 訪問平臺中的API層，以便使用自定義代碼輕松控制模型擴展
3. 通過啟動運行服務器并添加模型，可以輕松地進行部署
4. 使用更靈活、更動態(tài)的應用程序監(jiān)視功能，并使較少的技術開發(fā)人員能夠通過可視化應用程序模型進行分析和快速調試
5. 使用更靈活、更動態(tài)的應用程序監(jiān)視功能，并使較少的技術開發(fā)人員能夠通過可視化應用程序模型進行分析和快速調試

使用模型驅動的平臺比如OutSystems、Mendix的手冊會有很大一章講怎么做數(shù)據(jù)建模和處理，包括怎么定義實體、實體間關系、主鍵、唯一性、索引、數(shù)據(jù)怎么訪問、篩選、分組、統(tǒng)計等等，還提供SQL或類似擴展。使用表單驅動的產(chǎn)品則往往手冊第一章就是說明怎么定義各種表單，都是各種和界面相關的控件，比如單選多選下拉框、文本日期數(shù)字等。

低代碼平臺開發(fā)模式

目前市面上的低代碼開發(fā)平臺主要分為兩種模式。一種是引擎式開發(fā)模式，一種是快速生成代碼模式。

引擎開發(fā)模式

引擎式開發(fā)模式是目前最先進的軟件快速開發(fā)方式之一，只需在開發(fā)后臺進行配置，即可完成軟件開發(fā)的過程，由于過程中沒有生成或修改底層源碼，平臺可以統(tǒng)一維護和升級，輕松實現(xiàn)復雜的業(yè)務邏輯。

源碼生成模式

這種模式主要通過桌面式設計器來定義業(yè)務模塊，輔助生成源代碼框架，然后用戶可以在生成的源代碼的基礎上去編寫、修改自己的源代碼來實現(xiàn)業(yè)務邏輯，因此生成源碼模式也可認為是一種代碼生成器。這種模式對開發(fā)人員的要求比較高。

低代碼開發(fā)平臺價值

對開發(fā)者而言

圖形化操作，容易上手；提供成熟案例模板庫，不用從零開始；支持所有主流應用服務器和數(shù)據(jù)庫，降低開發(fā)難度；接口豐富，節(jié)省開發(fā)時間；強大的代碼調試功能，提升開發(fā)效率；

對企業(yè)而言

優(yōu)化流程，提升企業(yè)運作效率;節(jié)省成本，提升企業(yè)效益;維護方便，即改即用;一鍵升級，方便實用;

對使用者而言

操作簡單、友好 、人性化;消息驅動，合理利用工作時間;即用即改，優(yōu)化完善軟件功能;多客戶端入口，隨時隨地辦公;

低代碼平臺的誘人之處在于它可視化的開發(fā)形式，為開發(fā)者提供了不同于傳統(tǒng)編碼的界面，通過拖放式操作即可將各個字段進行部署。另外，低代碼開發(fā)平臺可以使用可視化建模方式來驗證應用邏輯，這無論對于IT人員、還是業(yè)務人員來說，都是一種極好的交流方式。

低代碼工具雖談不上萬能，但它非常強大。對于一些流程復雜的系統(tǒng)來說，即使低代碼會存在著一些局限性，它也可以作為系統(tǒng)開發(fā)的補充手段，在小范圍、小規(guī)模、流程簡單的場景下，根據(jù)業(yè)務需求去搭建應用程序。但千萬不要因此被限制了想象力，比如特斯拉僅25人花了4個月就做出一套ERP系統(tǒng)，就是當時的CTO Vijayan在梳理完業(yè)務流程后，用低代碼平臺Mendix實現(xiàn)的。

低代碼對于企業(yè)而言，無非是提升整個數(shù)字化轉型的利器，當然一切以自身的實際需求而定，業(yè)務流程管理是第一要務，技術手段僅僅是應用的呈現(xiàn)方式。企業(yè)數(shù)字化轉型不僅僅是企業(yè)IT部門的責任，整個過程會落在每一個人頭上，低代碼產(chǎn)品給所有人提供了都能看得懂的語言，在實際執(zhí)行過程中減少阻礙，加快數(shù)字化轉型進度，也未嘗不是一件好事。

低代碼平臺核心能力

低代碼的平臺具備的核心能力要素，我認為有四點：

• 可視化開發(fā)
• 數(shù)據(jù)模型驅動
• 擴展性
• 工程化

圖片

下面針對以上四點逐一分析：

(1) 可視化開發(fā)

業(yè)務人員基于可視化的頁面或工具能夠進行簡單拖拉拽、可以形成一個頁面信息。

他們也能夠基于可視化界面來配置定義數(shù)據(jù)源和數(shù)據(jù)模型、簡單定義一個流程，可以執(zhí)行工作流。

總而言之，就是前端拖拉拽可以形成前端的交互語言，進而生成后端可以執(zhí)行的計算機語言。

(2) 數(shù)據(jù)模型驅動

低代碼平臺，能夠可以通過頁面上的操作進行定義一個模型定義，可以靈活的定義模型中的字段、也可以進行相關數(shù)據(jù)表的關聯(lián)操作，以及設置數(shù)據(jù)模型的規(guī)則和索引。

a. 模型定義

進行數(shù)據(jù)庫模型的設計、添加字段，設置字段的類型以及索引

b. 模型關聯(lián)

建立數(shù)據(jù)庫表與表之間的關系，具體表現(xiàn)為 1 對 n，n 對 n，n 對 1、1 對 1 等關聯(lián)關系

c. 數(shù)據(jù)操作

基于數(shù)據(jù)庫表對外提供一個 CRUD 的操作，讓應用能夠操作該數(shù)據(jù)模型

(3) 擴展性

是指低代碼平臺是否可以提供一些機制來進行擴展。

具體的擴展方式有以下三點：

a. 擴展語言

低代碼平臺是否能夠我熟悉的語言來擴展，假如我是前端開發(fā)者，能否提供前端熟悉的語言來擴展，假如我是后端開發(fā)者，能否基于寫一些后端代碼（Java 、Go 等）來擴展。

b. 邏輯擴展

低代碼平臺能否通過定義一些流程圖也進行業(yè)務邏輯的擴展，來執(zhí)行業(yè)務 if、else 的流程來做業(yè)務上的一些調用。

c. API 集成

低代碼平臺是否可以通過低碼平臺搭建的應用與第三方公司已有的系統(tǒng)或者服務做集成，能否在低碼中通過 API 做集成過來，供我的應用來調用集成。

(4) 工程化

低代碼平臺是否可以進行本地開發(fā)調試、版本控制、自動構建發(fā)布上線、免運費以及監(jiān)控的一些能力。簡單來說是否在該平臺上一站式配套的能力。

a. 擴展語言

低代碼平臺要能夠進行本地的開發(fā)調試。

b. 版本管理

低代碼平臺可以進行版本回退操作，以及有能力可以預留體驗，回退體驗的時候不會影響到發(fā)布態(tài)的產(chǎn)物。

c. 自動化

低代碼平臺可以自動構建發(fā)布上線、免運費以及配套監(jiān)控的一站式能力。

低代碼平臺設計核心要點

關于低代碼的設計需要關心如下4點：

1. 業(yè)務數(shù)據(jù)如何存？如何實現(xiàn)自定義數(shù)據(jù)存儲？

需要抽象出數(shù)據(jù)模型

2. 如何實現(xiàn)業(yè)務流程流轉？

基于工作流來進行業(yè)務流程流轉。

3. 業(yè)務數(shù)據(jù)和流程流轉，那些人可以訪問和控制？

建立了用戶權限平臺，來進行人員角色的控制。

4. 如何進行服務端邏輯的自定義擴展？

通過云函數(shù)來實現(xiàn)后端服務的自定義擴展能力。

數(shù)據(jù)模型

數(shù)據(jù)模型基于業(yè)界標準的能力 JSONSchema 來進行擴展，數(shù)據(jù)模型分為內部數(shù)據(jù)源和外部數(shù)據(jù)源兩種。

數(shù)據(jù)模型 – 內部數(shù)據(jù)源：

為我們提供數(shù)據(jù)模型定義，索引、以及各種數(shù)據(jù)模型的關系。

我們可以靈活的來自定義數(shù)據(jù)字段，以及字段的索引功能。

也能過提供標準通用的能力，比如新增、刪除、查詢、更新等。

連接器：

連接器可以打通外部應用數(shù)據(jù)或調用外部應用開放的服務，開發(fā)者只需要對連接器完成授權或少量填寫一些配置信息，即可使用對應產(chǎn)品的服務接口。

自定義連接器

自定義連接器支持調用第三方服務接口或使用代碼來實現(xiàn)業(yè)務邏輯。開發(fā)者可以在應用、工作流、自定義數(shù)據(jù)模型中使用。

分為 http 和云函數(shù)模式：

http：開放式 API，用戶來鏈接外部的服務，與外部 API 來做集成。

云函數(shù)模式：完全自定義，當用戶以上所有的場景均不能滿足的時候，可以通過云函數(shù)的來手動寫一些代碼來自定義一些邏輯，實現(xiàn)業(yè)務上的邏輯擴展。

工作流

工作流基于業(yè)界標準 bpmn 協(xié)議來擴展，數(shù)據(jù)展示和存儲基于標準 JSON 來處理可讀性更高。

市場上比較有名的開源流程引擎有osworkflow、jbpm、activiti、flowable、camunda。其中：Jbpm4、Activiti、Flowable、camunda四個框架同宗同源，祖先都是Jbpm4，開發(fā)者只要用過其中一個框架，基本上就會用其它三個，目前比較流行可以推薦使用的flowable、camunda。

flowable、camunda都是源于美國的一些審批模式，對于國內的一些審批模式支持不太友好，需要進行定制開發(fā)，比如會簽、或簽、轉簽、任意流程跳轉等。

角色權限

角色權限整體遵循 RBAC 模型來進行設計的，業(yè)務上可靈活的支持擴展。具體用戶能夠訪問哪些頁面、數(shù)據(jù)源、以及流程權限等，同時也需要支持設置一些權限集，以便于靈活地進行業(yè)務上權限的擴展。

服務端擴展

服務端的擴展基于云函數(shù)(serverless)的能力，通過頁面可視化編寫代碼來進行服務端邏輯的擴展?？梢宰鲆恍?shù)據(jù)表的聚合，以及 CRUD 等操作方法。

目前各大云廠商都提供了相應的serverless支持，包括AWS的Lambda、Google Cloud Function、Azure Function，可以充分借助云的力量實現(xiàn)對服務端的擴展。

低代碼平臺常見問題匯總

低代碼和無代碼是兩回事

區(qū)分這個概念其實很簡單，一個需要寫代碼，一個不需要寫代碼，其實國內目前對于這個概念比較混亂。

無代碼和低代碼完全不同：無代碼面向業(yè)務人員，低代碼面向開發(fā)人員；無代碼泛指多種開發(fā)細分領域應用的工具，低代碼特指一種通用開發(fā)工具；無代碼不被國際頭部分析機構認可，低代碼被廣泛認可。

無代碼這個詞通常用來形容一些細分領域的開發(fā)工具，最常見的是應用搭建平臺（國外一般叫App Builder之類），如國外的Appy Pie、國內的宜搭、簡道云等，還可以用來形容Airtable / AppSheet / Treelab這類在線表單工具或輕流這類的工作流工具。

對于低代碼無論是Gartner還是Forrester都已經(jīng)開始給出比較清晰的篩選標準，如要支持通用場景（如UI、邏輯和數(shù)據(jù)三層都要有）、要滿足專業(yè)開發(fā)需求等，隨著行業(yè)發(fā)展標準化程度肯定會進一步提高。

低代碼不是一個想吸引業(yè)務用戶的用語，業(yè)務人員見了“代碼”兩個字就嚇跑了，再低也沒用，如果業(yè)務人員寫不了100行代碼的話，那10行也一樣寫不了。無代碼的“通用”開發(fā)平臺，目前看并不存在，據(jù)我看將來也不會存在。因為開發(fā)軟件必然要編寫邏輯，就必然要寫代碼，除非哪一天人工智能可以做到自動寫代碼。

低代碼真的是新瓶裝舊酒嗎

關于低代碼的出現(xiàn)，業(yè)內其實也有一些爭論，認為低代碼是新瓶裝舊酒，關說二十年多年前的Delphi、PowerBuiler（后稱PB）早就是低代碼，但早就被時代淘汰了，今天的低代碼也沒戲。

個人曾經(jīng)在大學期間也用過VB可視化編程，也看到了一些低代碼的影子，但和今天的低代碼還是有很大的區(qū)別的。個人認為主要是因為時代變了，這些可視化編程沒跟上。互聯(lián)網(wǎng)時代來了后，軟件架構很快就從桌面端的C / S變成Web端的B / S，再后來是移動App。Web應用和App對前后端的要求比桌面應用都要高很多，因為大家做網(wǎng)頁或App都是要吸引用戶主動來訪問啊，不像桌面端的企業(yè)應用就算不好用你為了工作也得用?；ヂ?lián)網(wǎng)的這二十年，技術棧發(fā)展的越來越復雜，新的低代碼技術只能一直慢慢醞釀。

但OutSystems等廠商經(jīng)過十多年的積累，今天的低代碼技術已經(jīng)遠勝當年的Delphi和PB。今天的低代碼要“低”得多，當年的Delph、PB等如果按今天的標準，連入門的資格都沒有。

低代碼能開發(fā)復雜的企業(yè)應用嗎

這個問題其實一直也是一個爭論的焦點，低代碼到底適不適合開發(fā)復雜的企業(yè)應用。業(yè)內很多人士認為低代碼只可以開發(fā)簡單的工作流和表單流轉的應用，不適合開發(fā)復雜邏輯的核心業(yè)務。

企業(yè)應用的復雜主要是領域模型和業(yè)務流程比較復雜，低代碼平臺在建模和邏輯方面的能力都是比較全面的，再通過腳本語言、開放集成等擴展機制，對于不方便低代碼實現(xiàn)的地方，可以和專業(yè)代碼開發(fā)協(xié)作實現(xiàn)，而且企業(yè)應用不存在高并發(fā)、智能算法之類場景，這恰恰是低代碼平臺的優(yōu)勢所在，所以用低代碼開發(fā)復雜企業(yè)應用，本質上沒問題，個人認為沒有技術解決不了的復雜問題。

明道云CEO任向暉寫過一篇《APaaS搞不定復雜的應用，是這樣嗎？》，把企業(yè)應用的復雜性分解為數(shù)據(jù)、權限、流程、算法、集成、報表等六個維度，然后逐一給出解決方案。這才是實事求是的態(tài)度。我覺得任總的分析已經(jīng)比較充分，我也不再展開說了。我相信任何人但凡不帶偏見，深入分析的，都會發(fā)現(xiàn)企業(yè)應用并沒有什么復雜性是低代碼一定搞不定的，我這里說的是低代碼不是無代碼。

OutSystems也有一些這方面的案例，做供應鏈、CRM、ERP的都有，國內的一些低代碼平臺都有對應的HR SaaS、CRM SaaS應用模板。從另外一個角度看，目前國內外知名的SaaS產(chǎn)品都有相應的低代碼配套產(chǎn)品，低代碼平臺就是解決客戶二開需求，提升交付效率、降低成本，這也解釋了為什么Saleforce、ServiceNow這樣的SaaS巨頭都有自己的低代碼平臺，而西門子會收購Mendix。

低代碼不適合開發(fā)哪些類型的應用

個人認為低代碼不適合以下場景：

• 對算法和復雜數(shù)據(jù)結構要求比較高的：我想不會有人想到用低代碼平臺去刷LeetCode題、打ACM比賽的吧。這里有個細微的地方是要區(qū)分是業(yè)務邏輯比較復雜還是算法邏輯比較復雜，業(yè)務邏輯復雜對低代碼來說不是問題，算法邏輯復雜才是問題。那啥叫業(yè)務邏輯復雜呢，就是業(yè)務人員總之是說得清楚，或者是能理解的；啥叫算法邏輯復雜呢，就是業(yè)務人員只能給個目標，具體怎么實現(xiàn)是不管的，就算解釋也是一臉悶逼聽不懂的。
• 對界面要求特別高的：比如游戲或抖音、云音樂這樣的社交娛樂型的應用。目前主流的低代碼平臺都不擅長做酷炫的界面（也有一些特定類型的低代碼平臺如App Onboard是面向游戲開發(fā)的，不在本文討論范圍之內）。
• 頭部互聯(lián)網(wǎng)級應用：頭部互聯(lián)網(wǎng)應用用戶量巨大，為了優(yōu)化性能有很多很多trick，前后臺技術架構非常復雜，低代碼平臺的實現(xiàn)是比較標準的數(shù)據(jù)庫 / 邏輯 / 界面三層架構，無法滿足性能需求。注意這不是說所有互聯(lián)網(wǎng)應用都不合適，只是指那些用戶量特大的頭部應用，比如用低代碼開發(fā)一個淘寶、天貓，肯定是不現(xiàn)實的。
• 分析和智能化應用：分析類應用自然應該用更專業(yè)的BI工具，智能化應用也應該用更專業(yè)的機器學習平臺等工具。
• 系統(tǒng)軟件、科學計算等其他專業(yè)性很強的應用。這個不多說了，估計也沒誰想用低代碼來做，但多說一句，雖然這些系統(tǒng)的內核肯定不適合低代碼開發(fā)，但界面可是很適合，我們輕舟低代碼產(chǎn)品正是脫胎于云計算平臺的界面開發(fā)。

低代碼不是銀彈，不要過度神化

說低代碼很適合開發(fā)典型的企業(yè)應用，優(yōu)點明顯，如開發(fā)人員上手快、開發(fā)效率高、增進溝通和集成等，但也不要認為低代碼是銀彈，用了什么問題都解決了。原因主要有以下三個方面。

• 開發(fā)工具只能解決軟件研發(fā)的部分問題

作為開發(fā)工具，低代碼可以加快在需求比較明確時的軟件交付，也可以在大方向比較明確但具體需求不明時加快軟件的迭代更新。但企業(yè)應用和企業(yè)的經(jīng)營管理方式、業(yè)務方向、業(yè)務流程、組織架構密切相關，和人密切相關，這些方面如果有問題，軟件都不知道怎么做，這都不是開發(fā)工具所能解決，該請咨詢還是得請咨詢。低代碼就像特種兵，單兵作戰(zhàn)能力是強，但如果將帥不行，戰(zhàn)略戰(zhàn)術拉垮，也打不了勝戰(zhàn)。

• 低代碼能提升多少開發(fā)效率缺乏權威數(shù)據(jù)，不要有太高預期

業(yè)界有很多對低代碼開發(fā)效率的宣傳，最多的是說什么提升10倍啦，這些一看就是胡扯。一些廠商和分析機構會發(fā)布提效數(shù)據(jù)，看似效果特別好，但因為前面說的無代碼和低代碼沒分清問題，這些數(shù)據(jù)不可信。

比如阿里“宜搭”的數(shù)據(jù)說平均將應用開發(fā)成本從17.5人天提高到3.5人天，提效500%，但前面說過“宜搭”是無代碼工具。無代碼工具因為都是面向特定類型的應用高度優(yōu)化的，提效明顯很正常的，但不通用。

專業(yè)的低代碼廠商如OutSystems、Mendix，反而不敢宣傳提效多少倍，所以一個廠商宣傳的效果越好，就越不可能是專業(yè)的低代碼平臺。個人覺得用低代碼做一些小系統(tǒng)確實挺快，但上了規(guī)模后還能是不是有數(shù)倍提升，我覺得也不大可能，提升1到2倍是一個比較合理的預期。

• 行業(yè)典型的項目制限制了低代碼的價值

低代碼平臺因為可視化、效率高，最適合業(yè)務和開發(fā)密切溝通合作，快速迭代。但當前甲乙方之間典型的項目制要求雙方提前簽訂詳細的合同和SOW，這就把本來可以敏捷開發(fā)的生生打回到瀑布模式，這樣低代碼快速迭代的價值就很難體現(xiàn)。項目制存在太久，不是一時半會改的了的。

低代碼會讓程序員失業(yè)嗎

這個問題的答案是NO,個人認為低代碼解決的是可抽象的，通用的且可復用的產(chǎn)品能力，程序員作為高級技術人才，是低代碼平臺的締造者，低代碼工具是將程序員從現(xiàn)有的重復的枯燥的接口開發(fā)中解放出來。程序員應該更關注業(yè)務創(chuàng)造方面的技術研究和開發(fā)。低代碼是工具，低代碼與程序員之間的關系就像翻譯軟件與譯者，數(shù)據(jù)統(tǒng)計系統(tǒng)與數(shù)據(jù)分析師，工具的目的是減少重復的勞作而將人力投入更有意義、有價值的研究之中。技術不應該掌握在少數(shù)人手里，普通人不應該因為不會寫代碼，而失去在IT時代創(chuàng)新的權利。

低代碼平臺未來發(fā)展趨勢

深扎平臺完整度和自定義能力，提升產(chǎn)品易用性和靈活度

低代碼平臺是在各種組件和模塊實現(xiàn)無代碼化的基礎上發(fā)展起來的，早期是數(shù)據(jù)庫管理、報表管理等單點能力突破。隨著 產(chǎn)品架構的設計能力和落地能力提升，低代碼由組件的無代碼化向平臺形式轉變。未來隨著引擎種類和交付模塊數(shù)量的增 加，低代碼平臺將會覆蓋更多應用場景，實現(xiàn)更大范圍的業(yè)務價值。除了集成性以外，產(chǎn)品的自定義能力也將是低代碼廠 商未來重點關注的方向，在眾多個性化和細分行業(yè)應用場景中，產(chǎn)品的靈活度和可拓展性是客戶主要考慮因素之一。因此， 低代碼廠商將更加關注低代碼平臺的完整度和自定義能力，提升低代碼產(chǎn)品的易用性和靈活度。

產(chǎn)品由組件向平臺化演進，嫁接高階能力提供一體化服務

之前，低代碼更多作為工具幫助研發(fā)人員降低軟件開發(fā)過程中部分模塊的可復用性，隨著可復用性模塊增加和云計算、微 服務架構等技術的發(fā)展，通過平臺架構設計和引擎的開發(fā)逐漸抽象出低代碼平臺。目前，隨著RPA、AI技術能力的應用普 及，將會有更多的泛自動化、智能化能力賦能到企業(yè)應用中。RPA可以幫助業(yè)務開發(fā)人員實現(xiàn)重復工作的替代，未來甚至 會有數(shù)字員工更多可以完成的工作。AI能力則可以提供ocr、nlp等工具輔助平臺使用者進行商業(yè)決策，實現(xiàn)為客戶提供一 體化服務的能力。

通用型平臺競爭大于垂直場景，產(chǎn)業(yè)鏈生態(tài)強者恒強

在低代碼市場發(fā)展早期，廠商類型多樣化，傳統(tǒng)軟件廠商、SaaS廠商、云廠商等紛紛涉足低代碼領域，希望借助低代碼平 臺完成對內和對外的高效開發(fā)。早期低代碼平臺依然依賴于服務，規(guī)?；^低，拓客速度相對較慢。通用型廠商相對 垂直型廠商應用場景更加廣泛，因此廠商數(shù)量更多。但隨著市場的孕育和成熟，通用型廠商競爭加劇，垂直型廠商在細分 領域的優(yōu)勢漸顯，可以進一步深挖用戶場景并不斷提升客戶滿意度。在市場成熟期，用戶對低代碼廠商依賴度高，品牌效 應明顯，前期知名度高、產(chǎn)品能力強的通用型廠商會跑出優(yōu)勢局面，市場集中度將會大幅提升。因此，及早布局低代碼產(chǎn) 業(yè)鏈生態(tài)，多維度拓展廠商優(yōu)勢，才能在將來競爭中占據(jù)高地。

參考文獻：

01：艾瑞咨詢[低代碼行業(yè)研究報告-2021]

02: 低代碼是什么？有什么優(yōu)勢

03: 低代碼平臺開發(fā)應用場景和常見用例

04: 萬字長文講透低代碼