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

阿里雲 雲原生應用研發平臺EMAS 彭羣（楚衡）

1、前言

若是選擇用一個關鍵詞來表明即將過去的2020年，我相信全部人都會認同是「新冠」。疫情來得太快就像龍捲風，短短數月就阻斷了全世界範圍內無數人與人之間的物理鏈接。但好在，咱們已經全面邁入互聯網時代：N95口罩再厚，也阻擋不了信息比特流的順暢流通（宅男：B站依然香）；居家隔離再久，也妨礙不了釘釘消息的準時送達（社畜：工做依然苦）。逍遙子在9月份的雲棲大會上說：「新技術表明的新生產力，必定是咱們全速打敗疫情、開創將來最好的原動力。」 那麼在後疫情時代，究竟須要什麼樣的新技術，才能真正解放IT生產力，加速社會數字化轉型，Make The World Great Again？我認爲是低代碼（Low-Code）。

基於經典的可視化和模型驅動理念，結合最新的雲原生與多端體驗技術，低代碼可以在合適的業務場景下實現大幅度的提效降本，爲專業開發者提供了一種全新的高生產力開發範式（Paradigm Shift）。另外一方面，低代碼還能讓不懂代碼的業務人員成爲所謂的平民開發者（Citizen Developer），彌補日益擴大的專業人才缺口，同時促成業務與技術深度協做的終極敏捷形態（BizDevOps）。本文將重點介紹低代碼相關背景知識，包括低代碼的定義與意義、相關概念、行業發展等，指望能幫助你們更好地認識與理解低代碼這個新興領域。

2、什麼是低代碼

「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） —— 能力更多、上線更快、質量更好，成本還更省，深入踐行了阿里「既要，又要，還要」的價值觀精髓。

平臺的職責與挑戰

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

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

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

爲開發者儘量屏蔽底層技術細節、減小沒必要要的技術複雜度，並支撐其更好地應對業務複雜度（知足靈活通用的業務場景需求），這是身爲一個低代碼開發平臺所應該盡到的核心職責。

在盡到上述職責的同時，低代碼開發平臺做爲一個面向開發者的產品，還須要致力於爲開發者提供簡單直觀的極致開發體驗。這背後除了巨大的工做量，還得能在「強大」和「易用」這兩個很難一箭雙鵰的矛盾點之間，努力找到一個符合本身產品定位與目標客戶需求的平衡點 —— 這也許是設計一個通用低代碼開發平臺所面臨的最大挑戰。

3、低代碼相關概念對比

純代碼（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在其相關調研報告中，就是將「No Code」劃在了範圍更廣的低代碼應用平臺「LCAP」（Low-Code Application Platform）中。而當前市面上不少通用的低代碼開發平臺，也都兼具必定程度的零代碼能力；好比低代碼領域領頭羊Mendix，既提供了簡單易用的零代碼Web IDE - Mendix Studio，也包括一個功能更強大的低代碼桌面IDE - Mendix Studio Pro。

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同樣提供現成的軟件服務（更詳細的說明可參考配圖來源文章）。

4、爲何須要低代碼

低代碼是什麼可能並沒那麼重要，畢竟在這個信息爆炸的世界，永遠不缺乏新奇而又短命的事物。大部分所謂的新技術都只是曇花一現：出現了，被看到了；大部分人「哦」了一聲，已閱但表示不感興趣；小部分人驚歎於它的奇思妙想，激動地點了個贊後，回過頭來該用什麼仍是什麼。真正決定新技術是否能轉化爲新生產力的，永遠不是技術自己有多麼優秀和華麗，而是它是否真的被須要，即：爲何須要低代碼？若是用不一樣的主語填充上面這個問句（冷知識：這叫作「延遲主語初始化」），能夠更全面地看待這個問題：

爲何「市場」須要低代碼？

在這個大爺大媽都滿嘴「互聯網+」和「數字化轉型」的時代，企業愈來愈須要經過應用（App）來改善企業內部的信息流轉、強化與客戶之間的觸點鏈接。然而，誕生還不過久的IT信息時代，也正面臨着與我國社會主義初級階段相似的供需關係矛盾：落後的軟件開發生產力跟不上人民日益增加的業務需求。

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

提效降本 & 質量保障

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

相比而言，傳統制造業通過幾百年工業革命的發展，大部分早已擺脫了對「人」的強依賴：從原料輸入到製品輸出，中間是各類精密儀器和自動化流水線的穩定支撐，真正實現生產的標準化和規模化。雖然信息化號稱是人類的第三次工業革命，但以軟件行業目前的情況，遠遠還沒到達成熟的「工業化」階段。

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

是的，低代碼正在將應用軟件開發過程工業化：每一個低代碼開發平臺都是一個技術密集型的應用工廠，全部項目相關人員都在同一條產線內緊密協做。開發主力再也不是熟知for循環一百種寫法的技術Geek，而是一羣心懷想法業務sense十足的應用Maker。藉助應用工廠中各類成熟的基礎設施、現成的標準零件、自動化的裝配流水線，開發者只須要專一於最核心的業務價值便可。即使是碰到非標需求，也能夠隨時本身動手，用最靈活的手工定製（代碼）方式來解決各類邊角問題。

擴大應用開發勞動力

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

至此，應用開發能力再也不是少數專業開發者的專利和特權，且從此所須要的技能門檻與擁有成本也會愈來愈低，真正實現所謂的「技術民主化」（democratization of technology）。

增強開發過程的溝通協做

多方調查結果顯示，軟件項目失敗的最主要緣由之一就是缺少溝通（poor communication）。傳統開發模式下，業務、產品、設計、開發、測試與運維人員各司其職，且各有一套領域內的工具和語言，長久以來很容易造成一個個「豎井」（silos），讓跨職能的溝通變得困難而低效。這也是爲何當前熱門的敏捷開發和DevOps都在強調溝通（前者是協同Biz與Dev，然後者是協同Dev和Ops），而經典的DDD領域驅動設計也主張經過「統一語言」來減小業務與技術人員之間的溝通不一致。

有了低代碼後，這一情況將獲得根本改善：上述各角色均可以在同一個低代碼開發平臺上緊密協做（甚至能夠是同一我的），這種全新的協做模式不只打破了職能豎井，還能經過統一的可視化語言和單一的應用表示（頁面/數據/邏輯），輕鬆對齊項目各方對應用形態和項目進度的理解，實現更終極的敏捷開發模式，以及在傳統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集成能力），但放在當年的市場和業務背景下，加上前面所說的技術不成熟度，總體的投入產出比會很低，不足以讓企業大面積採納低代碼解決方案。

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

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

爲何「專業開發者」也須要低代碼？

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

屏幕前一批穿格子襯衫的同窗要發問了：「低代碼都不怎麼寫代碼了，怎麼能算是爲咱們程序員服務呢？」。雖然程序員討厭重複本身，但重要的事情仍是得多說一遍：開發 ≠ 寫代碼。1萬年前蹲在洞穴裏的原始人，在用小石子畫遠古圖騰；100年前坐在書桌前的徐志摩，在用鋼筆給林徽因寫情書；而今天趴在屏幕前的不少人，相信都已經開始用上手寫板或iPad塗塗寫寫了。千百年來，人類使用的工具一直在演進，但所從事活動的本質並無多大改變。不管是用小石子仍是小鼠標，寫做繪畫的本質都是創造與表達，最終做品的好壞並不取決於當時你手中拿着什麼；一樣地，應用開發的本質是想法和邏輯，最終價值的高低也不取決你實現時是用的純代碼仍是低代碼。

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

減小沒必要要的工做量

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

強大的平臺能力支撐

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

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

一體化生態能力複用

複用（Reuse）是提高軟件開發效率和工程質量的最有效途徑。傳統的代碼開發模式下，開發者能夠經過提取公共類/函數、引用共享庫、調用外部API服務、沉澱代碼片斷和模板等方式實現複用。在低代碼的世界裏，平臺也能夠提供對應的多層次多粒度複用手段，好比頁面組件庫、邏輯函數庫、應用模板庫等。

但更重要的是，低代碼平臺還能夠充分發揮其一體化的生態優點，提供強大易用的可複用能力（資產）的發現、集成與共享體系：以頁面組件爲例，你能夠直接用系統組件，也能夠在平臺自帶的組件市場上搜索和引用更合適的組件，還能夠本身用代碼開發一個自定義組件併發布到市場中。平臺的生態體系越大，積累的可複用能力就越多，應用的開發成本也會越低。

相比而言，雖然傳統代碼世界總體生態更龐大和深厚，但因爲各種技術不互通、缺少統一平臺與市場、代碼集成成本高等緣由，一直以來都沒有造成有相似規模潛力的生態能力複用體系，致使重複造輪子和低水平重複建設的現象司空見慣，還美名爲「新基建」。

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

固然，若是你堅持要用純粹的寫代碼方式來改變世界，也不至於失業。要麼，你能夠選擇那些低代碼暫時不太適用的領域，好比底層系統驅動、3D遊戲引擎、火箭發射程序；或者，你也能夠選擇去寫低代碼中那一部分不可或缺的自定義代碼擴展，爲平民開發者提供高質量的積木。最後，你也徹底能夠選擇爲低代碼平臺自己的底層代碼添磚加瓦，好比加入阿里云云原生應用研發平臺EMAS團隊 (〃'▽'〃) ，與做者一塊兒共建下一代雲原生低代碼開發平臺「Mobi」，內推直達郵箱：pengqun.pq@alibaba-inc.com。

爲何「我不」須要低代碼

即便全部人都認同上述「爲何要用低代碼」的理由，但仍不時會有試水者跳出來，給你們細數「爲何我不須要低代碼」。實踐出真知沒錯，並且大部分質疑背後也都有必定道理；但在我看來，更多的多是主觀或無心識的偏見。這裏我列了一些對低代碼的常見質疑和我我的的見解，指望能幫助你們看到一個更全面和客觀的低代碼。

質疑1：低代碼平臺很差使

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

做爲調研過國內外多款低代碼產品的深度體驗用戶，個人觀點是：不能以偏概全。低代碼市場在國內正處於爆發初期，因此許多與低代碼只沾一點邊的產品也都在蹭熱點；但它們並不能表明低代碼目前的業界水平和發展方向。市面上真正成熟的企業級低代碼開發平臺，徹底有能力以高效的開發方式知足大部分複雜場景的功能需求，以及企業級應用所須要的安全、性能、可伸縮等非功能需求，這一點在國外市場已獲得充分驗證（否則也不會這麼被寄予厚望）。

固然，國內市場尚處於魚龍混雜的混戰階段，遇到真龍的機率很低，但碰上金魚鯉魚甚至木頭假魚都在所不免。相信隨着時間推移，真正有實力和口碑的產品都能脫穎而出，爲你們展示低代碼該有的樣子。

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

「平臺上的各類可視化組件、邏輯動做和部署環境都是黑盒，若是內部出問題沒法排查和解決。」

做爲一樣不搞清楚底層原理不舒服斯基的程序員，我更願意相信：問題只是暫時的。雖然這確實是目前使用低代碼平臺時繞不開的一個痛點，但並不屬於低代碼技術自己的固有缺陷。計算機領域有一句至理名言：任何問題均可以經過增長一個間接的中間層來解決。低代碼的思路亦是如此：與當年的操做系統和如今的雲平臺同樣，都是想經過創建一個黑盒化的中間層抽象來下降開發者的工做量與心智負擔。

固然，全部額外增長的中間層都不是徹底免費的，低代碼也不例外。做爲一個還沒有成熟穩定的新的中間層，低代碼必然會出現各類讓使用者束手無措的問題，就跟當年的操做系統內核bug、現在的雲主機I/O hang同樣。但歷史規律也告訴咱們，全部偉大的技術最終都會走向成熟；只要低代碼領域一直健康發展，問題總會愈來愈少，最終降到一個絕大部分人感知不到的範圍內。過去縈繞在Windows用戶心中揮之不去的「藍屏」問題，對現在的新用戶來講早已不知爲什麼物；今天低代碼開發者所遇到的種種「藍瘦」問題，將來也終將成爲被遺忘的歷史（誰還沒段黑歷史呢）。

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

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

做爲對軟件可維護性深有感觸的無腦級佈道者（見《救火必備！問題排查與系統優化手冊》），我不得不說：用低代碼開發，也要講基本法。通常來講，不管是使用低代碼開發仍是純代碼開發，形成應用可維護性低的根本緣由每每不在於開發工具，而是開發者自身沒有去遵循一些軟件開發的普適原則，好比工程規範性、命名可讀性、DRY/KISS/SOLID原則等。

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

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

5、低代碼行業發展

迴應質疑的最好方式，就是作好你本身，用實際的表現說話。對於一個行業而言，判斷它當前的表現是否夠好，或者將來是否有潛力作到更好，能夠從如下這三個方面進行衡量：市場規模（蛋糕夠不夠大）、適用場景（是否可落地）、競品情況（有沒有被驗證過）。

市場規模

"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了；下篇再說。）

6、結語

本文總結了低代碼領域的基本概念、核心價值與行業現狀。雖然這些內容都比較基礎和偏理論，但我始終認爲，深入理解一個系統的前提，正是這些務虛的東西 —— 技術架構只會告訴你這個系統是怎麼實現的（How），沒法準確表述它到底能用來作什麼（What），以及爲何要作這樣一個東西（Why）；然後面這兩個問題的答案，纔是後續系統全部設計與演進的根因和驅動力。

雖然程序員真的不喜歡重複本身，但冗餘也是一種必要的容錯手段，好東西真的不容錯過：歡迎各位技術同路人加入阿里云云原生應用研發平臺EMAS團隊，，咱們專一於普遍的雲原生技術（Backend as a Service、Serverless、DevOps、低代碼平臺等），致力於爲企業、開發者提供一站式的應用研發管理服務，內推直達郵箱：pengqun.pq@alibaba-inc.com。