4. 不只是少寫代碼

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

再往深一點兒看，低代碼不只是少寫代碼而已：代碼寫得少，bug 也就越少（正所謂“少做少錯”），因此開發(fā)環(huán)節(jié)的兩大支柱性工作“趕需求”和“修 bug”就都少了；要測的代碼少了，那么測試用例也可以少寫不少；除了開發(fā)階段以外，平臺還覆蓋了后續(xù)的應(yīng)用構(gòu)建、部署和管理，因此運(yùn)維操作也更少了（Low-Code → Low-Ops）。

然而，少并不是最終目的：如果單純只是想達(dá)到少的效果，砍需求減人力、降低質(zhì)量要求也是一樣的。低代碼背后的哲學(xué)，是少即是多（Less is More），或者更準(zhǔn)確說是多快好省（Do More with Less） —— 能力更多、上線更快、質(zhì)量更好，成本還更省，深刻踐行了阿里“既要，又要，還要”的價值觀精髓。

5. 平臺的職責(zé)與挑戰(zhàn)

上面說的是低代碼給開發(fā)者提供的能力與吸引力，那么作為服務(wù)的提供方與應(yīng)用的承載者，低代碼開發(fā)平臺自身應(yīng)該承擔(dān)怎樣的職責(zé)，其中又會遇到多大的挑戰(zhàn)？是否就一定要如阿里云所主張的那樣，“把復(fù)雜留給自己，把簡單留給別人”？雖然這句話聽起來很深明大義，但不知道大家有沒有想過，為什么我們一定要抱著復(fù)雜不放，平白無故給自己找事？就不能直接干掉復(fù)雜，也給咱阿里云自己的員工留點簡單嗎？是工作太容易就體現(xiàn)不出來 KPI 價值了，還是家里的飯菜不如公司的夜宵香？

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

根據(jù)《人月神話》作者 Fred Brooks 的劃分，軟件開發(fā)的復(fù)雜度可以劃分為本質(zhì)復(fù)雜度（Essential complexity ）和偶然復(fù)雜度（Accidental complexity）。前者是解決問題時固有的最小復(fù)雜度，跟你用什么樣的工具、經(jīng)驗是否豐富、架構(gòu)好不好等都無關(guān)，而后者就是除此之外在實際開發(fā)過程中引入的復(fù)雜度。通常來說，本質(zhì)復(fù)雜度與業(yè)務(wù)要解決的特定問題域強(qiáng)相關(guān)，因此這里我把它稱為更好理解的“業(yè)務(wù)復(fù)雜度”；這部分復(fù)雜度不是任何開發(fā)方法或工具能解決的，包括低代碼。而偶然復(fù)雜度一般與開發(fā)階段的技術(shù)細(xì)節(jié)強(qiáng)相關(guān)，因此我也相應(yīng)把它稱為“技術(shù)復(fù)雜度”；而這一部分復(fù)雜度，恰好就是低代碼所擅長且適合解決的。

為開發(fā)者盡可能屏蔽底層技術(shù)細(xì)節(jié)、減少不必要的技術(shù)復(fù)雜度，并支撐其更好地應(yīng)對業(yè)務(wù)復(fù)雜度（滿足靈活通用的業(yè)務(wù)場景需求），這是身為一個低代碼開發(fā)平臺所應(yīng)該盡到的核心職責(zé)。

在盡到上述職責(zé)的同時，低代碼開發(fā)平臺作為一個面向開發(fā)者的產(chǎn)品，還需要致力于為開發(fā)者提供簡單直觀的極致開發(fā)體驗。這背后除了巨大的工作量，還得能在“強(qiáng)大”和“易用”這兩個很難兩全其美的矛盾點之間，努力找到一個符合自己產(chǎn)品定位與目標(biāo)客戶需求的平衡點 —— 這也許是設(shè)計一個通用低代碼開發(fā)平臺所面臨的最大挑戰(zhàn)。

低代碼相關(guān)概念對比

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

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

當(dāng)然，更準(zhǔn)確的稱謂我認(rèn)為是“高代碼”（與低代碼恰好對應(yīng)，只是名字太難聽，被我嫌棄了…），因為即便是使用傳統(tǒng)的代碼 IDE，有些開發(fā)工作也支持（甚至更適合）以非代碼方式完成，比如：iOS 端開發(fā)時使用的 SwiftUI 界面設(shè)計器、服務(wù)端開發(fā)數(shù)據(jù)庫應(yīng)用時使用的 PowerDesigner 建模工具。不過這部分可視化工作在傳統(tǒng)開發(fā)模式下只是起輔助作用，最后通常也是生成開發(fā)者可直接修改的代碼；開發(fā)者仍然是以代碼為中心來開展主要工作。

低代碼與純代碼之間的關(guān)系，其實跟視頻和文章之間很像：

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

如果按上面這種類比關(guān)系推導(dǎo)，低代碼未來也會遵循與視頻類似的發(fā)展軌跡，超越純代碼成為主流開發(fā)模式。Gartner 的預(yù)測也表達(dá)了相同的觀點：到 2024 年，所有應(yīng)用程序開發(fā)活動當(dāng)中的 65% 將通過低代碼的方式完成，同時 75% 的大型企業(yè)將使用至少四種低代碼開發(fā)工具進(jìn)行應(yīng)用開發(fā)。

但同樣地，就像是視頻永遠(yuǎn)無法取代文章一樣，低代碼也永遠(yuǎn)無法徹底取代純代碼開發(fā)方式。未來低代碼和純代碼方式將以互補(bǔ)的形態(tài)長期共存，各自在其所適合的業(yè)務(wù)場景中發(fā)光發(fā)熱。在后面的“低代碼業(yè)務(wù)場景”章節(jié)，會詳細(xì)列出哪些場景在現(xiàn)階段更適合用低代碼模式開發(fā)。

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

從分類的完備性角度來看，有“純代碼”自然也應(yīng)該有完全相反的“零代碼”（也稱為“無代碼”）。零代碼就是完全不需要寫代碼的應(yīng)用開發(fā)平臺，但這并不代表零代碼就比低代碼更高級和先進(jìn)，它只是做了一個更極端的選擇而已：徹底擁抱簡單的圖形可視化，完全消滅復(fù)雜的文本代碼。選擇背后的原因是，零代碼開發(fā)平臺期望能盡可能降低應(yīng)用開發(fā)門檻，讓人人都能成為開發(fā)者（注意：開發(fā) ≠ 寫代碼），包括完全不懂代碼的業(yè)務(wù)分析師、用戶運(yùn)營，甚至是產(chǎn)品經(jīng)理（不懂裝懂可不算懂）。

即便是專業(yè)開發(fā)者，在技術(shù)分工越來越精細(xì)的趨勢下（前端/后端/算法/SRE/數(shù)據(jù)分析..），也很難招到一個能獨立開發(fā)和維護(hù)整套復(fù)雜應(yīng)用的全棧工程師。但零代碼可以改變這一切：無論是 Java 和 JavaScript 傻傻分不清楚的技術(shù)小白，還是精通深度學(xué)習(xí)但沒時間學(xué)習(xí) Web 開發(fā)的算法大牛，都可以通過零代碼實現(xiàn)自己的技術(shù)夢或全棧夢。“改變世界的 idea 已有，就差一個程序員了”，這句玩笑話或許真的可以成真；哦不，甚至都用不著程序員，有 idea 的人自己就能上。

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

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

雖然零代碼與狹義上的低代碼有著上述明顯差異，但從廣義上來說，零代碼可以當(dāng)作低代碼的一個子集。Gartner 在其相關(guān)調(diào)研報告中，就是將 “No Code” 劃在了范圍更廣的低代碼應(yīng)用平臺“LCAP”（Low-Code Application Platform）中。而當(dāng)前市面上很多通用的低代碼開發(fā)平臺，也都兼具一定程度的零代碼能力；比如低代碼領(lǐng)域領(lǐng)頭羊 Mendix，既提供了簡單易用的零代碼 Web IDE – Mendix Studio，也包括一個功能更強(qiáng)大的低代碼桌面 IDE – Mendix Studio Pro。

3. HpaPaaS（高生產(chǎn)力應(yīng)用 PaaS）

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

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

圖源：https://blog.kintone.com/business-with-heart/difference-SaaS-iaas-paas-apaas-hpapaas

值得補(bǔ)充的是，“HpaPaaS“ 這個詞也并非橫空出世，而是傳承自更早之前 Gartner 提出的 “aPaaS”，它倆之間的關(guān)系是：HpaPaaS 只是 aPaaS 的一個子類；除了 HpaPaaS 這種通過低代碼實現(xiàn)的高生產(chǎn)力應(yīng)用開發(fā)平臺以外，aPaaS 還包括面向純代碼的傳統(tǒng)應(yīng)用開發(fā)平臺（High-control aPaaS，即可控度更高的純代碼開發(fā)方式）。

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

為什么需要低代碼？

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

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

在這個大爺大媽都滿嘴“互聯(lián)網(wǎng) ”和“數(shù)字化轉(zhuǎn)型”的時代，企業(yè)越來越需要通過應(yīng)用（App）來改善企業(yè)內(nèi)部的信息流轉(zhuǎn)、強(qiáng)化與客戶之間的觸點連接。然而，誕生還不太久的 IT 信息時代，也正面臨著與我國社會主義初級階段類似的供需關(guān)系矛盾：落后的軟件開發(fā)生產(chǎn)力跟不上人民日益增長的業(yè)務(wù)需求。

Gartner 預(yù)測，到 2021 年應(yīng)用開發(fā)需求的市場增長將至少超過企業(yè) IT 交付能力的 5 倍。面對如此巨大的 IT 缺口，如果沒有一種革命性的“新生產(chǎn)力”體系，很難想象僅憑現(xiàn)有傳統(tǒng)技術(shù)體系的發(fā)展延續(xù)就能徹底解決問題。而低代碼技術(shù)正是帶著這樣的使命而降臨，期望通過以下幾個方面徹底革新應(yīng)用開發(fā)生產(chǎn)力，拯救差一點就要邁入水深火熱的 IT 世界：

1）提效降本 & 質(zhì)量保障

雖然軟件行業(yè)一直在高速發(fā)展，新的語言、框架和工具層出不窮，但作為從業(yè)者我們不得不承認(rèn)：軟件開發(fā)仍處于手工作坊階段，效率低、人力成本高、質(zhì)量不可控。項目延期交付已成為行業(yè)常態(tài)，而瓶頸幾乎總是開發(fā)人員（對機(jī)器能解決的問題都不是問題）；優(yōu)秀的開發(fā)人才永遠(yuǎn)是稀缺資源，還賊貴；軟件質(zhì)量缺陷始終無法收斂，線上故障頻發(fā)資損不斷。

相比而言，傳統(tǒng)制造業(yè)經(jīng)過幾百年工業(yè)革命的發(fā)展，大部分早已擺脫了對“人”的強(qiáng)依賴：從原料輸入到制品輸出，中間是各種精密儀器和自動化流水線的穩(wěn)定支撐，真正實現(xiàn)生產(chǎn)的標(biāo)準(zhǔn)化和規(guī)?；?。雖然信息化號稱是人類的第三次工業(yè)革命，但以軟件行業(yè)目前的狀況，遠(yuǎn)遠(yuǎn)還沒到達(dá)成熟的“工業(yè)化”階段。

所以，親愛的程序員朋友，當(dāng)你與前端聯(lián)調(diào)了一上午接口，又與產(chǎn)品撕逼了一下午需求，再與自己的 bug 抗?fàn)幜艘徽?，好不容易遁入夢鄉(xiāng)又被一連串報警短信吵醒時，是否有抬頭對著星空憧憬過：“I have a dream… that one day，軟件開發(fā)也能像工業(yè)制品一樣，批量流水化生產(chǎn)，穩(wěn)定高效沒煩惱。” 事到如今，不管你有沒有意識到，這個憧憬正在慢慢變成現(xiàn)實。

是的，低代碼正在將應(yīng)用軟件開發(fā)過程工業(yè)化：每個低代碼開發(fā)平臺都是一個技術(shù)密集型的應(yīng)用工廠，所有項目相關(guān)人員都在同一條產(chǎn)線內(nèi)緊密協(xié)作。開發(fā)主力不再是熟知 for 循環(huán)一百種寫法的技術(shù) Geek，而是一群心懷想法業(yè)務(wù) sense 十足的應(yīng)用 Maker。借助應(yīng)用工廠中各種成熟的基礎(chǔ)設(shè)施、現(xiàn)成的標(biāo)準(zhǔn)零件、自動化的裝配流水線，開發(fā)者只需要專注于最核心的業(yè)務(wù)價值即可。即便是碰到非標(biāo)需求，也可以隨時自己動手，用最靈活的手工定制（代碼）方式來解決各種邊角問題。

2）擴(kuò)大應(yīng)用開發(fā)勞動力

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

至此，應(yīng)用開發(fā)能力不再是少數(shù)專業(yè)開發(fā)者的專利和特權(quán)，且今后所需要的技能門檻與擁有成本也會越來越低，真正實現(xiàn)所謂的“技術(shù)民主化”（democratization of technology）。

3）加強(qiáng)開發(fā)過程的溝通協(xié)作

多方調(diào)查結(jié)果顯示，軟件項目失敗的最主要原因之一就是缺乏溝通（poor communication）。傳統(tǒng)開發(fā)模式下，業(yè)務(wù)、產(chǎn)品、設(shè)計、開發(fā)、測試與運(yùn)維人員各司其職，且各有一套領(lǐng)域內(nèi)的工具和語言，長久以來很容易形成一個個“豎井”（silos），讓跨職能的溝通變得困難而低效。這也是為什么當(dāng)前熱門的敏捷開發(fā)和 DevOps 都在強(qiáng)調(diào)溝通（前者是協(xié)同 Biz 與 Dev，而后者是協(xié)同 Dev 和 Ops），而經(jīng)典的 DDD 領(lǐng)域驅(qū)動設(shè)計也主張通過“統(tǒng)一語言”來減少業(yè)務(wù)與技術(shù)人員之間的溝通不一致。

有了低代碼后，這一狀況將得到根本改善：上述各角色都可以在同一個低代碼開發(fā)平臺上緊密協(xié)作（甚至可以是同一個人），這種全新的協(xié)作模式不僅打破了職能豎井，還能通過統(tǒng)一的可視化語言和單一的應(yīng)用表示（頁面/數(shù)據(jù)/邏輯），輕松對齊項目各方對應(yīng)用形態(tài)和項目進(jìn)度的理解，實現(xiàn)更終極的敏捷開發(fā)模式，以及在傳統(tǒng) DevOps 基礎(chǔ)之上更進(jìn)一步的 BizDevOps。

4）統(tǒng)一開發(fā)平臺下的聚合效應(yīng)

低代碼嘗試將所有與應(yīng)用開發(fā)相關(guān)活動都收斂到同一個平臺（one platform）上后，將會產(chǎn)生更多方面的聚合效應(yīng)與規(guī)模收益：

• 人員聚合：除了上一點所提到的各職能角色緊密協(xié)作以外，人員聚合到統(tǒng)一的低代碼開發(fā)平臺進(jìn)行作業(yè)后，還能促進(jìn)整個項目流程的標(biāo)準(zhǔn)化、規(guī)范化和統(tǒng)一化。
• 應(yīng)用聚合：一方面，新應(yīng)用的架構(gòu)設(shè)計、資產(chǎn)復(fù)用、相互調(diào)用變得更容易；另一方面，各應(yīng)用的數(shù)據(jù)都天然互通，同時平臺外數(shù)據(jù)也能通過集成能力進(jìn)行打通，徹底消除企業(yè)的數(shù)據(jù)孤島問題。
• 生態(tài)聚合：當(dāng)?shù)痛a開發(fā)平臺聚合了足夠多的開發(fā)者和應(yīng)用后，將形成一個巨大的、連接一切、有無限想象力的生態(tài)體系，徹底放飛低代碼的價值。

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

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

1）技術(shù)成熟度不足

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

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

2）業(yè)務(wù)收益不明顯

即使十幾年前的低代碼技術(shù)已經(jīng)足夠成熟，也一定不會在當(dāng)年的應(yīng)用開發(fā)市場上產(chǎn)生現(xiàn)在這樣的影響力。為什么？因為技術(shù)都是為業(yè)務(wù)服務(wù)的，而當(dāng)時的應(yīng)用開發(fā)業(yè)務(wù)需求可比現(xiàn)在簡單多了：沒有如今的多渠道（Multi-channel）、多樣化體驗（Multi-experience）和各種集成與定制需求，也不會奢求如今已成為企業(yè)級應(yīng)用標(biāo)配的彈性、分布式和高可用，更是缺乏快速變化的IT業(yè)務(wù)場景來推動持續(xù)集成與快速交付。

雖然低代碼可以完美解決上述所有問題（e.g. 多端應(yīng)用生成、云原生架構(gòu)、API 集成能力），但放在當(dāng)年的市場和業(yè)務(wù)背景下，加上前面所說的技術(shù)不成熟度，整體的投入產(chǎn)出比會很低，不足以讓企業(yè)大面積采納低代碼解決方案。

而如今這個時代，企業(yè)都快被新技術(shù)帶來的能力和收益“慣壞了”，動不動就是：我想做一個送菜應(yīng)用。用戶端？安卓、iOS、H5、小程序都來一套。運(yùn)營端？一般都在電腦上看，但記得手機(jī)上也得適配啊。服務(wù)端？上云，必須的。哦，我聽技術(shù)合伙人說現(xiàn)在流行多云架構(gòu)，也給我整一套哈。運(yùn)維還要錢？啥是運(yùn)維？應(yīng)用有了不就能用了嘛，運(yùn)維還要花我錢？你當(dāng)投資者給我的錢是大風(fēng)刮來的??！

如果用傳統(tǒng)的開發(fā)模式，這么全套下來的工時與報價，可能早就嚇跑了這群跟產(chǎn)品經(jīng)理一樣天真可愛的人；但現(xiàn)代化的低代碼技術(shù)，可以圓了上面這位創(chuàng)業(yè)者的賣菜夢，用白菜一般的價格，實現(xiàn)白粉一樣的價值。當(dāng)年的程維如果能用上現(xiàn)在的低代碼，第一版的滴滴 App 也就不至于被外包做得烏煙瘴氣直接報廢了（至少能多扛一陣子…）。

3. 為什么「專業(yè)開發(fā)者」也需要低代碼？

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

屏幕前一批穿格子襯衫的同學(xué)要發(fā)問了：“低代碼都不怎么寫代碼了，怎么能算是為我們程序員服務(wù)呢？”。雖然程序員討厭重復(fù)自己，但重要的事情還是得多說一遍：開發(fā) ≠ 寫代碼。1 萬年前蹲在洞穴里的原始人，在用小石子畫遠(yuǎn)古圖騰；100 年前坐在書桌前的徐志摩，在用鋼筆給林徽因?qū)懬闀?；而今天趴在屏幕前的很多人，相信都已?jīng)開始用上手寫板或 iPad 涂涂寫寫了。千百年來，人類使用的工具一直在演進(jìn)，但所從事活動的本質(zhì)并沒有多大改變。無論是用小石子還是小鼠標(biāo)，寫作繪畫的本質(zhì)都是創(chuàng)造與表達(dá)，最終作品的好壞并不取決于當(dāng)時你手中拿著什么；同樣地，應(yīng)用開發(fā)的本質(zhì)是想法和邏輯，最終價值的高低也不取決你實現(xiàn)時是用的純代碼還是低代碼。

而相比純代碼而言，低代碼極有可能成為更好的下一代生產(chǎn)力工具：

1）減少不必要的工作量

可視化拖拽與參數(shù)配置的極簡開發(fā)模式，結(jié)合模型驅(qū)動的代碼自動生成機(jī)制，可以消滅絕大部分繁瑣和重復(fù)的 boilerplate 代碼；一站式的部署和運(yùn)維管理平臺，無需自己搭建 CI/CD 流水線、申請環(huán)境資源、配置監(jiān)控報警；一次搭建同時生成、構(gòu)建和發(fā)布多端應(yīng)用，免去人工同步維護(hù)多個功能重復(fù)的端應(yīng)用；開箱即用的組件庫、模板庫、主題庫、連接器等，讓最大化軟件復(fù)用成為可能?？偠灾?，低代碼能夠讓專業(yè)開發(fā)者更專注于創(chuàng)新性、有價值、有區(qū)分度的工作，而不是把寶貴開發(fā)時間都耗費(fèi)在上面那些不必要的非業(yè)務(wù)核心工作上。

2）強(qiáng)大的平臺能力支撐

雖然上面列的技術(shù)支撐性工作并不直接產(chǎn)生業(yè)務(wù)價值，但卻會直接影響業(yè)務(wù)的性能、成本、穩(wěn)定性、安全性、可持續(xù)發(fā)展能力等。有遠(yuǎn)見的企業(yè)，絕不允許犧牲這些重要指標(biāo)，來換取短暫的業(yè)務(wù)加速。低代碼開發(fā)平臺深知這一點，因此在簡化和屏蔽底層技術(shù)細(xì)節(jié)的同時，也會盡可能把自己所 cover 的部分做到最好（至少能和純代碼開發(fā)方式一樣好），包括但不限于：

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

3）一體化生態(tài)能力復(fù)用

復(fù)用（Reuse）是提升軟件開發(fā)效率和工程質(zhì)量的最有效途徑。傳統(tǒng)的代碼開發(fā)模式下，開發(fā)者可以通過提取公共類/函數(shù)、引用共享庫、調(diào)用外部 API 服務(wù)、沉淀代碼片段和模板等方式實現(xiàn)復(fù)用。在低代碼的世界里，平臺也可以提供對應(yīng)的多層次多粒度復(fù)用手段，比如頁面組件庫、邏輯函數(shù)庫、應(yīng)用模板庫等。

但更重要的是，低代碼平臺還可以充分發(fā)揮其一體化的生態(tài)優(yōu)勢，提供強(qiáng)大易用的可復(fù)用能力（資產(chǎn)）的發(fā)現(xiàn)、集成與共享體系：以頁面組件為例，你可以直接用系統(tǒng)組件，也可以在平臺自帶的組件市場上搜索和引用更合適的組件，還可以自己用代碼開發(fā)一個自定義組件并發(fā)布到市場中。平臺的生態(tài)體系越大，積累的可復(fù)用能力就越多，應(yīng)用的開發(fā)成本也會越低。

相比而言，雖然傳統(tǒng)代碼世界整體生態(tài)更龐大和深厚，但由于各類技術(shù)不互通、缺乏統(tǒng)一平臺與市場、代碼集成成本高等原因，一直以來都沒有形成有類似規(guī)模潛力的生態(tài)能力復(fù)用體系，導(dǎo)致重復(fù)造輪子和低水平重復(fù)建設(shè)的現(xiàn)象司空見慣，還美名為“新基建”。

說到這里，另一批裹著沖鋒衣頭頂锃亮的同學(xué)也忍不住了：“萬一低代碼真的發(fā)展起來了，是不是就不需要那么多程序員了?。可嫌欣舷掠行〉?，同是碼農(nóng)身，相煎何太急！”。低代碼雖然是一場應(yīng)用開發(fā)生產(chǎn)力革命，但并不會革掉程序員的飯碗。它去掉的只是難懂的編程語法、繁瑣的技術(shù)細(xì)節(jié)和一切可自動化的重復(fù)性工作，并沒有也無法去掉應(yīng)用開發(fā)最核心的東西：嚴(yán)謹(jǐn)?shù)臉I(yè)務(wù)邏輯、巧妙的算法設(shè)計、良好的工程風(fēng)格等。對于真正的程序員，即使剝?nèi)ニ粚佑忠粚拥木幊陶Z言和工具熟練度技能外殼，最終剩下的仍然是一個有價值的硬核開發(fā)者。

當(dāng)然，如果你堅持要用純粹的寫代碼方式來改變世界，也不至于失業(yè)。要么，你可以選擇那些低代碼暫時不太適用的領(lǐng)域，比如底層系統(tǒng)驅(qū)動、3D 游戲引擎、火箭發(fā)射程序；或者，你也可以選擇去寫低代碼中那一部分不可或缺的自定義代碼擴(kuò)展，為平民開發(fā)者提供高質(zhì)量的積木。最后，你也完全可以選擇為低代碼平臺本身的底層代碼添磚加瓦，比如加入阿里云云原生應(yīng)用研發(fā)平臺 EMAS 團(tuán)隊 (〃'▽'〃) ，與作者一起共建下一代云原生低代碼開發(fā)平臺“Mobi”，內(nèi)推直達(dá)郵箱：pengqun.pq # alibaba-inc.com。

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

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

質(zhì)疑 1：低代碼平臺不好使

“試用過一些所謂的低代碼開發(fā)平臺，要么能力很弱，要么體驗太差，只能開發(fā)點玩具應(yīng)用?！?/span>

作為調(diào)研過國內(nèi)外多款低代碼產(chǎn)品的深度體驗用戶，我的觀點是：不能以偏概全。低代碼市場在國內(nèi)正處于爆發(fā)初期，所以許多與低代碼只沾一點邊的產(chǎn)品也都在蹭熱點；但它們并不能代表低代碼目前的業(yè)界水平和發(fā)展方向。市面上真正成熟的企業(yè)級低代碼開發(fā)平臺，完全有能力以高效的開發(fā)方式滿足大部分復(fù)雜場景的功能需求，以及企業(yè)級應(yīng)用所需要的安全、性能、可伸縮等非功能需求，這一點在國外市場已得到充分驗證（不然也不會這么被寄予厚望）。

當(dāng)然，國內(nèi)市場尚處于魚龍混雜的混戰(zhàn)階段，遇到真龍的概率很低，但碰上金魚鯉魚甚至木頭假魚都在所難免。相信隨著時間推移，真正有實力和口碑的產(chǎn)品都能脫穎而出，為大家展現(xiàn)低代碼該有的樣子。

質(zhì)疑 2：低代低開發(fā)不可控

“平臺上的各種可視化組件、邏輯動作和部署環(huán)境都是黑盒，如果內(nèi)部出問題無法排查和解決?！?/span>

作為同樣不搞清楚底層原理不舒服斯基的程序員，我更愿意相信：問題只是暫時的。雖然這確實是目前使用低代碼平臺時繞不開的一個痛點，但并不屬于低代碼技術(shù)本身的固有缺陷。計算機(jī)領(lǐng)域有一句至理名言：任何問題都可以通過增加一個間接的中間層來解決。低代碼的思路亦是如此：與當(dāng)年的操作系統(tǒng)和現(xiàn)在的云平臺一樣，都是想通過建立一個黑盒化的中間層抽象來降低開發(fā)者的工作量與心智負(fù)擔(dān)。

當(dāng)然，所有額外增加的中間層都不是完全免費(fèi)的，低代碼也不例外。作為一個尚未成熟穩(wěn)定的新的中間層，低代碼必然會出現(xiàn)各種讓使用者束手無措的問題，就跟當(dāng)年的操作系統(tǒng)內(nèi)核 bug、如今的云主機(jī) I/O hang 一樣。但歷史規(guī)律也告訴我們，所有偉大的技術(shù)最終都會走向成熟；只要低代碼領(lǐng)域一直健康發(fā)展，問題總會越來越少，最終降到一個絕大部分人感知不到的范圍內(nèi)。過去縈繞在 Windows 用戶心中揮之不去的“藍(lán)屏”問題，對如今的新用戶來說早已不知為何物；今天低代碼開發(fā)者所遇到的種種“藍(lán)瘦”問題，未來也終將成為被遺忘的歷史（誰還沒段黑歷史呢）。

質(zhì)疑 3：低代碼應(yīng)用難維護(hù)

“應(yīng)用一旦復(fù)雜起來，各種復(fù)雜邏輯流穿插著自定義代碼，看不懂也改不動，還不如全用代碼呢?！?/span>

作為對軟件可維護(hù)性深有感觸的無腦級布道者（見《救火必備！問題排查與系統(tǒng)優(yōu)化手冊》），我不得不說：用低代碼開發(fā)，也要講基本法。一般來說，無論是使用低代碼開發(fā)還是純代碼開發(fā)，造成應(yīng)用可維護(hù)性低的根本原因往往不在于開發(fā)工具，而是開發(fā)者自身沒有去遵循一些軟件開發(fā)的普適原則，比如工程規(guī)范性、命名可讀性、DRY/KISS/SOLID 原則等。

好的低代碼平臺絕不會阻礙開發(fā)者去改善應(yīng)用的可維護(hù)性；恰恰相反，還會盡可能提供引導(dǎo)和幫助。以 Mendix 為例，除了支持基本的模型分析與重構(gòu)（e.g. 無用模型、對象重命名、子邏輯流提取）以外，甚至還提供了基于 ISO/IEC 25010 標(biāo)準(zhǔn)的應(yīng)用質(zhì)量監(jiān)控（AQM）能力。另一方面，讓應(yīng)用變得難以維護(hù)的一個客觀原因也是應(yīng)用本身過于復(fù)雜，而低代碼作為高度抽象和自動化的開發(fā)模式，在降低應(yīng)用復(fù)雜度方面是專業(yè)的。

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

低代碼行業(yè)發(fā)展

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

1. 市場規(guī)模

"Talk is cheap，show me the code money." > —— Linus Starcraft

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

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

總結(jié)一下就是兩點：

• 低代碼的市場規(guī)模足夠大，且一直都在高速增長。
• 作為亞太地區(qū)的經(jīng)濟(jì)大國與IT強(qiáng)國，中國的低代碼市場將會引來一個爆發(fā)期，未來幾年內(nèi)的增速都會超過全球平均水平。

2. 適用場景

理論上來說，低代碼是完全對標(biāo)傳統(tǒng)純代碼的通用開發(fā)模式，應(yīng)該有能力支撐所有可能的業(yè)務(wù)場景。但理論也只是理論，低代碼一統(tǒng)江湖的夢想尚未照進(jìn)現(xiàn)實，也不可能完全取代現(xiàn)實。前文中提到過，低代碼與純代碼方式是互補(bǔ)關(guān)系，未來也將長期共存，各自在其所適合的業(yè)務(wù)場景中發(fā)光發(fā)熱。同時還需要指出的是，當(dāng)前階段的低代碼技術(shù)、產(chǎn)品和市場都尚未完全成熟，因此部分本來可能很適合用低代碼來開發(fā)的場景，目前也只能先用純代碼來替代。

Gartner 在 2019 年的低代碼調(diào)研報告中，曾經(jīng)繪制過一張用來闡述低代碼適用場景的“應(yīng)用金字塔”：

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

3. 競品概況

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

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

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

結(jié)語

本文總結(jié)了低代碼領(lǐng)域的基本概念、核心價值與行業(yè)現(xiàn)狀。雖然這些內(nèi)容都比較基礎(chǔ)和偏理論，但我始終認(rèn)為，深刻理解一個系統(tǒng)的前提，正是這些務(wù)虛的東西 —— 技術(shù)架構(gòu)只會告訴你這個系統(tǒng)是怎么實現(xiàn)的（How），無法準(zhǔn)確表述它到底能用來做什么（What），以及為什么要做這樣一個東西（Why）；而后面這兩個問題的答案，才是后續(xù)系統(tǒng)所有設(shè)計與演進(jìn)的根因和驅(qū)動力。

原文：https://developer.aliyun.com/article/779172?spm=5176.8068049.0.0.55746d19UcKI2P&groupCode=othertech