編輯導語：近幾年來，低程式碼開發的概念也十分火熱，某種程度上，低程式碼開發可以提升企業的開發效率，推動企業的數字化轉型，而這也是低程式碼開發火起來的原因之一。本篇文章裡，作者就對低程式碼開發的發展做了全面解讀，一起來看看吧。

2021年，“低程式碼”接力“中臺”燃起了熊熊之火，引發眾多業內人士論戰。其中有兩種極端的觀念，一種是“低端炒作”、“無用玩具”、“行業毒瘤”，另外一種是“顛覆行業”、“取代程式設計師”。

不管怎麼說，低程式碼現在已經被推向時代變革的大潮，成了我們數字化轉型過程中張口閉口的熱詞，它火熱的背後的動因是什麼呢？它是新瓶裝舊酒嗎？它到底是行業毒瘤還是顛覆革命？

讓我們先來看看百度百科對低程式碼的定義：

低程式碼（Low Code）是一種視覺化的應用開發方法，用較少的程式碼、以較快的速度來交付應用程式，將程式設計師不想開發的程式碼做到自動化，稱之為低程式碼。低程式碼是一組數字技術工具平臺，基於圖形化拖拽、引數化配置等更為高效的方式，實現快速構建、資料編排、連線生態、中臺服務。透過少量程式碼或不用程式碼實現數字化轉型中的場景應用創新。

——百度百科

一、低程式碼的發展歷程

其實低程式碼不是一個新概念，早在上世紀80年代，它的名字是“視覺化程式設計”，指的是用很少或幾乎不寫程式碼快速開發應用，並快速配置和部署的一種技術和工具。

推動現代低程式碼開發模式發展的我認為是SaaS應用的發展，具有標誌意義的就是2007年Salesforce面向開發者推出的Force。com應用開發平臺，第一次將低程式碼應用到SaaS應用中（下文中會分析SaaS推送低程式碼開發發展的原因）。

2014年，研究諮詢機構Forrester首次提出了“低程式碼/零程式碼”的概念，隨後在2018年Gartner又提出了aPaaS，和當下的低程式碼/零程式碼概念更為接近。從2018年開始，低程式碼相關的廠商和應用如雨後春筍一般爆發，2020年繼中臺概念後被稱為低程式碼元年。

但我們從上面的發展歷程圖上也能明顯的看出，其實從2014年（甚至追溯到2007年）到2018年這個時期，低程式碼發展好像進入了一個空白期，為什麼會出現這樣的情況呢？其實我們從國內的SaaS應用的發展也可以窺見端倪。

Salesforce開啟了SaaS模式之後，21世紀初SaaS模式還處市場探索的萌芽時期，直到2014-2018年才進入了快速發展期。SaaS爆發的初期，更多還是以標準化產品為主，服務的都是小微型客戶。所以這一時期SaaS對低程式碼開發還沒有推動的動力。

二、推進低程式碼發展的幾個因素

1. 從SaaS應用的能力進化看低程式碼發展

在沒有SaaS模式之前，傳統的資訊化都是透過購買或者開發部署獨立的私有化的資訊產品為主，在這種傳統模式下，就造成了幾個問題：

對客戶來說，軟體的成本太高，少則幾萬，動輒上百萬、上千萬。而且成本高也體現在個性化需求開發的時候，而且一旦定製，就很難再升級。

對廠商來說，落地實施的成本很高，產品版本分化嚴重，後期維護成本很高，服務能力降低。新的功能研發上線，無法對老客戶實行二次銷售，客戶體驗差。

所以，對於很多中小型企業來說，因為SaaS產品的出現，也解決了初期軟體投入成本過高問題，同時不需要招聘太多專業的資訊科技人員維護，SaaS模式逐步被接受。

但是SaaS的發展必然也面臨著客戶越來越多導致需求個性化的問題，SaaS的複雜性越來越大，發展的早期如何解決？

拒絕個性化，只做標準服務。

但這種方式可以應付小微客戶，但是一旦有一定規模的客戶，不可避免的存在個性化定製，拒絕個性化，就是拒絕機會，無疑自找思路。

在產品上增加定製開發功能。

當你無法把各個客戶的需求進行統一抽象，建立個性化功能模組就是應對個性化開發之道。但是這種做法讓你的產品和程式碼變成了一個

大泥球

，給未來的開發維護帶來巨大的災難。

為每個客戶建立分支版本。

這個做法和傳統的軟體交付模式其實沒什麼差別，只是接管了本來屬於甲方的運維，當分化的版本越來越多，版本維護和運維將是高昂的成本。

以上的做法其實是把傳統軟體開發的模式引入到SaaS應用中，實際上依然沒有從本質上，底層上解決問題。Salesforce其實給我們指明瞭道路——SaaS應用的PaaS化。透過提供具備開發能力的PaaS平臺，為SaaS應用提供定製開發能力。為了降低在PaaS平臺上開發的難度和工作量，於是低程式碼開發平臺也就應運而生。

2. 從企業數字化轉型需求看低程式碼發展

數字經濟下產品更新換代速度加快，市場需求更迭同步提速，企業需要不斷提升軟體開發效率和市場響應速度的產品。但傳統的開發模式對企業數字化轉型提出巨大的挑戰，導致出現一些問題和痛點，具體分析如下：

從滿足需求角度，資源缺口導致長尾需求無法滿足；

從降低成本角度，軟體成本高導致全面數字化推動力不足；

從改善架構角度，傳統系統架構可擴充套件性及整合度不高；

從孵化創新角度，重複建設、標準不統一、業務協同差導致對新業務的支援度不高。

而低程式碼開發像拖拉拽的視覺化開發方式，樂高式的應用搭建，共生的一體化平臺等特點能在一定程度上解決企業數字化轉型的這些需求和痛點。

3. 從技術和企業數智化演進看低程式碼發展

從企業數智化的發展經歷了幾個階段（如上圖），每個階段都伴隨著巨大的資訊科技的變革，在前兩個階段，開發工具的推動起到了很大的作用，開發語言的高階特性及開發工具的能力提升，讓工程師的開發效率獲得提高。而到了網際網路化的階段，雲計算、虛擬化、容器化帶動了雲端技術的巨大發展，特別是雲原生技術的提出和發展，讓基於雲端的開發發生了質的變化。

軟體開發技術發展的核心是讓技術實現更簡單這個核心原則始終沒有改變，而低程式碼開發的目的也正好符合這個原則，所以低程式碼開發模式得到推崇和發展也是情理之中。

三、低程式碼產品的形態

現在市場上低程式碼的產品琳琅滿目，低程式碼廠商也是百花齊放，按搭建應用時是否需要程式碼可以將廣義低程式碼產品分為狹義

低程式碼和零程式碼

兩種，二者均可透過視覺化介面，對封裝好的程式碼模組進行拖拉拽來完成應用搭建。

其中低程式碼主要服務關注業務邏輯的開發部門，需要少量程式碼進行模組銜接或功能 拓展；零程式碼更強調低程式碼的低門檻，僅需理順業務邏輯即可快速搭建流程管理、表單等輕量級應用。

整體上看，低程式碼產品的函式與系統解耦，在少量程式碼的支援下應用場景較廣，而零程式碼輕量便捷，搭建速度快，賦予業務部門更多自主權。零程式碼使用門檻低，但支援的場景有限，而低程式碼可搭建複雜度較高的應用，這也是我們主要深入瞭解低程式碼的原因。

按照低程式碼產品的底層驅動技術可劃分為

表單驅動、邏輯驅動和資料驅動

三類。

表單驅動直接關注業務場景，以資料表為 核心、以工作流為媒介構建應用。

模型驅動從業務場景中抽象出模型構建頁面和業務流，其應用場景更加複雜且廣泛。

資料驅動在模型驅動的基礎上深度挖掘資料價值，將從網際網路及其他軟體收集來的資料進行彙總和整理，運用新技術和演算法訓練擬合成自動化決策模型。

整體上看，低程式碼正從基礎表單向資料驅動遞進，其功能性逐漸提升，覆蓋更多業務場景。

從使用者需求的角度來看，低/無程式碼平臺可劃分為四大型別：

場景應用型

、

產品研發型

、

平臺生態型

和

技術賦能型

。

根據海比研究院調研資料，目前市場上共有低/無程式碼廠商74家。從各型別平臺商的數量分佈來看，場景應用型數量最多佔比達59。5%，說明終端應用的客戶是低程式碼的只要使用者，其次是產品研發型、平臺生態型和技術賦能型。

從各型別平臺商的年均收入規模來看，技術賦能型收入平均年收入最高，其次是平臺生態型，再次是產品研發型和場景應用型。綜合當前平臺生態型和技術賦能型數量不多但盈利能力較強，預計是未來廠商重點發展方向。

四、低程式碼的能力體現

從行業這麼多低程式碼產品的功能來看，低程式碼開發平臺的核心能力包括：

易用性。

在不寫程式碼的情況下能夠完成的功能多寡是決定平臺是否容易被接受的重要指標；

使用者體驗。

該指標能夠決定終端使用者對開發者的好評程度；

資料建模和管理。

應用複雜度越高，系統整合的要求越高，這個能力就越關鍵；

流程和業務邏輯。

決定了低程式碼支援的應用的寬度範圍；

介面和整合。

低程式碼不要為企業再造一個個資料孤島；

軟體開發週期支援。

除了開發和交付，還需要包含設計、反饋、測試、運維等多個環節；

服務質量。

所開發應用的故障率、穩定性，以及技術支援能力；

安全和合規。

需要在部署方式、系統安全機制和許可權管理和控制功能等層面提供全方位支援；

平臺生態。

獨木不成林，需要引入更多開發者，提供更豐富的解決方案，更好的賦能應用開發者。

和傳統的軟體開發的模式相比，低程式碼開發的流程極大的縮減，需要的崗位和人員也極大的減少，這就帶來了兩大優勢：

1）提高開發效率和降低成本

圖形化開發，大幅降低工作量；

有效規避程式碼本身的bug問題；

開發完成一鍵部署多個環境；

降低對開發者的要求，降低成本。

2）企業數字化轉型的有力工具

降低應用開發的准入門檻；

有助於打破資訊系統的孤島；

加速各種能力服務化的程序。

五、認識低程式碼的價值，也看清它的短板

任何新鮮事物的發展和火熱，我們都要先積極的擁抱它，只要它能幫助我們解決一定的問題，那麼它就是有價值的。所以梳理一下低程式碼開發的一些價值體現：

快速。

快速開發、快速反饋、快速調整，溝透過程中即可所見即所得開發；

低成本。

降低技術門檻，不需要專業技術人才就可以開發；

個性化支援。

透過靈活的元件、模組來解決各種個性化需求，而不需要去修改程式碼；

易維護。

採用元件化、線上組裝的方式，程式碼侵入少，更容易調整；

保護隱私。

減輕對外部廠商的依賴，保護企業資訊的隱私；

貼近業務價值。

專注於業務功能開發，甚至業務人員可以深度參與。

雖然低程式碼開發有很高的價值，但低程式碼並不是萬能的，它也有自己不擅長的領域，比如：

演算法和資料結構複雜的應用。

低程式碼開發此類應用的成本不亞於直接寫程式碼，甚至更高，無法發揮它的優勢；

對介面要求特別高的應用。

低程式碼平臺可不擅長做酷炫的介面，所以遊戲、動畫相關的應用並不適合；

超高流量網際網路的應用。

低程式碼開發中的效能大部分損失在配置解析，指令碼解析上，所以對於效能有著非常高的追求的網際網路應用並不適合；

分析和智慧化的應用。

分析有BI工具，智慧化應用更側重底層資料計算，這類的應用應該交給特定的專有工具實現；

系統軟體、科學計算等應用。

對於功能擴充套件性需求很弱，沒有可複用可抽象性，且底層計算很多，用低程式碼開發並不見得有優勢，甚至不可行。

所以，

低程式碼不是銀彈

，不要妄想透過引入低程式碼來解決你所有問題，它能解決的問題範圍有限，用對地方真正有效解決問題才是正道。它也

不是程式設計師終結者

，它只是數字化轉型應用開發中的一個補充，應用開發的主戰場還是coding，coding，coding。它淘汰的只是會CRUD的偽程式設計師。

寫好程式碼解決問題才是我們立足的根本。

六、我為什麼要搞低程式碼？

其實，十年前我在做工作流引擎和系統的時候，我認為就已經在從事低程式碼相關能力的開發和實踐了，雖然那時候前後端的技術體系並不是特別的完善，而且自己並不擅長前端頁面的構建，但是也基本上實現了拖拉拽的（雖然相比現在的介面過於簡陋）自定義的流程模型，視覺化的自定義表單設計，以及基本的許可權控制和指令碼植入。

前年我又在團隊中提出了低程式碼能力的建設，設計了以表單驅動為核心的低程式碼開發模組作為我們技術平臺和中臺能力的一種補充。當時出於對低程式碼的幾點認知：

1）要解決什麼問題？

① 隨訪產品中自定義隨訪的表單。

不同的臨床領域、不同的客戶，他的隨訪表單是不一樣的，這個是很難在研發時固化到系統中的。

② 專病健康檔案的設計和展示。

不同的病種，不同的客戶，在不同的應用下對於健康檔案的資料結構，展示的屬性是不一樣的，需要實現其靈活的擴充套件。

從應用場景上來說，主要是解決產品落地實施專案的時候解決個性化需求，以及產品使用過程中不斷擴充套件的需求。

2）使用的物件是誰？

首先，研發人員不是我設計低程式碼開發模組的目標使用者群體，因為對於很多研發人員來說，寫原生程式碼才能真正的體現自己的價值，另外即使需要快速開發，也會優先使用程式碼生成工具生成原生程式碼，並在此基礎上進行邏輯編寫。

那麼低程式碼開發面對的目標人群到底是誰呢？我們的定義是

專案實施工程師，部分產品經理或者醫學支援人員

。而零程式碼的功能可以開放給客戶使用，以幫助他們自助解決部分個性化問題。

低程式碼開發雖然不是一個新鮮的概念，但是由於科技的發展，企業發展訴求的變化，特別在企業數字化轉型的大趨勢面前，它脫胎換骨，有了更加高階的形態，這是時代的產物，這是趨勢的結果。

就像現在的特斯拉相比於上個世紀初的賓士，今天的智慧手機相比於十幾年前的諾基亞功能手機，同樣都是汽車、手機，但是它們所承載的作用，以及它們對於我們的意義都發生了巨大的變化。所以，不論是新瓶老酒還是老瓶新酒，只要能解決我們當前的問題，能夠體現它的價值，喝起來都是一樣的甘醇。

#專欄作家#

菜根老譚，微信公眾號：CGLT_TAN，人人都是產品經理專欄作家。經歷程式設計師、技術Leader、產品經理、研發Leader等多種崗位。現負責某科技公司整體產品研發，擅長企業IT架構及網際網路產品架構。

本文原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議