2B 領域下低代碼的探索之路

簡介：低代碼將成爲B端服務領域的基礎設施，必將顛覆傳統開發方式，將來可期。

做者：天晟

前言

你們好，我是釘釘宜搭前端一個小團隊的負責人天晟，在阿里作了五年的低代碼。今天的分享咱們不講技術細節，主要會分享下咱們這五年的探索過程和當前的市場分析，但願能給你們帶來一個對低代碼搭建不同視角的認識。

什麼是低代碼

提及低代碼（Low-Code）這個詞，是在 2014 年，Forrester Research 第一次正式使用低代碼來描述這個市場。國內也就是近幾年開始流行的，之前咱們這邊叫「可視化搭建」，可視化搭建講起來有個很大的缺點，就是很容易和數據可視化傻傻分不清楚。我還記得，2018 年的時候，當時作一個分享，主題是 「泛可視化搭建的解決方案」，我老闆的老闆說建議我把「泛可視化」改成「低代碼」，我當時回覆說不改，低代碼聽着有點 low，「泛可視化」高大上些。後來也不知道何時開始習慣了一口一個低代碼，並且衍生了 Node-Code/Pro-Code。如今回想起來，當時是本身 low。

看下業界領軍者對低代碼的定義：

outsystems: 「低代碼是一種軟件開發方法，能夠更快地交付應用程序，而且只需不多的手工編碼。低代碼平臺是一組工具，這些工具能夠經過 建模和 圖形界面來可視化應用程序開發。可使開發人員能夠跳過手工編碼，從而 加快了將應用程序投入生產的過程。」

mendix: 「低代碼開發是一種可視化應用開發方法。經過低代碼開發，不一樣經驗水平的開發人員可以經過圖形用戶界面，使用 拖放式組件和 模型驅動邏輯來建立 Web 和移動應用。低代碼開發平臺 減輕了非技術開發人員的壓力，幫其免去了代碼編寫工做，同時也 爲專業開發人員提供了支持，幫助他們提取應用開發過程當中的繁瑣底層架構與基礎設施任務。業務和 IT 部門的開發人員能夠在平臺中協同，建立、迭代和發佈應用，而所需時間只是傳統方法的一小部分。這種低代碼應用開發方法可針對不一樣用例開發各類類型的應用，包括將原有應用升級爲支持 IoT 的智能應用。」

能夠提煉出幾個詞：模型/建模、圖形界面、拖放組件、加快、減輕。連起來就是：經過模型/建模、圖形界面拖放組件能夠加快應用開發，減輕了非技術開發人員的壓力。其實從前端的角度看，低代碼的鼻祖應該是它：

從我目前階段的理解，低代碼是這個：

當前市場分析

市場規模

根據 Forrester 的報告，2019 年該領域的規模估計爲 38 億美圓，預計在 2021 年這一賽道的市場規模將增加到 152 億美圓，75％ 的應用程序將在低代碼平臺中開發。到 2022 年該市場規模將達到 212 億美圓。

根據 Gartner 預測，到 2021 年應用開發需求的市場增加，將至少超過企業 IT 交付能力的 5 倍。到 2024 年全球約有 65％ 的應用程序都將涉及低代碼開發（Forrester 、Gartner 全球最具影響力的獨立研究諮詢公司）。

一、領導者：行業領導者既要表現出超強的執行能力（好的產品與良好的銷售業績相匹配），又要表現出具備遠見（產品創新和相稱的營銷策略）的戰略計劃。LCAP 的領導者主要包括雲 SaaS 提供商（Microsoft、Salesforce、ServiceNow），專業的低代碼提供商（Mendix、OutSystems）以及混合 RPA 和低代碼應用程序供應商（Appian）。這些供應商具備強大產品能力、市場影響力以及用戶體驗。

二、挑戰者：在市場佔有率、產品能力方面與領導者的差距並非很大，將來有能力成爲該行業領導者。

三、特定領域者：不只能夠提供低代碼應用平臺技術，還混合了其餘技術，例如，RPA、業務流程挖掘、BPM 等技術。他們是 LCAP 行業的中流砥柱，擁有良好的發展空間。

四、遠見者：遠見者具備良好的合做生態以及市場發展策略，在產品創新方面也有很強的能力。可是在業務執行方面與領導者有着較大的差距。相信隨着時間的推移他們會更上一層樓。

市場分類

目前我看到的市場上主要有兩類：

一種是基於表單驅動，核心能力是表單、流程、報表，在必定的場景下，能夠快速的作業務交付，上手成本也比較低。好比：宜搭、簡道雲、明道雲、氚雲等。

另外一種是基於模型驅動，核心是領域模型、業務沉澱、完整性，有必定的技術壁壘，上手成本相對比較高。好比：Outsystems / Mendix / PowerApps / 奧哲雲樞 / 金蝶雲蒼穹等。

市場佈局

拿 PowerApps 來舉例，上面四個分別是 雲 + 端 + 協同 + 低代碼。已是很大、很先進的佈局了。從中咱們能看到低代碼平臺只是其中的一部分。獨木不成舟，獨木舟，雖然簡易也能用，但畢竟能力有限。

探索過程

用兩句話來歸納下：1. 始於表單終於表單；2.從技術到產品。

從 2015 年開始咱們一步一步探索，作了不少不少，不管是技術上仍是產品上。好比模型驅動、小程序搭建等。這裏面的每一塊均可以單出拿出來說好久。這裏我舉幾個例子簡單描述下。

釘釘審批-表單

釘釘審批，這個搭建當時只有 8 個組件，功能也很簡單，和如今相比也和易用。畢竟簡單，這個僅僅是咱們的開始，以後一發不可收拾。

中後臺頁面搭建

後來咱們開始作中後臺頁面搭建，但在開始推廣時，卻受到了很大的阻力。

咱們開始給前端用，技術同窗是來寫代碼的，就排斥這種高不成低不就的搭建平臺產品，並且功能又不全，你們意見很大。後來，咱們給服務端開發用，固然服務端也是排斥的，不僅排斥搭建，就像讓一個寫 Java 的人作前端的頁面就是排斥。

但沒辦法，前端資源就是不足，再加上從上層開始推，那一年，效果突出。有些服務端的同窗用的簡直飛起，他們作頁面特別快，沒有聯調成本，接口都是本身定義的，想怎麼搞就這麼高，並且代碼寫的很規整。

再後來，隨着咱們的功能逐漸的完善，好比多分支、回滾等功能，前端也開始漸漸接受了，平臺側有不少頁面都是用平臺本身搭建的。

服務化

當時咱們部門的業務，大部分中後臺系統服務端都能自交付。減小了不少前端資源。咱們本身用舒服了，因而開始想讓其餘團隊也能使用。但每一個業務場景都不同，默認的平臺沒法知足其餘部門的訴求。因此咱們開始作服務化。

服務化就是我可讓其餘團隊也快速擁有低代碼搭建的能力，而且能夠作定製，好比組件定製、設計器面板定製。這樣思路就打開了，不只能支持其餘團隊的中後臺場景，凡是和搭建相關的場景，均可以作。

好比上圖的例子，場景特別有趣，每次我都會拿出這張圖分享給你們：絕對佈局的畫布構建好後，服務端會本身作特殊解析，最終顯示在石墨屏上。相似這種例子有不少。包括後面要作的在線設計都是經過服務化來完成的。

代碼互轉/ WebIDE

隨着咱們的用戶量愈來愈多，複雜功能的實現和後續的可維護性受到了不少的挑戰。

典型的例子是：開始個人需求比較簡單，用搭建快速完成了，但後面的需求評估下來發現搭建知足不了。因而咱們開始作出碼，將搭建產物轉成代碼，繼續開發。

可是單純作出碼沒什麼挑戰，咱們也考慮了不一樣角色的開發。當年的 WebIDE 也很火，因而咱們經過 WebIDE 作了一套搭建和代碼互轉的功能。咱們創造了本身的 DSL，其實也參考了 Salesforce，有了本身的語言，不少事情都好作了，也可控。小程序也是這樣的。

後面的路怎麼走？

靈魂三問：1. 如何能把價值再作大？2. 低代碼 or 零代碼？3. 用戶是誰？

再問：可否商業化呢？要不要商業化呢？如何商業化？

看競品分析。

Salesforce / Power Platform / 金蝶雲蒼穹，他們的 PaaS 都是有明確支撐的業務領域，CRM / ERP。PaaS 是基於自身的 SaaS 長出來的。咱們要主打那塊業務？哪塊業務能找到市場？

若是單純的作 PaaS，感受最後作出的可能仍是工具。工具類的競品，像 Outsystems/ Mendix，他們提供是軟件工具、方法和架構，能夠快速建模、測試、部署、管理等，是一套完整應用開發的閉環（測試、部署、調試、穩定性等）。因此，單純作工具，最後被收購？像 Mendix。仍是支撐 SaaS 爲目標？咱們要打的 SaaS 行業蛋糕還有嗎？另外還要考慮多租、二開等，技術複雜度極高。

再看看國內，簡道雲，背後是帆軟-數據出身，氚雲-流程出身。兩個產品都偏零代碼，產品體驗作的都很不錯。猜想應該都是先有獨立的能力，後發展後低代碼平臺的。

結論呢？固然沒有。競品分析只能幫助咱們多瞭解，具體的方向還須要本身去探索和挖掘。

疫情帶來的變化

疫情讓我看到了：

• 疫情，業務變化之快。
• 企業創新，業務變化之快。
• 企業發展，核心是提效降本。

去年由於我留杭過年，因此參與到了疫情項目，用宜搭來作健康打卡，從大年三十一連續在家幹了兩週，7 * 24 小時待命。

健康打卡應該大部人都用過，看着簡單，其實背後有不少複雜，有針對員工的，有針對 HR 的，還有針對海外的。需求變化之快，今天加個高風險城市，明天加個海外地區，須要各類定製。一個前端，全鏈路完成，快速試錯、快速上線。若是沒有宜搭，真搞不定。後面我也去其餘相似的競品看過了，咱們這邊的定製場景還真都沒法完成。

此次項目讓我更深入的認識了宜搭產品的價值。

總結

2B領域下的低代碼適合用冰山理論來解釋。部分人認爲的，包括 5 年前的我也是這樣認爲的，拖拽設計器 == 低代碼。後來在深刻作了兩年後，發現有物料、多端、出碼、佈局、邏輯、國際化、監控、模板、協議、服務化、幫助體系這麼多功能要作。再日後作，要從 2B 的視角去看，就像以前微軟的那邊的局部，雲、協同、端。

後面還有不少的未知等着咱們。

再回到現實，總結五個點。

一、場景壁壘

我以爲咱們須要尋找更多的「場景壁壘」，好比，疫情下，快速交付的場景，爲何疫情下你們會選擇宜搭而不是選擇其餘開發模式，由於快且場景不是特別複雜，快須要找須要快的場景，這種場景其餘方式沒法完成，這就是壁壘。

二、完整性

用戶須要在這個一個平臺上能把全部研發相關的事情所有作完。完整性也包括了可維護性。可控的開發質量、維護性和升級成本；二次需求開發。

三、生態

產品完整性有了後，就能夠打造開發生態，經過更多的開發者生產更多的物料、服務。同時平臺能夠鏈接更多的物料、服務。

四、鏈接

這裏的鏈接有兩層含義，一個是產品以前的鏈接，一個是數據的鏈接。產品的鏈接能夠產生 1 + 1 > 2 的效果。目前的趨勢，是在改變傳統的 ERP/CRM 大而複雜的軟件系統。愈來愈多小而靈活的應用產生，並且隨着企業的創新需求變化愈來愈快，系統愈來愈多，但不能作成煙囪，數據的鏈接尤爲重要。

五、靈活性和易用性

靈活性和易用性的平衡若是作很差，平臺也很容易作差。我看過一個競品，真的作到了代碼徹底交互化，0 代碼，可是，前端的邏輯用交互編排的方式，其複雜度根本沒辦法二次維護。

講了這麼多，並無確切的回答以前本身提的問題，由於沒有徹底正確的答案，咱們仍然須要不斷的探索。低代碼將成爲B端服務領域的基礎設施，必將顛覆傳統開發方式，將來可期。歡迎來一塊兒探索低代碼將來的發展方向，感興趣的能夠加我微信：alex-mm-ts。

---

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。