什么是低代碼（Low-Code）？

什么是低代碼（Low-Code）？

簡介： 什么是低代碼？我們為什么需要低代碼？低代碼會讓程序員失業嗎？本文總結了低代碼領域的基本概念、核心價值與行業現狀，帶你全面了解低代碼。

一 前言如果選擇用一個關鍵詞來代表即將過去的2020年，我相信所有人都會認同是“新冠”。疫情來得太快就像龍卷風，短短數月就阻斷了全世界范圍內無數人與人之間的物理連接。但好在，我們已經全面邁入互聯網時代：N95口罩再厚，也阻擋不了信息比特流的順暢流通（宅男：B站依然香）；居家隔離再久，也妨礙不了釘釘消息的準時送達（社畜：工作依然苦）。逍遙子在9月份的云棲大會上說：“新技術代表的新生產力，一定是我們全速戰勝疫情、開創未來最好的原動力。” 那么在后疫情時代，究竟需要什么樣的新技術，才能真正解放IT生產力，加速社會數字化轉型，Make The World Great Again？我認為是低代碼（Low-Code）。基于經典的可視化和模型驅動理念，結合最新的云原生與多端體驗技術，低代碼能夠在合適的業務場景下實現大幅度的提效降本，為專業開發者提供了一種全新的高生產力開發范式（Paradigm Shift）。另一方面，低代碼還能讓不懂代碼的業務人員成為所謂的平民開發者（Citizen Developer），彌補日益擴大的專業人才缺口，同時促成業務與技術深度協作的終極敏捷形態（BizDevOps）。本文將重點介紹低代碼相關背景知識，包括低代碼的定義與意義、相關概念、行業發展等，期望能幫助大家更好地認識與理解低代碼這個新興領域。二 什么是低代碼“Low-Code”是什么？如果你是第一次聽說，沒準也會跟我當年從老板口中聽到這個詞后的內心戲一樣：啥？“Low-Code”？“Code”是指代碼我知道，但這個“Low”字是啥意思？不會是老板發現我最近趕工寫的代碼很丑很“Low”吧… 想多了，老板怎么可能親自review代碼呢。那難道是指，“Low-level programming”里的“Low”？老板終于發現讓我等編程奇才整天堆Java業務代碼太浪費，要派我去閉關寫一個高性能C語言網絡庫… 顯然也不是，老板哪能有這技術情懷呢。那到底是什么意思？作為一名搜商比情商還高的程序員，能問Google的絕不會問老板。于是我一頓操作后，不假思索地點開了第一條搜索結果。果不其然，這是一條充滿自由芳香只有翻墻才能聞到的Wikipedia詞條：Low-code development platform。Wikipedia定義

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

低代碼開發平臺（LCDP）本身也是一種軟件，它為開發者提供了一個創建應用軟件的開發環境。看到“開發環境”幾個字是不是很親切？對于程序員而言，低代碼開發平臺的性質與IDEA、VS等代碼IDE（集成開發環境）幾乎一樣，都是服務于開發者的生產力工具。與傳統代碼IDE不同的是，低代碼開發平臺提供的是更高維和易用的可視化IDE。大多數情況下，開發者并不需要使用傳統的手寫代碼方式進行編程，而是可以通過圖形化拖拽、參數配置等更高效的方式完成開發工作。

Forrester定義順著Wiki的描述還能發現，原來“Low-Code”一詞早在2014年就由Forrester提出了，它對低代碼開發平臺的始祖級定義是這樣的：

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

低代碼開發平臺能夠實現業務應用的快速交付。也就是說，不只是像傳統開發平臺一樣“能”開發應用而已，低代碼開發平臺的重點是開發應用更“快”。更重要的是，這個快的程度是顛覆性的：根據Forrester在2016年的調研，大部分公司反饋低代碼平臺幫助他們把開發效率提升了5-10倍。而且我們有理由相信，隨著低代碼技術、產品和行業的不斷成熟，這個提升倍數還能繼續上漲。低代碼開發平臺能夠降低業務應用的開發成本。一方面，低代碼開發在軟件全生命周期流程上的投入都要更低（代碼編寫更少、環境設置和部署成本也更簡單）；另一方面，低代碼開發還顯著降低了開發人員的使用門檻，非專業開發者經過簡單的IT基礎培訓就能快速上崗，既能充分調動和利用企業現有的各方面人力資源，也能大幅降低對昂貴專業開發者資源的依賴。

低代碼核心能力基于上述的定義和分析，不難總結出如下這3條低代碼開發平臺的核心能力：

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

不只是少寫代碼回到最初那個直擊心靈的小白問題：Low-Code中的“Low”，到底是啥意思？答案已經顯而易見：既不是指抽象程度很低（相反，低代碼開發方式的抽象程度要比傳統編程語言高一個level），也不是指代碼很low（也相反，低代碼所生成的代碼一般都經過精心維護和反復測試，整體質量強于大部分手寫代碼），而是單純的“少寫代碼” —— 只在少數需要的情況下才手寫代碼，其他大部分時候都能用可視化等非代碼方式解決。再往深一點兒看，低代碼不只是少寫代碼而已：代碼寫得少，bug也就越少（正所謂“少做少錯”），因此開發環節的兩大支柱性工作“趕需求”和“修bug”就都少了；要測的代碼少了，那么測試用例也可以少寫不少；除了開發階段以外，平臺還覆蓋了后續的應用構建、部署和管理，因此運維操作也更少了（Low-Code → Low-Ops）。然而，少并不是最終目的：如果單純只是想達到少的效果，砍需求減人力、降低質量要求也是一樣的。低代碼背后的哲學，是少即是多（Less is More），或者更準確說是多快好省（Do More with Less） —— 能力更多、上線更快、質量更好，成本還更省，深刻踐行了阿里“既要，又要，還要”的價值觀精髓。

在盡到上述職責的同時，低代碼開發平臺作為一個面向開發者的產品，還需要致力于為開發者提供簡單直觀的極致開發體驗。這背后除了巨大的工作量，還得能在“強大”和“易用”這兩個很難兩全其美的矛盾點之間，努力找到一個符合自己產品定位與目標客戶需求的平衡點 —— 這也許是設計一個通用低代碼開發平臺所面臨的最大挑戰。三 低代碼相關概念對比純代碼（Pro-Code / Custom-Code）“純代碼”可能算是我杜撰的一個詞，更常見的說法是-碼（Pro-Code）或定制代碼（Custom-Code）；但意思都一樣，就是指傳統的以代碼為中心（Code-Centric）的開發模式。之所以我選擇用“純代碼”，是因為如果用“-碼”會顯得似乎低代碼就不專業了一樣，而用“定制代碼”又容易讓人誤解成低代碼無法支持定制的自定義代碼。當然，更準確的稱謂我認為是“高代碼”（與低代碼恰好對應，只是名字太難聽，被我嫌棄了…），因為即便是使用傳統的代碼IDE，有些開發工作也支持（甚至更適合）以非代碼方式完成，比如：iOS端開發時使用的SwiftUI界面設計器、服務端開發數據庫應用時使用的PowerDesigner建模工具。不過這部分可視化工作在傳統開發模式下只是起輔助作用，最后通常也是生成開發者可直接修改的代碼；開發者仍然是以代碼為中心來開展主要工作。低代碼與純代碼之間的關系，其實跟視頻和文章之間很像：

低代碼就像是現代的“視頻”，大部分內容都由直觀易理解、表達能力強的圖片組成，因此更容易被大眾所接受。但與此同時，視頻也不是死板得只能有圖片，完全可以添加少量文字（如字幕、標注）來彌補圖片表達不夠精確的問題。BTW，關于“圖”和“文字”之間的辯證關系，可以進一步參考《架構制圖：工具與方法論》[1]這篇文章中的相關描述。純代碼則更像是傳統的“文章”，雖然很久以來都一直是信息傳播的唯一媒介，但自從視頻技術誕生以及相應軟硬件基礎設施的普及以來，便逐漸開始被搶走了風頭。如今，視頻已成為大部分人獲取信息的主要渠道（從電視電影到B站抖音），而經常讀書讀文章的人卻越來越少。但不可否認的是，文章依然有它存在的意義和受眾（不然我也不會費這勁敲這么多字了），即使“市場份額”一直在被擠壓，但永遠會有它立足的空間。

如果按上面這種類比關系推導，低代碼未來也會遵循與視頻類似的發展軌跡，超越純代碼成為主流開發模式。Gartner的預測也表達了相同的觀點：到2024年，所有應用程序開發活動當中的65%將通過低代碼的方式完成，同時75%的大型企業將使用至少四種低代碼開發工具進行應用開發。但同樣地，就像是視頻永遠無法取代文章一樣，低代碼也永遠無法徹底取代純代碼開發方式。未來低代碼和純代碼方式將以互補的形態長期共存，各自在其所適合的業務場景中發光發熱。在后面的“低代碼業務場景”章節，會詳細列出哪些場景在現階段更適合用低代碼模式開發。零代碼（Zero-Code / No-Code）從分類的完備性角度來看，有“純代碼”自然也應該有完全相反的“零代碼”（也稱為“無代碼”）。零代碼就是完全不需要寫代碼的應用開發平臺，但這并不代表零代碼就比低代碼更高級和先進，它只是做了一個更極端的選擇而已：徹底擁抱簡單的圖形可視化，完全消滅復雜的文本代碼。選擇背后的原因是，零代碼開發平臺期望能盡可能降低應用開發門檻，讓人人都能成為開發者（注意：開發 ≠ 寫代碼），包括完全不懂代碼的業務分析師、用戶運營，甚至是產品經理（不懂裝懂可不算懂）。即便是專業開發者，在技術分工越來越精細的趨勢下（前端/后端/算法/SRE/數據分析..），也很難招到一個能獨立開發和維護整套復雜應用的全棧工程師。但零代碼可以改變這一切：無論是Java和JavaScript傻傻分不清楚的技術小白，還是精通深度學習但沒時間學習Web開發的算法大牛，都可以通過零代碼實現自己的技術夢或全棧夢。“改變世界的idea已有，就差一個程序員了”，這句玩笑話或許真的可以成真；哦不，甚至都用不著程序員，有idea的人自己就能上。

當然，所有選擇都要付出代價，零代碼也不例外。完全拋棄代碼的代價，就是平臺能力與靈活性受限：

一方面，可視化編輯器的表達能力遠不及圖靈完備的通用編程語言，不引入代碼根本沒法實現靈活的定制與擴展（當然，理論上也可以做成Scrach/Blockly那樣的圖形編程語言，但那樣不過是換一種形式在手寫代碼而已）。另一方面，由于目標受眾是非專業開發人員，平臺能支持的操作會更趨于“傻瓜化”（e.g. 頁面只支持大塊業務組件的簡單堆疊，不支持細粒度原子組件和靈活的CSS布局定義），同時也只會透出相對“親民化”的模型和概念（e.g. 使用“表格”表示數據，而不是用“數據庫”），無法支撐強大專業的底層開發原語和編程理念。

Gartner預測，到2021年應用開發需求的市場增長將至少超過企業IT交付能力的5倍。面對如此巨大的IT缺口，如果沒有一種革命性的“新生產力”體系，很難想象僅憑現有傳統技術體系的發展延續就能徹底解決問題。而低代碼技術正是帶著這樣的使命而降臨，期望通過以下幾個方面徹底革新應用開發生產力，拯救差一點就要邁入水深火熱的IT世界：提效降本 & 質量保障雖然軟件行業一直在高速發展，新的語言、框架和工具層出不窮，但作為從業者我們不得不承認：軟件開發仍處于手工作坊階段，效率低、人力成本高、質量不可控。項目延期交付已成為行業常態，而瓶頸幾乎總是開發人員（對機器能解決的問題都不是問題）；優秀的開發人才永遠是稀缺資源，還賊貴；軟件質量缺陷始終無法收斂，線上故障頻發資損不斷。相比而言，傳統制造業經過幾百年工業革命的發展，大部分早已擺脫了對“人”的強依賴：從原料輸入到制品輸出，中間是各種精密儀器和自動化流水線的穩定支撐，真正實現生產的標準化和規模化。雖然信息化號稱是人類的第三次工業革命，但以軟件行業目前的狀況，遠遠還沒到達成熟的“工業化”階段。所以，親愛的程序員朋友，當你與前端聯調了一上午接口，又與產品撕逼了一下午需求，再與自己的bug抗爭了一整晚，好不容易遁入夢鄉又被一連串報警短信吵醒時，是否有抬頭對著星空憧憬過：“I have a dream… that one day，軟件開發也能像工業制品一樣，批量流水化生產，穩定高效沒煩惱。” 事到如今，不管你有沒有意識到，這個憧憬正在慢慢變成現實。

是的，低代碼正在將應用軟件開發過程工業化：每個低代碼開發平臺都是一個技術密集型的應用工廠，所有項目相關人員都在同一條產線內緊密協作。開發主力不再是熟知for循環一百種寫法的技術Geek，而是一群心懷想法業務sense十足的應用Maker。借助應用工廠中各種成熟的基礎設施、現成的標準零件、自動化的裝配流水線，開發者只需要專注于最核心的業務價值即可。即便是碰到非標需求，也可以隨時自己動手，用最靈活的手工定制（代碼）方式來解決各種邊角問題。擴大應用開發勞動力通過讓大部分開發工作可以僅通過簡單的拖拽與配置完成，低代碼（包括零代碼）顯著降低了使用者門檻，讓企業能夠充分利用前面所提到的平民開發者資源。部分純零代碼需求場景下，低代碼還能讓業務人員實現自助式（self-service）應用交付，既解決了傳統IT交付模式下的任務堆積（backlog）問題，避免稀缺的專業開發資源被大量簡單、重復性的應用開發需求所侵占，也能讓業務人員真正按自己的想法去實現應用，擺脫交由他人開發時不可避免的桎梏。

有了低代碼后，這一狀況將得到根本改善：上述各角色都可以在同一個低代碼開發平臺上緊密協作（甚至可以是同一個人），這種全新的協作模式不僅打破了職能豎井，還能通過統一的可視化語言和單一的應用表示（頁面/數據/邏輯），輕松對齊項目各方對應用形態和項目進度的理解，實現更終極的敏捷開發模式，以及在傳統DevOps基礎之上更進一步的BizDevOps[2]。統一開發平臺下的聚合效應低代碼嘗試將所有與應用開發相關活動都收斂到同一個平臺（one platform）上后，將會產生更多方面的聚合效應與規模收益：

人員聚合：除了上一點所提到的各職能角色緊密協作以外，人員聚合到統一的低代碼開發平臺進行作業后，還能促進整個項目流程的標準化、規范化和統一化。應用聚合：一方面，新應用的架構設計、資產復用、相互調用變得更容易；另一方面，各應用的數據都天然互通，同時平臺外數據也能通過集成能力進行打通，徹底消除企業的數據孤島問題。生態聚合：當低代碼開發平臺聚合了足夠多的開發者和應用后，將形成一個巨大的、連接一切、有無限想象力的生態體系，徹底放飛低代碼的價值。

為什么「這個時代」才需要低代碼？如果你了解過市面上各種低代碼產品，不難發現其實這個領域的許多玩家在低代碼概念誕生之前就已經存在了，比如：低代碼領域的另一個巨頭OutSystems，早在2001年就已經創立；而去年也被Forrester評為低代碼行業leader之一的FileMaker，更是誕生于遙遠的1985年（正好35歲，似乎在瘋狂暗示什么）。那么，如果低代碼像前面說的那么好，為什么以前沒有火起來呢？從技術和業務兩個角度看，可以歸納為以下原因：技術成熟度不足低代碼底層的各項核心技術（可視化、模型驅動、RAD、BPMS…）都已經有漫長的發展歷史，看上去似乎只是新瓶裝舊酒。然而理智的人都知道，任何技術都會遵循所謂的“技術成熟度曲線”（The Hype Cycle），不可能剛一誕生就跳過發育直接秀翻全場，被大規模采納和投入生產。以模型驅動技術為例，雖然十幾年前就已經有體系化的理論研究（e.g. MDA）和配套工具（e.g. EMF），但在當時的技術背景下，由于能力不完備、過于理想化、技術門檻高等原因，一直沒能在工業界走向主流。

而如今這個時代，支撐低代碼的那些“老”技術都已經過長時間的發展醞釀與市場檢驗，而另一些完美互補的“新”技術（e.g. 云原生、響應式Web）也在飛速發展和走向成熟，是時候通過“低代碼”這個新酒瓶重新包裝上市，為亟需新生產力的傳統IT市場帶來一場真香之旅了。業務收益不明顯即使十幾年前的低代碼技術已經足夠成熟，也一定不會在當年的應用開發市場上產生現在這樣的影響力。為什么？因為技術都是為業務服務的，而當時的應用開發業務需求可比現在簡單多了：沒有如今的多渠道（Multi-channel）、多樣化體驗（Multi-experience）和各種集成與定制需求，也不會奢求如今已成為企業級應用標配的彈性、分布式和高可用，更是缺乏快速變化的IT業務場景來推動持續集成與快速交付。雖然低代碼可以完美解決上述所有問題（e.g. 多端應用生成、云原生架構、API集成能力），但放在當年的市場和業務背景下，加上前面所說的技術不成熟度，整體的投入產出比會很低，不足以讓企業大面積采納低代碼解決方案。

現代化的技術架構和實現：現代化的低代碼開發平臺，在支撐用戶應用時所選擇的技術架構與實現方案，也會是現代化且符合業界最佳實踐的，例如，前端基于主流的HTML5/CSS3標準和React框架，后端基于成熟的Java語言、SpringBoot框架和MySQL數據庫，部署環境基于云原生的Docker鏡像、CI/CD流水線、K8s集群和Service Mesh技術（相關知識可參考《正確入門Service Mesh：起源、發展和現狀》）。零成本的技術升級和維護：低代碼的高維抽象開發方式，讓應用的核心業務邏輯與底層技術細節徹底解耦。開發者在大部分情況下都不需要關心底層技術選型，同時也無需親自跟進這些技術的版本升級與漏洞修復，免費享受與時俱進的技術紅利和應用安全性提升。即便遇到某些底層技術或工具需要進行徹底更換（比如不再維護的開源項目），開發者也完全不必感知；技術遷移再費勁再難搞，平臺自己努力就行，對開發者來說只要服務一直在線，歲月就依然靜好；事后可能還會驚喜地發現，應用訪問突然就變得更快了，仿佛冥冥中自有天助，感激上蒼和低代碼。

“試用過一些所謂的低代碼開發平臺，要么能力很弱，要么體驗太差，只能開發點玩具應用。”

作為調研過國內外多款低代碼產品的深度體驗用戶，我的觀點是：不能以偏概全。低代碼市場在國內正處于爆發初期，所以許多與低代碼只沾一點邊的產品也都在蹭熱點；但它們并不能代表低代碼目前的業界水平和發展方向。市面上真正成熟的企業級低代碼開發平臺，完全有能力以高效的開發方式滿足大部分復雜場景的功能需求，以及企業級應用所需要的安全、性能、可伸縮等非功能需求，這一點在國外市場已得到充分驗證（不然也不會這么被寄予厚望）。當然，國內市場尚處于魚龍混雜的混戰階段，遇到真龍的概率很低，但碰上金魚鯉魚甚至木頭假魚都在所難免。相信隨著時間推移，真正有實力和口碑的產品都能脫穎而出，為大家展現低代碼該有的樣子。質疑2：低代低開發不可控

“平臺上的各種可視化組件、邏輯動作和部署環境都是黑盒，如果內部出問題無法排查和解決。”

作為同樣不搞清楚底層原理不舒服斯基的程序員，我更愿意相信：問題只是暫時的。雖然這確實是目前使用低代碼平臺時繞不開的一個痛點，但并不屬于低代碼技術本身的固有缺陷。計算機領域有一句至理名言：任何問題都可以通過增加一個間接的中間層來解決。低代碼的思路亦是如此：與當年的操作系統和現在的云平臺一樣，都是想通過建立一個黑盒化的中間層抽象來降低開發者的工作量與心智負擔。當然，所有額外增加的中間層都不是完全免費的，低代碼也不例外。作為一個尚未成熟穩定的新的中間層，低代碼必然會出現各種讓使用者束手無措的問題，就跟當年的操作系統內核bug、如今的云主機I/O hang一樣。但歷史規律也告訴我們，所有偉大的技術最終都會走向成熟；只要低代碼領域一直健康發展，問題總會越來越少，最終降到一個絕大部分人感知不到的范圍內。過去縈繞在Windows用戶心中揮之不去的“藍屏”問題，對如今的新用戶來說早已不知為何物；今天低代碼開發者所遇到的種種“藍瘦”問題，未來也終將成為被遺忘的歷史（誰還沒段黑歷史呢）。質疑3：低代碼應用難維護

“應用一旦復雜起來，各種復雜邏輯流穿插著自定義代碼，看不懂也改不動，還不如全用代碼呢。”

作為對軟件可維護性深有感觸的無腦級布道者（見《救火必備！問題排查與系統優化手冊》），我不得不說：用低代碼開發，也要講基本法。一般來說，無論是使用低代碼開發還是純代碼開發，造成應用可維護性低的根本原因往往不在于開發工具，而是開發者自身沒有去遵循一些軟件開發的普適原則，比如工程規范性、命名可讀性、DRY/KISS/SOLID原則等。好的低代碼平臺絕不會阻礙開發者去改善應用的可維護性；恰恰相反，還會盡可能提供引導和幫助。以Mendix為例，除了支持基本的模型分析與重構（e.g. 無用模型、對象重命名、子邏輯流提取）以外，甚至還提供了基于ISO/IEC 25010標準的應用質量監控（AQM）能力。另一方面，讓應用變得難以維護的一個客觀原因也是應用本身過于復雜，而低代碼作為高度抽象和自動化的開發模式，在降低應用復雜度方面是專業的。綜合來看，低代碼雖然不是能解決一切問題的銀彈，但更不是會帶來更多問題的炸彈：在提高應用可維護性方面的上限，一定比傳統開發模式更高；但決定應用可維護性下限的，依然還是開發者自己。五 低代碼行業發展回應質疑的最好方式，就是做好你自己，用實際的表現說話。對于一個行業而言，判斷它當前的表現是否夠好，或者未來是否有潛力做到更好，可以從以下這三個方面進行衡量：市場規模（蛋糕夠不夠大）、適用場景（是否可落地）、競品狀況（有沒有被驗證過）。市場規模

“Talk is cheap，show me the code money.”

—— Linus Starcraft

文章可以忽悠，但市場不會說謊：

Forrester在2015年曾預測過，低代碼的市場將從2015年的17億美元增長至2020年的150億美元。Marketsandmarkets在今年四月份的分析報告中預測，低代碼的市場將從2020年的130億美元（估算值，可以看出來與Forrester當年的預測是接近的）增長到2025年的450億美元（年復合增長率：28.1%）。PS Inteligence在2018年的分析報告中預測，全球的低代碼開發平臺市場中，亞太地區將在今后五年（2019-2024年）中保持最高的增長速度。

總結一下就是兩點：

低代碼的市場規模足夠大，且一直都在高速增長。作為亞太地區的經濟大國與IT強國，中國的低代碼市場將會引來一個爆發期，未來幾年內的增速都會超過全球平均水平。

適用場景理論上來說，低代碼是完全對標傳統純代碼的通用開發模式，應該有能力支撐所有可能的業務場景。但理論也只是理論，低代碼一統江湖的夢想尚未照進現實，也不可能完全取代現實。前文中提到過，低代碼與純代碼方式是互補關系，未來也將長期共存，各自在其所適合的業務場景中發光發熱。同時還需要指出的是，當前階段的低代碼技術、產品和市場都尚未完全成熟，因此部分本來可能很適合用低代碼來開發的場景，目前也只能先用純代碼來替代。Gartner在2019年的低代碼調研報告中，曾經繪制過一張用來闡述低代碼適用場景的“應用金字塔”：

應用級別劃分：從下往上，分別為工作組級（Workgroup Class）、部門級（Departmental Class）、企業級（Enterprise Class）、可擴展需求極強的企業級（Extreme-Scale Enterprise Class）。容易看出來，它主要的劃分維度就是應用所面向的用戶基數（基數越大，可擴展需求也越高）。任務關鍵性：從下往上，各級別應用的任務關鍵性（Mission Criticality）逐級遞增。例如一個只在工作組內使用的后臺管理應用，一般都不會涉及到影響整個企業的關鍵任務。脫離企業這個視角來看，整個軟件產業中也有很多通用的任務關鍵型應用，比如：實時操作系統、航空調度系統、銀行對賬系統。實現復雜度：從下往上，各級別應用的復雜度（Complexity）也逐級遞增。例如最上層的企業級應用，除了功能覆蓋面大導致業務復雜以外，往往還需要滿足更多苛刻的非功能需求，包括但不限于：用戶體驗、性能、可靠性、安全性、可伸縮性、可維護性、兼容性。其他一些復雜軟件的案例包括：3D游戲界面（交互復雜）極其底層的游戲引擎（邏輯復雜）、超大型CRM系統（一方面是實現很復雜，另一方面，這種成熟軟件的標準化程度較高，大部分情況下可以直接用現成的SaaS軟件）。應用需求量：從上往下，各級別應用的需求體量（Volume）逐級遞增，呈現一個金字塔形狀。這個特征可以用萬能的2/8原則來理解：20%的“全民”應用，由于需求的通用性和普適性，可以覆蓋至少80%的用戶群體（例如企業大部分人都要用的考勤系統）；而剩下那80%的“小眾”應用，由于需求的定制化和特殊性（例如螞蟻的期權系統…），就只能覆蓋各自小圈子里那20%的用戶了。與低代碼的契合關系：從上往下，各級別應用與低代碼越來越契合（Relevant）。也就是說：越簡單的應用，越契合低代碼；越不太關鍵的任務，也越契合低代碼。同時，由于契合低代碼的應用更偏金字塔底層，而這些應用的需求量都更大，所以可以得出如下判斷：低代碼能夠適用于大部分業務場景（而且這個比例會一直上升，逐步往金字塔的更上層應用逼近），例如：B2E類應用（表單、審批流、ERP系統）、B2B類應用（企業商城、工業控制臺）、B2C類應用（企業展示、營銷頁、店鋪裝修）。

競品概況低代碼雖然是一個新興概念，但這個行業本身并不算很新（前文也有提到），這些年以來早就積累了不少資深的榮耀王者。同時，低代碼作為一個朝陽產業和資本熱點，近幾年也不斷有更多的新玩家在加入這個刺激戰場。

上圖分別是Gartner給出的低代碼平臺魔力象限和Forrester給出的低代碼平臺技術波譜。從圖中可以看到：

OutSystems和Mendix一馬當先，是公認的低代碼領域頭牌。這兩家都是很純粹的通用低代碼開發平臺，且都經過了長時間的發展和積累：OutSystems成立于2001年，員工人數1000+，年營收超過1億美元；2018年6月獲得了KKR和高盛的3.6億美元融資，目前估值超過10億美元；Mendix成立于2005年，員工人數500+，年營收超過2300萬美元（18年數據），2018年8月被西門子以7.3億美元收購。Salesforce和Microsoft緊隨其后，都處于行業領先者地位。但這兩家的公司性質和發展路徑都很不一樣：Salesforce是以SaaS起家，公司規模就不用多說了，反正就是SaaS屆的巨無霸。這類SaaS廠商做低代碼的動力，是為了解決客戶對成品SaaS軟件的定制訴求。M$更不用多介紹，只說下他們做低代碼的天然優勢：一方面，作為辦公軟件航空母艦，低代碼可以幫助他們的客戶實現從Excel表單到定制App的能力與體驗升級；另一方面，作為云計算三巨頭之一，低代碼可以幫助他們連接內部的云計算生態體系，為開發者提供一個統一和易用的上云界面。國外市場已經得到充分驗證，但國內市場還剛剛興起，還沒有一家能夠贏得上述調研機構的芳心，擠進上面這兩張方圖。國內目前的一些競品和融資情況包括：2018年5月，搭搭云完成A輪的千萬級融資；2018年9月，宜創科技得到清源創投的戰略融資；2018年12月，輕流完成千萬級Pre-A融資；2019年8月，數式科技得到盈動資本的數千萬人民幣天使輪融資；2019年8月，ClickPaas獲得晨興資本數百萬美元的A輪融資；2019年，奧哲分別獲得阿里5千萬的A+輪融和高榕資本上億元的B輪融資。（注：競品數據來源于我們組PD的辛勤整理；為此我決定這篇文章剩下內容再也不黑PD了；下篇再說。）

六 結語本文總結了低代碼領域的基本概念、核心價值與行業現狀。雖然這些內容都比較基礎和偏理論，但我始終認為，深刻理解一個系統的前提，正是這些務虛的東西 —— 技術架構只會告訴你這個系統是怎么實現的（How），無法準確表述它到底能用來做什么（What），以及為什么要做這樣一個東西（Why）；而后面這兩個問題的答案，才是后續系統所有設計與演進的根因和驅動力。作者：返回搜狐，查看更多

責任編輯：

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。