4. 不只是少寫代碼

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

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

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

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

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

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

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

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

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

低代碼相關概念對比

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

按照 Gartner 的定義，HpaPaaS 是一種支持聲明式、模型驅動設計和一鍵部署的平臺，提供了云上的快速應用開發(fā)（RAD）、部署和運行特性；這顯然與低代碼的定義如出一轍。但事實證明，名字起得太專業(yè)并不見得是好事，“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 這種通過低代碼實現(xiàn)的高生產力應用開發(fā)平臺以外，aPaaS 還包括面向純代碼的傳統(tǒng)應用開發(fā)平臺（High-control aPaaS，即可控度更高的純代碼開發(fā)方式）。

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

為什么需要低代碼？

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

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

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

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

1）提效降本 & 質量保障

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

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

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

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

2）擴大應用開發(fā)勞動力

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

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

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

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

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

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

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

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

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

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

1）技術成熟度不足

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

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

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

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

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

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

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

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

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

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

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

1）減少不必要的工作量

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

2）強大的平臺能力支撐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 市場規(guī)模

"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 年的分析報告中預測，全球的低代碼開發(fā)平臺市場中，亞太地區(qū)將在今后五年（2019-2024 年）中保持最高的增長速度。

總結一下就是兩點：

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

2. 適用場景

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

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

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

3. 競品概況

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

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

• OutSystems 和 Mendix 一馬當先，是公認的低代碼領域頭牌。這兩家都是很純粹的通用低代碼開發(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è)領先者地位。但這兩家的公司性質和發(fā)展路徑都很不一樣：Salesforce 是以 SaaS 起家，公司規(guī)模就不用多說了，反正就是 SaaS 屆的巨無霸。這類 SaaS 廠商做低代碼的動力，是為了解決客戶對成品 SaaS 軟件的定制訴求。M$ 更不用多介紹，只說下他們做低代碼的天然優(yōu)勢：一方面，作為辦公軟件航空母艦，低代碼可以幫助他們的客戶實現(xiàn)從 Excel 表單到定制 App 的能力與體驗升級；另一方面，作為云計算三巨頭之一，低代碼可以幫助他們連接內部的云計算生態(tài)體系，為開發(fā)者提供一個統(tǒng)一和易用的上云界面。
• 國外市場已經(jīng)得到充分驗證，但國內市場還剛剛興起，還沒有一家能夠贏得上述調研機構的芳心，擠進上面這兩張方圖。國內目前的一些競品和融資情況包括：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 的辛勤整理；為此我決定這篇文章剩下內容再也不黑 PD 了；下篇再說。）

結語

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

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