Low Code: 低程式碼，打造未來型企業

效率翻倍，成本大降！低程式碼開發革命，引爆應用程式新時代！Low-Code 當今最快建構可擴展 App 的捷徑

簡介： 何謂低程式碼技術？我們為何需求此一技術？此技術會導致程序員失業嗎？本篇文章匯總了低程式碼領域的基礎知識、核心價值及產業現狀，讓你全面理解低程式碼。

一、導言

若要以一個關鍵詞概括即將過去的2023年，那麼在後疫情時代，何種新興技術能真正釋放IT生產力，加速社會數位轉型，並使世界再次偉大？我認為答案是低程式碼（Low-Code） or 無程式碼 (No-Code)。

低程式碼技術基於經典的可視化及模型驅動理念，融合最新的雲原生技術及多端體驗技術，在合適的商業場景中能大幅提升效率降低成本，為專業開發者提供一種全新的高效開發新範式（Paradigm Shift）。此外，低程式碼也使非技術業務人員能成為所謂的平民開發者（Citizen Developer），彌補專業人才的缺口，同時促進業務與技術的深度協作，達到終極敏捷的合作形態（BizDevOps）。本文旨在深入介紹低程式碼的相關背景知識，包括其定義、意義、相關概念及行業發展等，期望能夠幫助讀者更深刻地理解這一新興領域。

二、Low-Code 低程式碼的定義

何為「Low-Code」？若你初次接觸，其實它指的是：低程式碼開發平台（Low-code development platform）。

維基百科的定義

以下是 Wiki 對於 Low-Code 的定義中，：

• 低程式碼開發平台（LCDP）本質上也是一種軟件，它為開發者提供創建應用軟件的環境。當你看到「開發環境」這幾個字，是不是覺得非常親切？對於程序員而言，低程式碼開發平台的本質與IDEA、VS等程式碼IDE（整合開發環境）非常相似，都是旨在提升開發者生產力的工具。
• 與傳統的程式碼IDE不同，低程式碼開發平台提供的是更高維度和易用性的視覺化IDE。在大多數情況下，開發者無需使用傳統的手寫程式碼方式進行編程，而是可以通過圖形化拖拉、參數配置等更高效的方式完成開發工作。

Forrester的定義

根據Forrester的描述，「Low-Code」一詞早在2014年就被提出，其對低程式碼開發平台的先驅級定義如下：

相比 Wiki 的版本，這個定義更偏向於闡明低程式碼帶來的核心價值：

• 低程式碼開發平台能夠實現業務應用的快速交付。這意味著，它不僅能夠像傳統開發平台一樣「能夠」開發應用，更重要的是，它使開發應用更加「快速」。更值得注意的是，這種快速是顛覆性的：根據Forrester在2016年的研究，大多數公司反饋低程式碼平台幫助他們將開發效率提升了5-10倍。隨著低程式碼技術、產品和行業的不斷成熟，這種提升的幅度還有望持續增加。
• 低程式碼開發平台也能夠降低業務應用的開發成本。一方面，低程式碼開發在軟件全生命周期的投入都要更低（程式碼編寫更少、環境設置和部署成本也更簡單）；另一方面，由於低程式碼開發大大降低了開發人員的使用門檻，非專業開發者經過簡單的IT基礎培訓就能快速上手，這不僅充分調動了企業現有的人力資源，也大幅降低了對昂貴專業開發者資源的依賴。

低程式碼的核心能力

基於以上的定義和分析，我們不難總結出低程式碼開發平台的三大核心能力：

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

低程式碼並不僅僅是少寫程式碼

回到最初的問題：Low-Code中的「Low」到底代表什麼？答案已經非常明顯：它既不指抽象程度低（相反，低程式碼開發方式的抽象程度要比傳統編程語言更高），也不是指程式碼質量低（相反，低程式碼生成的程式碼通常都經過精心維護和反覆測試，質量往往優於大多數手寫程式碼），而是字面上的「少寫程式碼」——只在少數需要的情況下手寫程式碼，其他大部分時候都能用視覺化等非程式碼方式解決。

深入探究，低程式碼不僅僅是關於少寫程式碼：寫得少，錯誤自然也就更少（正所謂「少做少錯」），因此開發階段的兩大核心工作「趕需求」和「修bug」都相對減少；要測試的程式碼少了，相應的測試用例也能減少不少；除了開發階段之外，平台還覆蓋了後續的應用構建、部署和管理，因此運維操作也大大簡化（Low-Code → Low-Ops）。

然而，「少」並不是最終目標：如果單純只是為了達到少的效果，砍需求、減人力、降低質量要求也可以達成相同的結果。低程式碼背後的哲學是「少即是多」（Less is More），或者更準確地說是「多快好省」（Do More with Less）——能做更多、上線更快、質量更好，且成本更省。

Low-Code 平台的職責與挑戰

以上所述是低程式碼為開發者提供的能力與吸引力，那麼作為服務的提供方和應用的承載者，低程式碼開發平台應該承擔什麼樣的職責，面對怎樣的挑戰呢？

依據《人月神話》一書作者Fred Brooks的分類，軟體開發的複雜性可以分為兩類：本質複雜性（Essential complexity）和附加複雜性（Accidental complexity）。前者代表解決問題時固有的最基本複雜性，與所用工具、經驗豐富與否或架構的優劣無關；後者則指在實際開發過程中額外引入的複雜性。通常，本質複雜性與需解決的特定業務問題緊密相關，故此我將之稱作「業務複雜度」以便更易理解；此種複雜度並非任何開發方法或工具所能解決，低程式碼亦然。至於附加複雜性，則主要與開發階段的技術細節緊密相關，故此我將之命名為「技術複雜度」；而正是這部分複雜度，低程式碼開發平台擅長且適宜處理的。

作為一個低程式碼開發平台，其核心職責應是盡可能地為開發者隔絕底層技術細節，減少不必要的技術複雜度，並支援他們更有效地應對業務複雜度，滿足靈活多變的業務場景需求。

三、低程式碼概念之比較

專業編碼（Pro-Code / Custom-Code）

「高級編碼」（與低程式碼形成對比）是一個更精確的稱謂，儘管這名稱略顯拗口，遭我所棄。傳統的程式碼IDE雖有部分開發工作可透過非程式碼方式進行（甚或更為適宜），例如：iOS開發時用的SwiftUI介面設計器、或是在後端開發中用於資料庫應用的PowerDesigner建模工具。然而，在傳統開發模式下，這些視覺化工具多半只起到輔助作用，最終仍轉化為開發者可直接修改的程式碼；開發者的主要工作仍圍繞程式碼展開。

低程式碼與專業編碼的關係，有如影片與文章之比：

• 低程式碼猶如當代「影片」，其內容大多由直觀、易理解且表達力強的圖像構成，故更易獲大眾青睞。然而，影片亦非僅限於圖像，適量文字（如字幕、註解）的加入可補足圖像表達之不足。關於「圖像」與「文字」的辯證關係，《架構製圖：工具與方法論》[1]中有更進一步的闡述。
• 專業編碼則較似傳統「文章」，長久以來作為資訊傳播的主要媒介。但隨著影片技術的誕生及相關基礎設施的普及，其地位逐漸受到影響。現今，多數人透過影片（從電視電影至短視頻平台）獲取資訊，而定期閱讀的人群卻日益減少。儘管如此，文章仍具其獨特意義和受眾群，倘若非如此，我亦不會費力撰寫如此之多文字。

根據以上類比，低程式碼的未來或將追隨影片的發展軌跡，最終超越專業編碼，成為主流開發方式。Gartner的預測亦支持此觀點：預計至2024年，所有應用程式開發活動中有65%將採用低程式碼方式進行，同時75%的大型企業將至少使用四種低程式碼開發工具。

然而低程式碼無法全然替代專業編碼。未來，低程式碼與專業編碼將以互補形式長期共存，各發光熱於其最適宜的業務場景中。後續「低程式碼業務場景」章節將詳述哪些場景當下更適合低程式碼開發方式。

低程式碼/ 無程式碼（Zero-Code / No-Code）

從完整性角度考慮，有「專業編碼」就應有其對立面「零編碼」（亦稱「無程式碼 No-Code」）。零編碼是一種完全不需撰寫程式碼的應用開發平台，但這並不意味著零編碼比低程式碼更先進，它僅僅是一種極端選擇：全然擁抱簡單的圖形視覺化，徹底摒棄文本程式碼。零編碼旨在極大降低應用開發門檻，使人人皆可成為開發者（開發 ≠ 寫程式碼），包括那些完全不懂程式碼的業務分析師、用戶運營人員，甚至是產品經理。

即便對專業開發者而言，在技術分工日益細化的趨勢下，招聘一名能獨立開發及維護整套複雜應用的全棧工程師亦越發困難。然而，零編碼或能改變此局面：無論是混淆Java與JavaScript的技術新手，或是精於深度學習卻未及學習Web開發的算法專家，均能透過零編碼實現其技術夢想或成為全棧工程師。「改變世界的想法已具，僅欠一名程序員」，這一玩笑或許終將成真；甚至無需程序員，有想法之人自可實現夢想。

然而，每一種選擇皆有其代價，零編碼亦不例外。完全摒棄程式碼意味著平台能力與靈活性的局限：

• 一方面，視覺化編輯器的表達能力遠不及圖靈完備的通用編程語言，不引入程式碼便難以實現靈活定製與擴展（理論上或可創建類似Scrach/Blockly的圖形編程語言，但那亦不過是另一種形式的程式碼編寫）。
• 另一方面，由於目標受眾為非專業開發者，平台所支援操作將趨向「傻瓜化」（例如，頁面僅支援大塊業務組件的堆疊，不支持細粒度元件與靈活CSS布局定義），同時也僅呈現相對「親民化」的模型與概念（如以「表格」代表數據，而非「資料庫」），無法支援專業的底層開發語言與編程理念。

儘管零編碼與低程式碼在狹義上有明顯差異，但從廣義上看，零編碼可視為低程式碼的一個分支。Gartner在其研究報告中將「No Code」納入了更廣泛的低程式碼應用平台「LCAP」（Low-Code Application Platform）範疇。而當前市場上許多通用的低程式碼開發平台也具備一定程度的零編碼能力；例如低程式碼領域的領導者Mendix，既提供了簡單易用的零編碼Web IDE - Mendix Studio，也擁有功能更全面的低程式碼桌面IDE - Mendix Studio Pro。

高效應用平台即服務（HpaPaaS）

正如前文所述，Forrester首創「低程式碼」一詞，而在國際知名研究領域的另一巨頭Gartner，亦不甘示弱，在概念創新的競賽中不願落後。於是在2017年，Gartner提出了「HpaPaaS」（High-productivity application Platform as a Service），這一名詞看似更具專業與規模感。

根據Gartner的界定，HpaPaaS是支持聲明式、模型驅動設計及一鍵式部署的平台，它提供雲端快速應用開發（RAD）、部署及運行功能，這與低程式碼的概念大致相同。然而，現實告訴我們，一個名詞的專業程度並不總是正面的，「HpaPaaS」終究未能超越更早出現、更貼近用戶、也更容易口語化的「低程式碼」。從2019年起，Gartner在其報告中開始全面采用「低程式碼」一詞（如LCAP），象徵性地為「HpaPaaS」畫上了淘汰符。

值得一提的是，「HpaPaaS」並非無中生有，而是承襲自Gartner早期提出的「aPaaS」概念，它們之間的關係是：HpaPaaS僅是aPaaS的一種形式。除了透過低程式碼實現的高效應用開發平台HpaPaaS外，aPaaS還包含針對專業編碼的傳統應用開發平台（High-control aPaaS，即高可控性的專業編碼開發方式）。

而提及「aPaaS」，這一概念與雲計算的興起息息相關。熟悉雲道的朋友們應能理解，aPaaS與IaaS/PaaS/SaaS等雲計算的基石概念相關聯：aPaaS位於PaaS和SaaS之間，相比於PaaS提供更偏向應用的服務，而又不同於SaaS所提供的現成軟體服務。更多細節可以參考上述圖源文章。

四、Low-Code之必要性

低程式碼究竟為何物或許並非至關重要，在這個資訊氾濫的時代，新奇之物屢見不鮮。多數所謂的新技術不過是曇花一現：出現了，被目睹了；大多數人略作驚嘆，表明不感興趣；少數人驚歎於其創新，激動點贊後仍回歸日常。真正決定新技術是否能轉化為生產力的，從不僅僅是技術本身的卓越與否，而是其是否真正滿足需求，即為何我們需要低程式碼？若從不同角度提問（一種稱為「延遲主語初始化」的技巧），可以更全面地探討此問題。

Gartner預計到2021年，應用開發需求的市場增長將至少是企業IT交付能力的五倍之多。面對這一巨大的IT缺口，若無一種創新性的「新生產力」體系，難以想像僅依賴現有的傳統技術體系就能解決這一問題。低程式碼技術應運而生，擔負著改革應用開發生產力、拯救即將步入困境的IT世界的重任。以下幾個方面特別凸顯了其革新意義：

提高效率、降低成本並保證質量

儘管軟體行業快速發展，新語言、框架和工具層出不窮，但必須承認，軟體開發依然停留在手工作坊階段，其效率低下、人力成本高昂、質量難以保證。項目延期交付成為常態，開發人員常是瓶頸所在；優秀的開發人才稀缺而昂貴；軟體缺陷層出不窮，線上故障頻發，導致持續的資損。

相對之下，傳統製造業經過數百年的工業革命，大多已擺脫對人的依賴：從原料到成品，整個過程由各種精密儀器和自動化流水線穩定支撐，實現了生產的標準化和規模化。儘管資訊化被譽為人類第三次工業革命，但軟體行業遠未達到成熟的「工業化」階段。

所以當你經歷了漫長的聯調、需求討論和bug修復，被連串的報警資訊從甜美夢境中驚醒時，是否仰望星空憧憬過：「I have a dream... that one day，軟體開發也能像工業產品那樣，實現批量化、流水線生產，穩定而高效。」現在，這個憧憬正逐漸變為現實。

是的，低程式碼正在實現應用軟體開發過程的工業化：每個低程式碼開發平台都像一個技術密集型的應用工廠，所有項目相關人員在同一生產線上緊密協作。開發主力不再是那些精通各種編程技巧的技術極客，而是充滿業務洞察力和創意的應用創造者。借助應用工廠中的成熟基礎設施、標準零件和自動化裝配線，開發者僅需專注於最核心的業務價值。即使面對特殊需求，也能隨時手動定製，靈活解決各種棘手問題。

擴大應用開發勞動力

通過簡化開發工作到僅需拖拽與配置，低程式碼顯著降低了使用門檻，使企業能更充分利用廣泛的開發資源。在純零程式碼需求場景下，低程式碼甚至能讓業務人員實現自助式應用交付，解決了傳統IT交付模式下的任務堆積問題，避免了稀缺的專業開發資源被大量簡單、重複性的應用開發需求佔據，同時讓業務人員能夠真正按照自己的想法實現應用，擺脫了依賴他人開發的束縛。

至此，應用開發能力不再是少數專業開發者的專利和特權，未來所需的技能門檻和擁有成本也將越來越低，真正實現所謂的「技術民主化」。

加強開發過程的溝通協作

多項研究顯示，軟體項目失敗的主要原因之一是溝通不暢。在傳統開發模式下，業務、產品、設計、開發、測試和運維人員各司其職，長期形成的「壁壘」使跨職能的溝通變得困難而低效。這也是為什麼當前流行的敏捷開發和DevOps都強調溝通，而經典的領域驅動設計也主張通過「統一語言」來減少業務與技術人員之間的溝通不一致。

有了低程式碼之後，這一狀況將得到根本改善：上述各角色都可以在同一個 Low-Code 開發平台上緊密協作（甚至可以是同一個人），這種全新的協作模式不僅打破了職能壁壘，還能通過統一的視覺化語言和單一的應用表現（頁面/數據/邏輯），輕鬆對齊項目各方對應用形態和項目進度的理解，實現更終極的敏捷開發模式，以及在傳統DevOps基礎上更進一步的BizDevOps。

聚合效應下的統一開發平台

當低程式碼將所有與應用開發相關的活動整合至單一平台時，將產生多方面的聚合效應及規模經濟：

• 人員聚集：除了前述的跨職能角色緊密協作之外，將人員集中至統一的低程式碼開發平台還有助於推動整個項目流程的標準化、規範化和一致化。
• 應用聚集：一方面，新應用的架構設計、資源重用和相互調用變得更加便捷；另一方面，應用間的數據自然互通，且平台外的數據也能通過整合能力實現連接，有效解決企業數據孤島問題。
• 生態聚集：當足夠多的開發者和應用集中到低程式碼開發平台時，將形成一個龐大而連通的生態系統，激發無限創意，釋放低程式碼的潛力。

Low-Code 現在的趨勢

觀察市場上各種低程式碼產品，不難發現許多參與者早在低程式碼概念誕生之前就已存在，例如：早在2001年成立的低程式碼巨頭OutSystems，以及1985年誕生的FileMaker。那為什麼低程式碼在過去並未大火，從技術和業務兩個角度可以歸納為以下原因：

技術成熟度不足

低程式碼的核心技術如視覺化、模型驅動、RAD等都有著悠久的發展歷史，似乎不過是舊酒新瓶。但事實上，任何技術都遵循「技術成熟度曲線」，不會一誕生就能大規模被採用。例如，儘管模型驅動技術早有理論研究和工具支持，但在當時的技術背景下，因能力不完善、過度理想化、技術門檻高等因素，未能成為主流。

然而，在當前這個時代，支持低程式碼的「舊」技術已經經過長期發展和市場檢驗，與此同時，完美互補的「新」技術如雲原生、響應式Web等也在迅速成熟，是時候通過低程式碼這一新概念重新包裝上市，為傳統IT市場帶來創新。

業務收益不明顯

即使早期的低程式碼技術已相對成熟，也未能在當時的市場產生顯著影響。原因在於技術始終服務於業務，而當時的業務需求遠不如今天複雜：缺乏多渠道、多體驗及各種整合和定製需求，對彈性、分散式和高可用性等特性的要求也不高，缺乏推動持續整合和快速交付的IT業務場景。

而在當前時代，企業對新技術帶來的能力和收益需求日益增長，期望以更低成本實現更高價值的應用交付。如果仍依賴傳統開發模式，這些要求的成本和工時可能早已超出可承受範圍；但現代化的低程式碼技術能以更低的成本實現這些願景，從而實現技術和業務的協同進步。

為什麼「專業開發者」也應關注 Low-Code？

儘管零程式碼主要面向非專業開發者，但其所能覆蓋的業務場景有限，無法真正革新傳統開發模式或取代需專業開發者參與的複雜場景。而低程式碼則有潛力實現這一轉變，因為它本質上是為專業開發者設計的。Gartner的研究顯示，多達66%的低程式碼平台用戶是企業IT部門的專業開發者，這說明專業開發者可能比一般用戶更需要低程式碼。

儘管低程式碼的開發過程中程式碼量減少，但開發本質並未改變。無論使用何種工具，創造和表達的核心活動始終不變。同理，應用開發的本質在於思維和邏輯，其價值不在於實現過程中使用的是傳統程式碼還是低程式碼。低程式碼有潛力成為下一代更高效的生產力工具，值得每位專業開發者關注。

精簡工作量的策略

低程式碼透過視覺化拖拽和參數配置的簡化開發模式，再結合模型驅動的自動程式碼生成機制，大幅減少了冗長重複的基礎程式碼（boilerplate code）工作。一站式的部署和運維管理平台省去了建立CI/CD流水線、申請環境資源、配置監控報警等繁瑣步驟。同時，一次性搭建可同步生成、構建和發布多端應用，消除了手動維護多個端應用的重複勞動。開箱即用的組件庫、模板庫、主題庫、連接器等，極大地促進了軟體的重用性。總的來說，低程式碼讓專業開發者能更專注於創新性、有價值、具特色的工作，而非耗費時間在那些非核心的瑣碎事務上。

強大的平台能力支撐

儘管上述提到的技術支持性工作不直接產生業務價值，但它們對業務的性能、成本、穩定性、安全性和可持續發展能力有直接影響。有遠見的企業不會為了短期的業務加速而犧牲這些關鍵指標。低程式碼開發平台深知這一點，因此在簡化底層技術細節的同時，也努力確保它們能夠提供的部分至少和傳統程式碼開發一樣好，甚至更好。這包括但不限於：

• 現代化技術架構和實現：採用業界最佳實踐和現代技術標準，例如前端基於HTML5/CSS3和React框架，後端基於Java語言、SpringBoot框架和MySQL資料庫等。
• 零成本技術升級和維護：高度抽象的開發方式讓核心業務邏輯與底層技術細節解耦，使開發者無需關心技術選型和追蹤技術升級，同時享受持續的技術進步和安全性提升。

一體化生態能力復用

復用是提升軟體開發效率和質量的關鍵策略。在低程式碼世界裡，不僅可通過頁面組件庫、邏輯函數庫、應用模板庫等提供多層次、多粒度的復用手段，而且 Low-Code 平台的一體化生態優勢還能提供強大且易用的復用資產發現、整合和共享系統。平台的生態越豐富，積累的可復用資源就越多，開發成本也相應降低。

相對於傳統程式碼開發，雖然整體生態更大、更深厚，但由於缺乏統一平台和市場、技術整合成本高等問題，往往無法形成有效的復用體系。低程式碼則改變了這一局面，提供了一種更高效、更可持續的開發模式。

低程式碼並未消除應用開發的核心要素：嚴謹的業務邏輯、巧妙的演算法設計、良好的工程風格等。對於專業開發者而言，低程式碼提供了一種更現代、更高效的工具，而不是取代他們的技能和創造力。即使在低程式碼的時代，深入了解底層系統、精通算法和高質量程式碼的專業開發者依然是極有價值的。

對「我不需要低程式碼」的反思

儘管低程式碼的優勢被廣泛認同，仍有些人會表達「我不需要低程式碼」的觀點。這些質疑背後或許有一定的道理，但在我看來，往往更多是源於主觀偏見或無意識的偏好。以下是一些對低程式碼常見質疑的解析，旨在提供一個更全面和客觀的視角。

質疑1：低程式碼平台無法滿足需求

「我試用過一些所謂低程式碼平台，發現要麼功能有限，要麼體驗糟糕，只適合開發簡單應用。」
我的看法是：不能一概而論。國內低程式碼市場正處於快速發展階段，許多產品或許只是初入低程式碼領域，但這並不代表所有低程式碼平台都一樣。真正成熟的企業級低程式碼平台有足夠的能力滿足複雜的功能需求，並提供必要的安全、性能和可擴展性，這在國際市場已經得到證實。

質疑2：低程式碼平台不可控

「低程式碼平台上的視覺化組件和邏輯都是黑盒，一旦出問題無法自行排查和解決。」
作為一名喜歡深究底層原理的開發者，我理解這種擔憂。但應看到這是低程式碼領域發展中的暫時問題，而非技術本質上的缺陷。任何技術都有成熟過程，隨著低程式碼領域的健康發展，這些問題會逐步減少，最終達到大多數人可接受的水平。

質疑3：低程式碼應用難以維護

「一旦應用變複雜，混雜自定義程式碼和複雜邏輯，變得難以理解和修改，不如純程式碼清晰。」
我認為，不論是低程式碼還是純程式碼開發，應用的可維護性主要取決於開發者是否遵循軟體開發的基本原則。好的低程式碼平台不會阻礙開發者提高應用可維護性，反而會提供必要的支持和指導。而應用複雜性過高往往是業務本身的特點，低程式碼通過高度抽象和自動化，在降低複雜度方面有其獨特優勢。

低程式碼行業的發展前景

對於一個行業來說，最好的回應質疑的方式是不斷自我完善並展現實際成效。評估一個行業當前的表現和未來潛力，可以從以下幾個角度考慮：市場規模、適用場景和競爭狀態。

Low-Code 與 No-Code 市場規模

市場的聲音是最真實的：Forrester於2015年預測，低程式碼市場規模將從2015年的17億美元增長至2023年的150億美元。Marketsandmarkets於2020年預測，2023年低程式碼市場規模將達130億美元，到2025年將增長至450億美元。這些數據顯示，低程式碼技術正逐漸成為一個巨大且持續增長的市場。

這些觀點不僅反映出低程式碼領域的挑戰，也揭示了其潛力和發展機遇。隨著技術的成熟和市場的認知提升，低程式碼將持續塑造軟體開發的未來。

No Code 與 Low Code 領域有兩個核心觀點：

• 市場規模巨大且持續快速增長：低程式碼技術擁有巨大的市場潛力，特別是在亞太地區，預計將在未來幾年內超過全球平均增速。
• 適用範圍廣泛但仍有限制：理論上，低程式碼能夠支持各種業務場景，但實際上，由於技術、產品和市場的成熟度，某些場景仍然更適合使用傳統的純程式碼方法。

Gartner在2019年的研究中描繪了一個低程式碼適用場景的「應用金字塔」模型，從工作組級到企業級再到極端規模的企業級，展示了低程式碼適用性隨應用規模和複雜度的變化。這表明，低程式碼在不同層次的應用中都有潛在的應用價值，但其契合度和效率會根據具體情況有所不同。

在競品方面，低程式碼市場已有多個成熟玩家，如OutSystems和Mendix，以及大型科技公司如Salesforce和Microsoft等，這些公司提供的低程式碼解決方案已在國際市場上得到認可和應用。這證明了低程式碼技術的可行性和商業潛力。

結論是，雖然低程式碼領域仍在發展中，並面臨諸多挑戰和質疑，但其核心價值、市場潛力和適用範圍的廣闊使其成為值得關注的技術趨勢。理解低程式碼的基本概念、核心價值和行業現狀是深入掌握和有效應用這一技術的前提。

Learn more about Low-Code

• No Code/ Low Code - Tenten 科技與設計週報
• 如何使用 Retool 搭建內部工具平台
• 如何用 No-code 協助企業數位転型? Tenten 創辦人專訪
• 想創業嗎? 快來認識這 16個 no code 工具吧！
• 2023 年每個企業都需要的無代碼工具
• Low-Code 和 No-Code 有什麼差別？初學者必讀
• 企業在使用無代碼 /低代碼 (No Code) 開發之前應該問的 5 個問題
• No-Code 無程式碼是什麼？當設計網站不再需要Coding的時候..