[[385227]]

引子

宜搭負(fù)責(zé)人驍勇給我舉過一個例子，我們小時候逢年過節(jié)穿的衣服，都是去裁縫店選一下材料、量一下尺寸，等個半個來月，討回來就可以穿了，衣服合身又喜歡。鏡頭切回今天，我們只需要在天貓、淘寶上看看圖片、選擇合適的尺寸就可以下單了，第二天就可以穿上，偶爾一絲不合身，偶爾大街上撞衫，但我們并不在意，因為我們享受到了更多的便利與高效。受益于這個產(chǎn)業(yè)制定了很多的標(biāo)準(zhǔn)化模型，比如身材模型：S、L、XL、XXL，我不再需要每次都去量身高尺寸，現(xiàn)在標(biāo)準(zhǔn)化生產(chǎn)出來的衣服可以滿足超過 90% 的需求，除明星或特殊場景之外也不會費心思去量身定制。

服裝、飲食、汽車乃至各行各業(yè)發(fā)展至今都已經(jīng)形成非常成熟、高效的產(chǎn)業(yè)鏈，軟件研發(fā)行業(yè)同樣如此，業(yè)務(wù)需求在增長且變化快，越是技術(shù)密集型的工種越容易帶來人力不足的瓶頸。這就越需要更多的標(biāo)準(zhǔn)和模型的制定，標(biāo)準(zhǔn)越趨于統(tǒng)一，就越高效，有時候 “放棄創(chuàng)造力才是最大的創(chuàng)造力”，本質(zhì)是追求普惠，可以預(yù)見，未來絕大多數(shù)場景將使用標(biāo)準(zhǔn)化模板通過無定制或低定制來完成業(yè)務(wù)需求。

期望的軟件研發(fā)姿勢

接下來就簡單談一談基于 no-code > low-code > pro-code 漸進(jìn)式思路的研發(fā)體系。

一 前置概念

在開篇之前先介紹幾個概念：

云計算主要分為三大類服務(wù)：軟件即服務(wù) (SaaS)、平臺即服務(wù) (PaaS) 和基礎(chǔ)架構(gòu)即服務(wù) (IaaS)。

• 軟件即服務(wù) (SaaS) 是一種通過互聯(lián)網(wǎng)交付應(yīng)用的模式。客戶能夠通過 Web 瀏覽器訪問 SaaS 應(yīng)用，這意味著，客戶無需購買、安裝、維護(hù)和更新硬件或軟件。SaaS 提供商負(fù)責(zé)確保一切順利進(jìn)行，而且客戶通常能夠使用最新版本的應(yīng)用。
• 平臺即服務(wù) (PaaS) 能夠提供云平臺和各種工具，幫助開發(fā)人員構(gòu)建和部署云應(yīng)用。用戶可以通過 Web 瀏覽器訪問 PaaS，所以企業(yè)無需購買和維護(hù)基礎(chǔ)硬件和軟件。借助 PaaS，開發(fā)人員還能采用租用的方式挑選所需的功能。
• 采用基礎(chǔ)架構(gòu)即服務(wù) (IaaS)，企業(yè)可以通過按使用付費的方式，“租用”服務(wù)器、網(wǎng)絡(luò)、存儲器和操作系統(tǒng)等計算資源。IaaS 提供商負(fù)責(zé)托管基礎(chǔ)架構(gòu)和處理系統(tǒng)維護(hù)及備份等任務(wù)，這樣，客戶就無需購買硬件或雇傭內(nèi)部專家對其進(jìn)行管理。

在 PaaS 層有專門用來支持應(yīng)用在云上開發(fā)、部署、運行的平臺，稱之為 aPaaS (Application platform as a service)，在 aPaaS 基礎(chǔ)上，提供 no-code & low-code 方式開發(fā)應(yīng)用的平臺稱之為 hpaPaaS (High-productivity aPaaS)，提供快速應(yīng)用研發(fā)能力，比如業(yè)務(wù)編排、邏輯編排、模型驅(qū)動、頁面編排等。

以上概念加入了一些我的個人理解，不同平臺可能有不同解釋，我們接下來對比一下業(yè)內(nèi)幾款明星平臺，看能給到我們什么參考?

二 業(yè)內(nèi)精品

• Microsoft PowerApps：微軟全家桶服務(wù)集成的非常好，比如 Excel，全站寫代碼的地方都統(tǒng)一為 Excel 相似的概念 Formula/Fx，另外 PowerBI/PowerFlow 十分強大，定位 hpaPaaS (low-code);
• Google AppMaker：谷歌產(chǎn)，谷歌全家桶服務(wù)集成的非常好，谷歌工程師文化在 SCRIPTS 體現(xiàn)得比較極致，無論是后端、前端都使用開發(fā)生態(tài)的 JS 語法，代碼提示十分友好，定位 hpaPaaS (low-code);
• Salesforce SaaS：平臺領(lǐng)頭羊，集 IaaS、PaaS、SaaS 與一體的云平臺，目前市值 1255 億美元;
• Sap：集 IaaS、PaaS、SaaS 與一體的云平臺，相比 salesforce，使用的技術(shù)要新一些，體驗上要好一些，目前市值 1577 億美元;
• OutSystems：提供桌面 IDE，最近提供的 OutSystems AI 能夠輔助模型設(shè)計，定位 hpaPaaS (low-code)，作為后起之秀，表現(xiàn)不俗，已獲得多輪融資，在 2018 年估值 10+ 億美元，儼然成為下一個獨角獸。

應(yīng)用研發(fā)能力對比如下：

幾點產(chǎn)品體驗感受：

• Google 和 Microsoft 老牌玩家玩 hpaPaaS 這一套相當(dāng)?shù)眯膽?yīng)手，體驗相當(dāng)講究，把自家的服務(wù)包括三方常用服務(wù)整合的非常好。
• OutSystems 類似微軟，提供多種流式編排，很多時候不需要寫代碼，同時也整合了非常多數(shù)據(jù)服務(wù)，比如 Swagger 的 OpenAPI。
• Salesforce 和 SAP 類似，從單一的應(yīng)用程序，到一套應(yīng)用程序，到一個快速應(yīng)用開發(fā)平臺，企業(yè)協(xié)作工具，再到一個應(yīng)用程序容器和數(shù)據(jù)庫提供，提供了一套完整的生態(tài)鏈，以 SaaS、PaaS、IaaS 的分層方式對外輸出。

幾點參考：

• 高效整合才能降低成本，這是所有玩家的心智，不容質(zhì)疑。
• 視角要放大，要能夠覆蓋 90% 場景，必須要構(gòu)建一套完整的生態(tài)鏈，從 no-code 到 low-code 再到 pro-code 都要有對應(yīng)的解決方案，且要做到互相之間能夠打通，這是 Salesforce 和 SAP 給到的經(jīng)驗，目前 AppMaker 和 PowerApps 主要針對表單、表格垂直領(lǐng)域，還不能夠玩大，單一領(lǐng)域視角解決的問題有限。
• 可視化的流式編排針對特定場景提效明顯，應(yīng)對稍微復(fù)雜一點的場景，一點也不好玩，比如 AppMaker 就粗暴一點，直接使用 SCRIPTS，書寫表達(dá)式更舒服，不知道使用 OutSystems 的用戶是什么感受。

三 走過的可視化建站

很長一段時間，國內(nèi)興起了很多可視化建站產(chǎn)品，「可視化建站」是「低代碼建站」的前身，目標(biāo)也是不用寫一行代碼，拖拖拽拽就可以把一個站點搭建起來，但更多的是從表現(xiàn)層(前端)單一領(lǐng)域去解決問題，只能完成靜態(tài)頁面的效果，對于真正的業(yè)務(wù)很難走完閉環(huán)。

總結(jié)一下突出的問題：

• 純前端思維，比如數(shù)據(jù)服務(wù)接入方式，缺少像 AppMaker/PowerApps 支持 DataConnectors 的統(tǒng)一數(shù)據(jù)接入層，和各個系統(tǒng)沒有形成有效整合。
• 能解決的場景也有限，高度復(fù)雜的企業(yè)級 CRM 系統(tǒng)，不是通篇一律的，業(yè)務(wù)邏輯高度復(fù)雜，面臨定制化考驗，稍微復(fù)雜一點的，需要做的工作可能會更多，甚至有時候搞不定，沒有享受到可視化搭建帶來的福報。
• 很多專業(yè)開發(fā)在搭建平臺施展不開才華，缺少專業(yè)級工具支持，比如 VSCode、Git。
• 不同角色之間不能有效的形成配合，比如后端數(shù)據(jù)接口，不能在可視化搭建工具中反射出來。
• 搭建頁面大多以 Schema 形式存儲，代碼也不好 diff，在運行時動態(tài)渲染也會帶來性能問題。

......

看到眾多業(yè)內(nèi)優(yōu)秀的設(shè)計，給我們帶來了很多奇思妙想，典型的 hpaPaaS 這種架構(gòu)一定程度上能將我們標(biāo)準(zhǔn)化場景完全解決掉，但標(biāo)準(zhǔn)化場景偏消費性質(zhì)，消費我們生產(chǎn)的物料沉淀、場景沉淀等，這樣的純 hpaPaaS 平臺應(yīng)對企業(yè)級場景肯定會透支，我們在為能活 102 年的超大型企業(yè)設(shè)計商業(yè)操作系統(tǒng)時，不能一律求快、求簡單，還需要考慮靈活性、擴(kuò)展性、復(fù)雜性，在這套系統(tǒng)上要能源源不斷的生產(chǎn)標(biāo)準(zhǔn)化的物料、場景，持續(xù)將復(fù)雜性問題抽象沉淀，形成一個有效的生態(tài)循環(huán)系統(tǒng)，我們需要的是一種加強版的 hpaPaaS 平臺 —— 企業(yè)級 hpaPaaS 平臺。

四 企業(yè)級的 hpaPaaS

以我們「企業(yè)智能事業(yè)部」為例做一下簡單的業(yè)務(wù)分型：

中后臺業(yè)務(wù)大多是和表單、表格相關(guān)的，這對 hpaPaaS 平臺來說是好事，但真正代表企業(yè)級場景特別是財務(wù)、法務(wù)等系統(tǒng)，涉及到的表單可以用魔鬼來形容，比如表單嵌套表格，表格再嵌套表格(存在必然有合理之處)，無法使用一套規(guī)則來描述，強大如 AppMaker 或 PowerApps，對這類問題基本無解，主要是沒有提供 backup 機(jī)制，企業(yè)級應(yīng)用最初始狀態(tài)大多是定制型應(yīng)用，如何進(jìn)化為標(biāo)準(zhǔn)化的配置型應(yīng)用，進(jìn)一步成為解決方案或商業(yè)能力，這是「企業(yè)級 hpaPaaS 平臺」需要重點解決的。

將較年輕的產(chǎn)品 AppMaker 和 PowerApps 定義為商業(yè)級解決方案，將較成熟的 SAP 和 Salesforce 定義為企業(yè)級解決方案，商業(yè)級能解決大多數(shù)通用問題，而企業(yè)級是要能解決更多復(fù)雜性問題，面對復(fù)雜性企業(yè)級問題時，我認(rèn)為最起碼要做到兩點：

• 將不同場景所需要的能力進(jìn)行分解、分層，最后通過能力的整合來應(yīng)對，提升靈活變通能力;
• 同時有通用方案和兜底方案，多種方案之間應(yīng)該遵循統(tǒng)一標(biāo)準(zhǔn)，是打通融合的。

如果非要用一句話概括企業(yè)級 hpaPaaS 能力，我認(rèn)為是從 no-code 到 pro-code 的漸進(jìn)式能力，如下圖：

實現(xiàn)這樣的「企業(yè)級的 hpaPaaS」有以下幾個重難點：

重難點一：從 no-code 到 pro-code

以一個簡單的業(yè)務(wù)系統(tǒng)為例來說一下這個過程。

迭代一(no-code 開發(fā))

最初比較簡單，符合標(biāo)準(zhǔn)化的 CRUD：

1. 進(jìn)行業(yè)務(wù)建模，配置業(yè)務(wù)規(guī)則;
2. 根據(jù)建立好的模型選擇標(biāo)準(zhǔn)化 CRUD 模板，直接產(chǎn)出;
3. 預(yù)覽、發(fā)布。

迭代二(low-code 開發(fā))

但是有些地方需要稍作定制，比如時間戳的格式化、頁面上需要額外展示用戶詳細(xì)信息：

將標(biāo)準(zhǔn)化生成的產(chǎn)物，以可視化編輯打開;

修改關(guān)聯(lián)字段時間的格式化方式、新增用戶信息塊;

保存、預(yù)覽、發(fā)布。

迭代三(pro-code 開發(fā))

隨著業(yè)務(wù)復(fù)雜度變高，很多業(yè)務(wù)邏輯需要寫更多代碼，也希望代碼被版本控制、進(jìn)行 diff 等：

• 將標(biāo)準(zhǔn)化生成的產(chǎn)物在 WebIDE 中打開;
• 編輯視圖，比如關(guān)聯(lián)的動作，定位到對應(yīng)動作代碼，修改邏輯;
• 使用 WebIDE 提供的 git 功能，進(jìn)行代碼對比及代碼提交;
• 保存、編譯、預(yù)覽、發(fā)布。

no-code 和 low-code 試錯成本低，在創(chuàng)業(yè)時期我更希望使用這兩種方式，隨著我的業(yè)務(wù)的成長，價值逐漸被認(rèn)可，對該產(chǎn)品的要求也變高，這時候我也愿意投入更多，這時候可以采用 pro-code 方式對我的項目進(jìn)行精裝修，這種漸進(jìn)式交付能力將越來越多的被推崇。

在這過程中，有一個關(guān)鍵點，no-code 到 low-code 再到 pro-code 始終遵循的是一個標(biāo)準(zhǔn)，在我需要時可以被任意方式打開。

雖然我們期望未來業(yè)務(wù)研發(fā)只有 10% 的工作需要 pro-code 來完成，但 pro-code 的相關(guān)技術(shù)體系也是不可或缺的，它就是一個全功能開放的底層架構(gòu)，no-code 和 low-code 在這之上做的更垂直化，所以并不是說 10% 就不需要了，尤其在做企業(yè)級研發(fā)，pro-code 的存在更是一顆定心丸。

對于 pro-code 核心關(guān)鍵點有：

• WebIDE：pro-code 環(huán)節(jié)設(shè)計上是可以使用桌面 IDE 的方式，但未來必定屬于云開發(fā)時代，桌面 IDE 天然的和 PaaS 平臺有割裂感，過去我們擔(dān)心 WebIDE 技術(shù)不成熟，今天 vscode 引領(lǐng)了新一代的編輯器變革，帶來諸如 coder、theia 等功能和性能都很完備的 WebIDE 技術(shù)儲備，技術(shù)上沒什么好擔(dān)心的;
• Git 打通：企業(yè)級產(chǎn)品，沒有那么隨意，一般需要強管控，其中版本控制尤為重要，不管是 pro-code 還是 no-code，最終形態(tài)都是一種代碼形式的標(biāo)準(zhǔn)產(chǎn)物，都應(yīng)該托管在 Git 倉庫上，在必要的時候可以進(jìn)行回溯和對比;
• 可視化編輯打通：可視化編輯是 low-code 和 no-code 的代表功能，通過 Recore (統(tǒng)一 DSL)的技術(shù)將可視化和 pro-code 打通，是 pro-code、low-code、no-code 三者之間形成互通的必要條件。

重難點二：服務(wù)的集成

在上面提到的產(chǎn)品中，都有這樣的一個設(shè)計，無論是自家的服務(wù)還是別人家的服務(wù)通過一個集成平臺，將他們有機(jī)的整合在一起，在任何需要的環(huán)節(jié)，都能被高效的使用。

圖片源自：https://developers.google.com/

我們也提出 OneService 概念，期望將與數(shù)據(jù)相關(guān)的接口或服務(wù)通過 OneService 集成起來，打通生產(chǎn)中的各個環(huán)節(jié)，如下圖：

重難點三：生命力

我們設(shè)計的系統(tǒng)，比較關(guān)心兩個問題：

1. 能創(chuàng)造多少價值?
2. 能活多久?

我認(rèn)為一個具有頑強生命力的系統(tǒng)，應(yīng)當(dāng)在時間維度上持續(xù)創(chuàng)造價值，有以下幾個關(guān)鍵點：

• 適合的土壤，大風(fēng)向以及政策鼓勵，有強烈市場需求;
• 持續(xù)標(biāo)準(zhǔn)化，標(biāo)準(zhǔn)化不是一個固定結(jié)果，而是一個動態(tài)過程，需要有一個進(jìn)化機(jī)制，保證標(biāo)準(zhǔn)化的生態(tài)具有自潔能力，適應(yīng)行業(yè)發(fā)展;
• 行業(yè)滲透，打通行業(yè)鏈路上下游，將標(biāo)準(zhǔn)、理念融入到行業(yè)各節(jié)點，能夠反哺自己的生態(tài)，并有助于形成規(guī)模;
• 共同成長，帶動行業(yè)成長，行業(yè)的成長就是自己的成長。

五 未來可期

SaaS 化的平臺，以 SAP 和 Salesforce 為代表在歐美國家活的很滋潤，在中國剛起步，從過去一年的變化可以看到，國家越來越多的政策在鼓勵中小型創(chuàng)新企業(yè)，意味著未來 toB 市場前景廣闊，阿里整體風(fēng)向現(xiàn)在也是 toB，釘釘和阿里云已經(jīng)在這條路上越走越穩(wěn)，讓我們看到，在 toB 這件事情上時機(jī)已經(jīng)成熟，而我們現(xiàn)在要做的就是把本土化的 SaaS 平臺做好、做強。

相關(guān)參考與鏈接

https://www.sap.cn/products/business-technology-platform.html