什麼是低代碼（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 的絕不會問老闆。于是我一頓操作後，不假思索地點開了第一條搜尋結：Low-code development platform。

1. Wikipedia 定義

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

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

2. Forrester 定義

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

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

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

3. 低代碼核心能力

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

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

4. 不隻是少寫代碼

回到最初那個直擊心靈的小白問題：Low-Code 中的 “Low”，到底是啥意思？答案已經顯而易見：既不是指抽象程度很低（相反，低代碼開發方式的抽象程度要比傳統程式設計語言高一個 level），也不是指代碼很 low（也相反，低代碼所生成的代碼一般都經過精心維護和反複測試，整體品質強于大部分手寫代碼），而是單純的“少寫代碼” —— 隻在少數需要的情況下才手寫代碼，其他大部分時候都能用可視化等非代碼方式解決。

再往深一點兒看，低代碼不隻是少寫代碼而已：代碼寫得少，bug 也就越少（正所謂“少做少錯”），是以開發環節的兩大支柱性工作“趕需求”和“修 bug”就都少了；要測的代碼少了，那麼測試用例也可以少寫不少；除了開發階段以外，平台還覆寫了後續的應用建構、部署和管理，是以運維操作也更少了（Low-Code → Low-Ops）。

然而，少并不是最終目的：如果單純隻是想達到少的效果，砍需求減人力、降低品質要求也是一樣的。低代碼背後的哲學，是少即是多（Less is More），或者更準确說是多快好省（Do More with Less） —— 能力更多、上線更快、品質更好，成本還更省，深刻踐行了阿裡“既要，又要，還要”的價值觀精髓。

5. 平台的職責與挑戰

上面說的是低代碼給開發者提供的能力與吸引力，那麼作為服務的提供方與應用的承載者，低代碼開發平台自身應該承擔怎樣的職責，其中又會遇到多大的挑戰？是否就一定要如阿裡雲所主張的那樣，“把複雜留給自己，把簡單留給别人”？雖然這句話聽起來很深明大義，但不知道大家有沒有想過，為什麼我們一定要抱着複雜不放，平白無故給自己找事？就不能直接幹掉複雜，也給咱阿裡雲自己的員工留點簡單嗎？是工作太容易就展現不出來 KPI 價值了，還是家裡的飯菜不如公司的宵夜香？

冥思苦想許久後，我從熱力學第一定律中找到了答案：開發一個應用的總複雜度是恒定的，隻能轉移而不可能憑空消失。要想讓開發者做的更少，安心享受簡單的快樂，那麼平台方就得做的更多，默默承擔盡可能多的複雜度。就像一個滿身腱子肉的雜技男演員，四平八穩地托舉着在高處旋轉與跳躍的女搭檔；上面的人顯得越輕盈越毫不費力，下面的人就得越穩重越用盡全力。當然，不是說上面的女演員就很輕松沒壓力，隻是他們各自的分工不同，所承擔的複雜度也不一樣。

根據《人月神話》作者 Fred Brooks 的劃分，軟體開發的複雜度可以劃分為本質複雜度（Essential complexity ）和偶然複雜度（Accidental complexity）。前者是解決問題時固有的最小複雜度，跟你用什麼樣的工具、經驗是否豐富、架構好不好等都無關，而後者就是除此之外在實際開發過程中引入的複雜度。通常來說，本質複雜度與業務要解決的特定問題域強相關，是以這裡我把它稱為更好了解的“業務複雜度”；這部分複雜度不是任何開發方法或工具能解決的，包括低代碼。而偶然複雜度一般與開發階段的技術細節強相關，是以我也相應把它稱為“技術複雜度”；而這一部分複雜度，恰好就是低代碼所擅長且适合解決的。

為開發者盡可能屏蔽底層技術細節、減少不必要的技術複雜度，并支撐其更好地應對業務複雜度（滿足靈活通用的業務場景需求），這是身為一個低代碼開發平台所應該盡到的核心職責。

在盡到上述職責的同時，低代碼開發平台作為一個面向開發者的産品，還需要緻力于為開發者提供簡單直覺的極緻開發體驗。這背後除了巨大的工作量，還得能在“強大”和“易用”這兩個很難兩全其美的沖突點之間，努力找到一個符合自己産品定位與目标客戶需求的平衡點 —— 這也許是設計一個通用低代碼開發平台所面臨的最大挑戰。

低代碼相關概念對比

1. 純代碼（Pro-Code / Custom-Code）

“純代碼”可能算是我杜撰的一個詞，更常見的說法是專業代碼（Pro-Code）或定制代碼（Custom-Code）；但意思都一樣，就是指傳統的以代碼為中心（Code-Centric）的開發模式。之是以我選擇用“純代碼”，是因為如果用“專業代碼”會顯得似乎低代碼就不專業了一樣，而用“定制代碼”又容易讓人誤解成低代碼無法支援定制的自定義代碼。

當然，更準确的稱謂我認為是“高代碼”（與低代碼恰好對應，隻是名字太難聽，被我嫌棄了...），因為即便是使用傳統的代碼 IDE，有些開發工作也支援（甚至更适合）以非代碼方式完成，比如：iOS 端開發時使用的 SwiftUI 界面設計器、服務端開發資料庫應用時使用的 PowerDesigner 模組化工具。不過這部分可視化工作在傳統開發模式下隻是起輔助作用，最後通常也是生成開發者可直接修改的代碼；開發者仍然是以代碼為中心來開展主要工作。

低代碼與純代碼之間的關系，其實跟視訊和文章之間很像：

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

如果按上面這種類比關系推導，低代碼未來也會遵循與視訊類似的發展軌迹，超越純代碼成為主流開發模式。Gartner 的預測也表達了相同的觀點：到 2024 年，所有應用程式開發活動當中的 65% 将通過低代碼的方式完成，同時 75% 的大型企業将使用至少四種低代碼開發工具進行應用開發。

但同樣地，就像是視訊永遠無法取代文章一樣，低代碼也永遠無法徹底取代純代碼開發方式。未來低代碼和純代碼方式将以互補的形态長期共存，各自在其所适合的業務場景中發光發熱。在後面的“低代碼業務場景”章節，會詳細列出哪些場景在現階段更适合用低代碼模式開發。

2. 零代碼（Zero-Code / No-Code）

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

即便是專業開發者，在技術分工越來越精細的趨勢下（前端/後端/算法/SRE/資料分析..），也很難招到一個能獨立開發和維護整套複雜應用的全棧工程師。但零代碼可以改變這一切：無論是 Java 和 JavaScript 傻傻分不清楚的技術小白，還是精通深度學習但沒時間學習 Web 開發的算法大牛，都可以通過零代碼實作自己的技術夢或全棧夢。“改變世界的 idea 已有，就差一個程式員了”，這句玩笑話或許真的可以成真；哦不，甚至都用不着程式員，有 idea 的人自己就能上。

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

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

雖然零代碼與狹義上的低代碼有着上述明顯差異，但從廣義上來說，零代碼可以當作低代碼的一個子集。Gartner 在其相關調研報告中，就是将 “No Code” 劃在了範圍更廣的低代碼應用平台“LCAP”（Low-Code Application Platform）中。而目前市面上很多通用的低代碼開發平台，也都兼具一定程度的零代碼能力；比如低代碼領域領頭羊 Mendix，既提供了簡單易用的零代碼 Web IDE - Mendix Studio，也包括一個功能更強大的低代碼桌面 IDE - Mendix Studio Pro。

3. HpaPaaS（高生産力應用 PaaS）

上文提到，“Low-Code” 一詞是拜 Forrester 所賜。作為同樣是國際知名調研機構（a.k.a 造詞小能手）的 Gartner，顯然不會輕易在這場可能決定低代碼領域江湖地位的新概念作詞大賽中認輸，于是也于 2017 年發明了 “HpaPaaS”（High-productivity application Platform as a Service）這個聽上去更高大上的縮寫詞。

按照 Gartner 的定義，HpaPaaS 是一種支援聲明式、模型驅動設計和一鍵部署的平台，提供了雲上的快速應用開發（RAD）、部署和運作特性；這顯然與低代碼的定義如出一轍。但事實證明，名字起得太專業并不見得是好事，“HpaPaas” 最終還是敗給了起源更早、更接地氣也更順口的 “Low-Code”：從 2019 年開始，Gartner 在其相關調研報告中也開始全面采用 “Low-Code” 一詞（如 LCAP），親手為 “HpaPaaS” 打上了 @deprecated 印記。

圖源：

https://blog.kintone.com/business-with-heart/difference-saas-iaas-paas-apaas-hpapaas

值得補充的是，“HpaPaaS“ 這個詞也并非橫空出世，而是傳承自更早之前 Gartner 提出的 “aPaaS”，它倆之間的關系是：HpaPaaS 隻是 aPaaS 的一個子類；除了 HpaPaaS 這種通過低代碼實作的高生産力應用開發平台以外，aPaaS 還包括面向純代碼的傳統應用開發平台（High-control aPaaS，即可控度更高的純代碼開發方式）。

不值得但就想八卦一下的是，“aPaaS” 這個詞也非憑空捏造，而是與雲計算的興起淵源頗深。相信各位雲道中人都已猜到，aPaaS 與 IaaS/PaaS/SaaS 這些雲計算遠古概念是一脈相承的：aPaaS 介于 PaaS 和 SaaS 之間，相比 PaaS 提供的服務更偏應用，但又不像 SaaS 一樣提供現成的軟體服務（更詳細的說明可參考配圖來源文章）。

為什麼需要低代碼？

低代碼是什麼可能并沒那麼重要，畢竟在這個資訊爆炸的世界，永遠不缺少新奇而又短命的事物。大部分所謂的新技術都隻是昙花一現：出現了，被看到了；大部分人“哦”了一聲，已閱但表示不感興趣；小部分人驚歎于它的奇思妙想，激動地點了個贊後，回過頭來該用什麼還是什麼。真正決定新技術是否能轉化為新生産力的，永遠不是技術本身有多麼優秀和華麗，而是它是否真的被需要，即：為什麼需要低代碼？如果用不同的主語填充上面這個問句（冷知識：這叫做“延遲主語初始化”），可以更全面地看待這個問題：

1. 為什麼「市場」需要低代碼？

在這個大爺大媽都滿嘴“網際網路+”和“數字化轉型”的時代，企業越來越需要通過應用（App）來改善企業内部的資訊流轉、強化與客戶之間的觸點連接配接。然而，誕生還不太久的 IT 資訊時代，也正面臨着與我國社會主義初級階段類似的供需關系沖突：落後的軟體開發生産力跟不上人民日益增長的業務需求。

Gartner 預測，到 2021 年應用開發需求的市場增長将至少超過企業 IT 傳遞能力的 5 倍。面對如此巨大的 IT 缺口，如果沒有一種革命性的“新生産力”體系，很難想象僅憑現有傳統技術體系的發展延續就能徹底解決問題。而低代碼技術正是帶着這樣的使命而降臨，期望通過以下幾個方面徹底革新應用開發生産力，拯救差一點就要邁入水深火熱的 IT 世界：

1）提效降本 & 品質保障

雖然軟體行業一直在高速發展，新的語言、架構和工具層出不窮，但作為從業者我們不得不承認：軟體開發仍處于手工作坊階段，效率低、人力成本高、品質不可控。項目延期傳遞已成為行業常态，而瓶頸幾乎總是開發人員（對機器能解決的問題都不是問題）；優秀的開發人才永遠是稀缺資源，還賊貴；軟體品質缺陷始終無法收斂，線上故障頻發資損不斷。

相比而言，傳統制造業經過幾百年工業革命的發展，大部分早已擺脫了對“人”的強依賴：從原料輸入到制品輸出，中間是各種精密儀器和自動化流水線的穩定支撐，真正實作生産的标準化和規模化。雖然資訊化号稱是人類的第三次工業革命，但以軟體行業目前的狀況，遠遠還沒到達成熟的“工業化”階段。

是以，親愛的程式員朋友，當你與前端聯調了一上午接口，又與産品撕逼了一下午需求，再與自己的 bug 抗争了一整晚，好不容易遁入夢鄉又被一連串報警短信吵醒時，是否有擡頭對着星空憧憬過：“I have a dream... that one day，軟體開發也能像工業制品一樣，批量流水化生産，穩定高效沒煩惱。” 事到如今，不管你有沒有意識到，這個憧憬正在慢慢變成現實。

是的，低代碼正在将應用軟體開發過程工業化：每個低代碼開發平台都是一個技術密集型的應用工廠，所有項目相關人員都在同一條産線内緊密協作。開發主力不再是熟知 for 循環一百種寫法的技術 Geek，而是一群心懷想法業務 sense 十足的應用 Maker。借助應用工廠中各種成熟的基礎設施、現成的标準零件、自動化的裝配流水線，開發者隻需要專注于最核心的業務價值即可。即便是碰到非标需求，也可以随時自己動手，用最靈活的手工定制（代碼）方式來解決各種邊角問題。

2）擴大應用開發勞動力

通過讓大部分開發工作可以僅通過簡單的拖拽與配置完成，低代碼（包括零代碼）顯著降低了使用者門檻，讓企業能夠充分利用前面所提到的平民開發者資源。部分純零代碼需求場景下，低代碼還能讓業務人員實作自助式（self-service）應用傳遞，既解決了傳統 IT 傳遞模式下的任務堆積（backlog）問題，避免稀缺的專業開發資源被大量簡單、重複性的應用開發需求所侵占，也能讓業務人員真正按自己的想法去實作應用，擺脫交由他人開發時不可避免的桎梏。

至此，應用開發能力不再是少數專業開發者的專利和特權，且今後所需要的技能門檻與擁有成本也會越來越低，真正實作所謂的“技術民主化”（democratization of technology）。

3）加強開發過程的溝通協作

多方調查結果顯示，軟體項目失敗的最主要原因之一就是缺乏溝通（poor communication）。傳統開發模式下，業務、産品、設計、開發、測試與運維人員各司其職，且各有一套領域内的工具和語言，長久以來很容易形成一個個“豎井”（silos），讓跨職能的溝通變得困難而低效。這也是為什麼目前熱門的靈活開發和 DevOps 都在強調溝通（前者是協同 Biz 與 Dev，而後者是協同 Dev 和 Ops），而經典的 DDD 領域驅動設計也主張通過“統一語言”來減少業務與技術人員之間的溝通不一緻。

有了低代碼後，這一狀況将得到根本改善：上述各角色都可以在同一個低代碼開發平台上緊密協作（甚至可以是同一個人），這種全新的協作模式不僅打破了職能豎井，還能通過統一的可視化語言和單一的應用表示（頁面/資料/邏輯），輕松對齊項目各方對應用形态和項目進度的了解，實作更終極的靈活開發模式，以及在傳統 DevOps 基礎之上更進一步的

BizDevOps

。

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

低代碼嘗試将所有與應用開發相關活動都收斂到同一個平台（one platform）上後，将會産生更多方面的聚合效應與規模收益：

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

2. 為什麼「這個時代」才需要低代碼？

如果你了解過市面上各種低代碼産品，不難發現其實這個領域的許多玩家在低代碼概念誕生之前就已經存在了，比如：低代碼領域的另一個巨頭 OutSystems，早在 2001 年就已經創立；而去年也被 Forrester 評為低代碼行業leader之一的 FileMaker，更是誕生于遙遠的 1985 年（正好 35 歲，似乎在瘋狂暗示什麼）。那麼，如果低代碼像前面說的那麼好，為什麼以前沒有火起來呢？從技術和業務兩個角度看，可以歸納為以下原因：

1）技術成熟度不足

低代碼底層的各項核心技術（可視化、模型驅動、RAD、BPMS...）都已經有漫長的發展曆史，看上去似乎隻是新瓶裝舊酒。然而理智的人都知道，任何技術都會遵循所謂的“技術成熟度曲線”（The Hype Cycle），不可能剛一誕生就跳過發育直接秀翻全場，被大規模采納和投入生産。以模型驅動技術為例，雖然十幾年前就已經有體系化的理論研究（e.g. MDA）和配套工具（e.g. EMF），但在當時的技術背景下，由于能力不完備、過于理想化、技術門檻高等原因，一直沒能在工業界走向主流。

而如今這個時代，支撐低代碼的那些“老”技術都已經過長時間的發展醞釀與市場檢驗，而另一些完美互補的“新”技術（e.g. 雲原生、響應式 Web）也在飛速發展和走向成熟，是時候通過“低代碼”這個新酒瓶重新包裝上市，為亟需新生産力的傳統IT市場帶來一場真香之旅了。

2）業務收益不明顯

即使十幾年前的低代碼技術已經足夠成熟，也一定不會在當年的應用開發市場上産生現在這樣的影響力。為什麼？因為技術都是為業務服務的，而當時的應用開發業務需求可比現在簡單多了：沒有如今的多管道（Multi-channel）、多樣化體驗（Multi-experience）和各種內建與定制需求，也不會奢求如今已成為企業級應用标配的彈性、分布式和高可用，更是缺乏快速變化的IT業務場景來推動持續內建與快速傳遞。

雖然低代碼可以完美解決上述所有問題（e.g. 多端應用生成、雲原生架構、API 內建能力），但放在當年的市場和業務背景下，加上前面所說的技術不成熟度，整體的投入産出比會很低，不足以讓企業大面積采納低代碼解決方案。

而如今這個時代，企業都快被新技術帶來的能力和收益“慣壞了”，動不動就是：我想做一個送菜應用。使用者端？安卓、iOS、H5、小程式都來一套。營運端？一般都在電腦上看，但記得手機上也得适配啊。服務端？上雲，必須的。哦，我聽技術合夥人說現在流行多雲架構，也給我整一套哈。運維還要錢？啥是運維？應用有了不就能用了嘛，運維還要花我錢？你當投資者給我的錢是大風刮來的啊！

如果用傳統的開發模式，這麼全套下來的工時與報價，可能早就吓跑了這群跟産品經理一樣天真可愛的人；但現代化的低代碼技術，可以圓了上面這位創業者的賣菜夢，用白菜一般的價格，實作白粉一樣的價值。當年的程維如果能用上現在的低代碼，第一版的滴滴 App 也就不至于被外包做得烏煙瘴氣直接報廢了（至少能多扛一陣子...）。

3. 為什麼「專業開發者」也需要低代碼？

雖然零代碼确實是設計給非專業開發者用的，但其所能支撐的業務場景确實有限，無法真正革新傳統開發模式，替代那些仍需專業開發者參與的複雜業務場景。而狹義上的低代碼卻有潛力做到這一點，因為它天生就是為專業開發者而量身定制的。Gartner 最近的一項調研報告顯示，“66% 的低代碼開發平台使用者都是企業 IT 部門的專業開發者”。這充分說明了，專業開發者比平民開發者更需要低代碼。

螢幕前一批穿格子襯衫的同學要發問了：“低代碼都不怎麼寫代碼了，怎麼能算是為我們程式員服務呢？”。雖然程式員讨厭重複自己，但重要的事情還是得多說一遍：開發 ≠ 寫代碼。1 萬年前蹲在洞穴裡的原始人，在用小石子畫遠古圖騰；100 年前坐在書桌前的徐志摩，在用鋼筆給林徽因寫情書；而今天趴在螢幕前的很多人，相信都已經開始用上手寫闆或 iPad 塗塗寫寫了。千百年來，人類使用的工具一直在演進，但所從事活動的本質并沒有多大改變。無論是用小石子還是小滑鼠，寫作繪畫的本質都是創造與表達，最終作品的好壞并不取決于當時你手中拿着什麼；同樣地，應用開發的本質是想法和邏輯，最終價值的高低也不取決你實作時是用的純代碼還是低代碼。

而相比純代碼而言，低代碼極有可能成為更好的下一代生産力工具：

1）減少不必要的工作量

可視化拖拽與參數配置的極簡開發模式，結合模型驅動的代碼自動生成機制，可以消滅絕大部分繁瑣和重複的 boilerplate 代碼；一站式的部署和運維管理平台，無需自己搭建 CI/CD 流水線、申請環境資源、配置監控報警；一次搭建同時生成、建構和釋出多端應用，免去人工同步維護多個功能重複的端應用；開箱即用的元件庫、模闆庫、主題庫、連接配接器等，讓最大化軟體複用成為可能。總而言之，低代碼能夠讓專業開發者更專注于創新性、有價值、有區分度的工作，而不是把寶貴開發時間都耗費在上面那些不必要的非業務核心工作上。

2）強大的平台能力支撐

雖然上面列的技術支撐性工作并不直接産生業務價值，但卻會直接影響業務的性能、成本、穩定性、安全性、可持續發展能力等。有遠見的企業，絕不允許犧牲這些重要名額，來換取短暫的業務加速。低代碼開發平台深知這一點，是以在簡化和屏蔽底層技術細節的同時，也會盡可能把自己所 cover 的部分做到最好（至少能和純代碼開發方式一樣好），包括但不限于：

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

3）一體化生态能力複用

複用（Reuse）是提升軟體開發效率和工程品質的最有效途徑。傳統的代碼開發模式下，開發者可以通過提取公共類/函數、引用共享庫、調用外部 API 服務、沉澱代碼片段和模闆等方式實作複用。在低代碼的世界裡，平台也可以提供對應的多層次多粒度複用手段，比如頁面元件庫、邏輯函數庫、應用模闆庫等。

但更重要的是，低代碼平台還可以充分發揮其一體化的生态優勢，提供強大易用的可複用能力（資産）的發現、內建與共享體系：以頁面元件為例，你可以直接用系統元件，也可以在平台自帶的元件市場上搜尋和引用更合适的元件，還可以自己用代碼開發一個自定義元件并釋出到市場中。平台的生态體系越大，積累的可複用能力就越多，應用的開發成本也會越低。

相比而言，雖然傳統代碼世界整體生态更龐大和深厚，但由于各類技術不互通、缺乏統一平台與市場、代碼內建成本高等原因，一直以來都沒有形成有類似規模潛力的生态能力複用體系，導緻重複造輪子和低水準重複建設的現象司空見慣，還美名為“新基建”。

說到這裡，另一批裹着沖鋒衣頭頂锃亮的同學也忍不住了：“萬一低代碼真的發展起來了，是不是就不需要那麼多程式員了啊？上有老下有小的，同是碼農身，相煎何太急！”。低代碼雖然是一場應用開發生産力革命，但并不會革掉程式員的飯碗。它去掉的隻是難懂的程式設計文法、繁瑣的技術細節和一切可自動化的重複性工作，并沒有也無法去掉應用開發最核心的東西：嚴謹的業務邏輯、巧妙的算法設計、良好的工程風格等。對于真正的程式員，即使剝去他一層又一層的程式設計語言和工具熟練度技能外殼，最終剩下的仍然是一個有價值的硬核開發者。

當然，如果你堅持要用純粹的寫代碼方式來改變世界，也不至于失業。要麼，你可以選擇那些低代碼暫時不太适用的領域，比如底層系統驅動、3D 遊戲引擎、火箭發射程式；或者，你也可以選擇去寫低代碼中那一部分不可或缺的自定義代碼擴充，為平民開發者提供高品質的積木。最後，你也完全可以選擇為低代碼平台本身的底層代碼添磚加瓦，比如加入阿裡雲雲原生應用研發平台 EMAS 團隊 (〃'▽'〃) ，與作者一起共建下一代雲原生低代碼開發平台“Mobi”，内推直達郵箱：pengqun.pq # alibaba-inc.com。

4. 為什麼「我不」需要低代碼

即使所有人都認同上述“為什麼要用低代碼”的理由，但仍不時會有試水者跳出來，給大家細數“為什麼我不需要低代碼”。實踐出真知沒錯，而且大部分質疑背後也都有一定道理；但在我看來，更多的可能是主觀或無意識的偏見。這裡我列了一些對低代碼的常見質疑和我個人的看法，期望能幫助大家看到一個更全面和客觀的低代碼。

質疑 1：低代碼平台不好使

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

作為調研過國内外多款低代碼産品的深度體驗使用者，我的觀點是：不能以偏概全。低代碼市場在國内正處于爆發初期，是以許多與低代碼隻沾一點邊的産品也都在蹭熱點；但它們并不能代表低代碼目前的業界水準和發展方向。市面上真正成熟的企業級低代碼開發平台，完全有能力以高效的開發方式滿足大部分複雜場景的功能需求，以及企業級應用所需要的安全、性能、可伸縮等非功能需求，這一點在國外市場已得到充分驗證（不然也不會這麼被寄予厚望）。

當然，國内市場尚處于魚龍混雜的混戰階段，遇到真龍的機率很低，但碰上金魚鯉魚甚至木頭假魚都在所難免。相信随着時間推移，真正有實力和口碑的産品都能脫穎而出，為大家展現低代碼該有的樣子。

質疑 2：低代低開發不可控

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

作為同樣不搞清楚底層原理不舒服斯基的程式員，我更願意相信：問題隻是暫時的。雖然這确實是目前使用低代碼平台時繞不開的一個痛點，但并不屬于低代碼技術本身的固有缺陷。計算機領域有一句至理名言：任何問題都可以通過增加一個間接的中間層來解決。低代碼的思路亦是如此：與當年的作業系統和現在的雲平台一樣，都是想通過建立一個黑盒化的中間層抽象來降低開發者的工作量與心智負擔。

當然，所有額外增加的中間層都不是完全免費的，低代碼也不例外。作為一個尚未成熟穩定的新的中間層，低代碼必然會出現各種讓使用者束手無措的問題，就跟當年的作業系統核心 bug、如今的雲主機 I/O hang 一樣。但曆史規律也告訴我們，所有偉大的技術最終都會走向成熟；隻要低代碼領域一直健康發展，問題總會越來越少，最終降到一個絕大部分人感覺不到的範圍内。過去萦繞在 Windows 使用者心中揮之不去的“藍屏”問題，對如今的新使用者來說早已不知為何物；今天低代碼開發者所遇到的種種“藍瘦”問題，未來也終将成為被遺忘的曆史（誰還沒段黑曆史呢）。

質疑 3：低代碼應用難維護

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

作為對軟體可維護性深有感觸的無腦級布道者（見

《救火必備！問題排查與系統優化手冊》

），我不得不說：用低代碼開發，也要講基本法。一般來說，無論是使用低代碼開發還是純代碼開發，造成應用可維護性低的根本原因往往不在于開發工具，而是開發者自身沒有去遵循一些軟體開發的普适原則，比如工程規範性、命名可讀性、DRY/KISS/SOLID 原則等。

好的低代碼平台絕不會阻礙開發者去改善應用的可維護性；恰恰相反，還會盡可能提供引導和幫助。以 Mendix 為例，除了支援基本的模型分析與重構（e.g. 無用模型、對象重命名、子邏輯流提取）以外，甚至還提供了基于 ISO/IEC 25010 标準的應用品質監控（AQM）能力。另一方面，讓應用變得難以維護的一個客觀原因也是應用本身過于複雜，而低代碼作為高度抽象和自動化的開發模式，在降低應用複雜度方面是專業的。

綜合來看，低代碼雖然不是能解決一切問題的銀彈，但更不是會帶來更多問題的炸彈：在提高應用可維護性方面的上限，一定比傳統開發模式更高；但決定應用可維護性下限的，依然還是開發者自己。

低代碼行業發展

回應質疑的最好方式，就是做好你自己，用實際的表現說話。對于一個行業而言，判斷它目前的表現是否夠好，或者未來是否有潛力做到更好，可以從以下這三個方面進行衡量：市場規模（蛋糕夠不夠大）、适用場景（是否可落地）、競品狀況（有沒有被驗證過）。

1. 市場規模

"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強國，中國的低代碼市場将會引來一個爆發期，未來幾年内的增速都會超過全球平均水準。

2. 适用場景

理論上來說，低代碼是完全對标傳統純代碼的通用開發模式，應該有能力支撐所有可能的業務場景。但理論也隻是理論，低代碼一統江湖的夢想尚未照進現實，也不可能完全取代現實。前文中提到過，低代碼與純代碼方式是互補關系，未來也将長期共存，各自在其所适合的業務場景中發光發熱。同時還需要指出的是，目前階段的低代碼技術、産品和市場都尚未完全成熟，是以部分本來可能很适合用低代碼來開發的場景，目前也隻能先用純代碼來替代。

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 類應用（企業展示、營銷頁、店鋪裝修）。

3. 競品概況

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

上圖分别是 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）；而後面這兩個問題的答案，才是後續系統所有設計與演進的根因和驅動力。

雖然程式員真的不喜歡重複自己，但備援也是一種必要的容錯手段，好東西真的不容錯過：歡迎各位技術同路人加入阿裡雲雲原生應用研發平台 EMAS 團隊，我們專注于廣泛的雲原生技術（Backend as a Service、Serverless、DevOps、低代碼平台等），緻力于為企業、開發者提供一站式的應用研發管理服務，内推直達郵箱：pengqun.pq # alibaba-inc.com。