引子
宜搭負責人驍勇給我舉過一個例子，我們小時候逢年過節穿的衣服，都是去裁縫店選一下材料、量一下尺寸，等個半個來月，討回來就可以穿了，衣服合身又喜歡。鏡頭切回今天，我們只需要在天貓、淘寶上看看圖片、選擇合適的尺寸就可以下單了，第二天就可以穿上，偶爾一絲不合身，偶爾大街上撞衫，但我們並不在意，因為我們享受到了更多的便利與高效。受益於這個產業制定了很多的標準化模型，比如身材模型：S、L、XL、XXL，我不再需要每次都去量身高尺寸，現在標準化生產出來的衣服可以滿足超過 90% 的需求，除明星或特殊場景之外也不會費心思去量身定製。
服裝、飲食、汽車乃至各行各業發展至今都已經形成非常成熟、高效的產業鏈，軟件研發行業同樣如此，業務需求在增長且變化快，越是技術密集型的工種越容易帶來人力不足的瓶頸。這就越需要更多的標準和模型的制定，標準越趨於統一，就越高效，有時候 “放棄創造力才是最大的創造力”，本質是追求普惠，可以預見，未來絕大多數場景將使用標準化模板通過無定製或低定製來完成業務需求。
期望的軟件研發姿勢
接下來就簡單談一談基於 no-code > low-code > pro-code 漸進式思路的研發體系。
一 前置概念
在開篇之前先介紹幾個概念：
雲計算主要分為三大類服務：軟件即服務 (SaaS)、平臺即服務 (PaaS) 和基礎架構即服務 (IaaS)。
- 軟件即服務 (SaaS) 是一種通過互聯網交付應用的模式。客戶能夠通過 Web 瀏覽器訪問 SaaS 應用，這意味著，客戶無需購買、安裝、維護和更新硬件或軟件。SaaS 提供商負責確保一切順利進行，而且客戶通常能夠使用最新版本的應用。
- 平臺即服務 (PaaS) 能夠提供雲平臺和各種工具，幫助開發人員構建和部署雲應用。用戶可以通過 Web 瀏覽器訪問 PaaS，所以企業無需購買和維護基礎硬件和軟件。藉助 PaaS，開發人員還能採用租用的方式挑選所需的功能。
- 採用基礎架構即服務 (IaaS)，企業可以通過按使用付費的方式，“租用”服務器、網絡、存儲器和操作系統等計算資源。IaaS 提供商負責託管基礎架構和處理系統維護及備份等任務，這樣，客戶就無需購買硬件或僱傭內部專家對其進行管理。
在 PaaS 層有專門用來支持應用在雲上開發、部署、運行的平臺，稱之為 aPaaS (Application platform as a service)，在 aPaaS 基礎上，提供 no-code & low-code 方式開發應用的平臺稱之為 hpaPaaS (High-productivity aPaaS)，提供快速應用研發能力，比如業務編排、邏輯編排、模型驅動、頁面編排等。
以上概念加入了一些我的個人理解，不同平臺可能有不同解釋，我們接下來對比一下業內幾款明星平臺，看能給到我們什麼參考？
二 業內精品
- Microsoft PowerApps：微軟全家桶服務集成的非常好，比如 Excel，全站寫代碼的地方都統一為 Excel 相似的概念 Formula/Fx，另外 PowerBI/PowerFlow 十分強大，定位 hpaPaaS (low-code)；
- Google AppMaker：谷歌產，谷歌全家桶服務集成的非常好，谷歌工程師文化在 SCRIPTS 體現得比較極致，無論是後端、前端都使用開發生態的 JS 語法，代碼提示十分友好，定位 hpaPaaS (low-code);
- Salesforce SaaS：平臺領頭羊，集 IaaS、PaaS、SaaS 與一體的雲平臺，目前市值 1255 億美元;
- Sap：集 IaaS、PaaS、SaaS 與一體的雲平臺，相比 salesforce，使用的技術要新一些，體驗上要好一些，目前市值 1577 億美元；
- OutSystems：提供桌面 IDE，最近提供的 OutSystems AI 能夠輔助模型設計，定位 hpaPaaS (low-code)，作為後起之秀，表現不俗，已獲得多輪融資，在 2018 年估值 10+ 億美元，儼然成為下一個獨角獸。
應用研發能力對比如下：
幾點產品體驗感受：
- Google 和 Microsoft 老牌玩家玩 hpaPaaS 這一套相當得心應手，體驗相當講究，把自家的服務包括三方常用服務整合的非常好。
- OutSystems 類似微軟，提供多種流式編排，很多時候不需要寫代碼，同時也整合了非常多數據服務，比如 Swagger 的 OpenAPI。
- Salesforce 和 SAP 類似，從單一的應用程序，到一套應用程序，到一個快速應用開發平臺，企業協作工具，再到一個應用程序容器和數據庫提供，提供了一套完整的生態鏈，以 SaaS、PaaS、IaaS 的分層方式對外輸出。
幾點參考：
- 高效整合才能降低成本，這是所有玩家的心智，不容質疑。
- 視角要放大，要能夠覆蓋 90% 場景，必須要構建一套完整的生態鏈，從 no-code 到 low-code 再到 pro-code 都要有對應的解決方案，且要做到互相之間能夠打通，這是 Salesforce 和 SAP 給到的經驗，目前 AppMaker 和 PowerApps 主要針對表單、表格垂直領域，還不能夠玩大，單一領域視角解決的問題有限。
- 可視化的流式編排針對特定場景提效明顯，應對稍微複雜一點的場景，一點也不好玩，比如 AppMaker 就粗暴一點，直接使用 SCRIPTS，書寫表達式更舒服，不知道使用 OutSystems 的用戶是什麼感受。
三 走過的可視化建站
很長一段時間，國內興起了很多可視化建站產品，「可視化建站」是「低代碼建站」的前身，目標也是不用寫一行代碼，拖拖拽拽就可以把一個站點搭建起來，但更多的是從表現層（前端）單一領域去解決問題，只能完成靜態頁面的效果，對於真正的業務很難走完閉環。
總結一下突出的問題：
- 純前端思維，比如數據服務接入方式，缺少像 AppMaker/PowerApps 支持 DataConnectors 的統一數據接入層，和各個系統沒有形成有效整合。
- 能解決的場景也有限，高度複雜的企業級 CRM 系統，不是通篇一律的，業務邏輯高度複雜，面臨定製化考驗，稍微複雜一點的，需要做的工作可能會更多，甚至有時候搞不定，沒有享受到可視化搭建帶來的福報。
- 很多專業開發在搭建平臺施展不開才華，缺少專業級工具支持，比如 VSCode、Git。
- 不同角色之間不能有效的形成配合，比如後端數據接口，不能在可視化搭建工具中反射出來。
- 搭建頁面大多以 Schema 形式存儲，代碼也不好 diff，在運行時動態渲染也會帶來性能問題。
- ......
看到眾多業內優秀的設計，給我們帶來了很多奇思妙想，典型的 hpaPaaS 這種架構一定程度上能將我們標準化場景完全解決掉，但標準化場景偏消費性質，消費我們生產的物料沉澱、場景沉澱等，這樣的純 hpaPaaS 平臺應對企業級場景肯定會透支，我們在為能活 102 年的超大型企業設計商業操作系統時，不能一律求快、求簡單，還需要考慮靈活性、擴展性、複雜性，在這套系統上要能源源不斷的生產標準化的物料、場景，持續將複雜性問題抽象沉澱，形成一個有效的生態循環系統，我們需要的是一種加強版的 hpaPaaS 平臺 —— 企業級 hpaPaaS 平臺。
四 企業級的 hpaPaaS
以我們「企業智能事業部」為例做一下簡單的業務分型：
中後臺業務大多是和表單、表格相關的，這對 hpaPaaS 平臺來說是好事，但真正代表企業級場景特別是財務、法務等系統，涉及到的表單可以用魔鬼來形容，比如表單嵌套表格，表格再嵌套表格（存在必然有合理之處），無法使用一套規則來描述，強大如 AppMaker 或 PowerApps，對這類問題基本無解，主要是沒有提供 backup 機制，企業級應用最初始狀態大多是定製型應用，如何進化為標準化的配置型應用，進一步成為解決方案或商業能力，這是「企業級 hpaPaaS 平臺」需要重點解決的。
將較年輕的產品 AppMaker 和 PowerApps 定義為商業級解決方案，將較成熟的 SAP 和 Salesforce 定義為企業級解決方案，商業級能解決大多數通用問題，而企業級是要能解決更多複雜性問題，面對複雜性企業級問題時，我認為最起碼要做到兩點：
- 將不同場景所需要的能力進行分解、分層，最後通過能力的整合來應對，提升靈活變通能力；
- 同時有通用方案和兜底方案，多種方案之間應該遵循統一標準，是打通融合的。
如果非要用一句話概括企業級 hpaPaaS 能力，我認為是從 no-code 到 pro-code 的漸進式能力，如下圖：
實現這樣的「企業級的 hpaPaaS」有以下幾個重難點：
重難點一：從 no-code 到 pro-code
以一個簡單的業務系統為例來說一下這個過程。
迭代一（no-code 開發）
最初比較簡單，符合標準化的 CRUD：
- 進行業務建模，配置業務規則；
- 根據建立好的模型選擇標準化 CRUD 模板，直接產出；
- 預覽、發佈。
迭代二（low-code 開發）
但是有些地方需要稍作定製，比如時間戳的格式化、頁面上需要額外展示用戶詳細信息：
- 將標準化生成的產物，以可視化編輯打開；
- 修改關聯字段時間的格式化方式、新增用戶信息塊；
- 保存、預覽、發佈。
迭代三（pro-code 開發）
隨著業務複雜度變高，很多業務邏輯需要寫更多代碼，也希望代碼被版本控制、進行 diff 等：
- 將標準化生成的產物在 WebIDE 中打開；
- 編輯視圖，比如關聯的動作，定位到對應動作代碼，修改邏輯；
- 使用 WebIDE 提供的 git 功能，進行代碼對比及代碼提交；
- 保存、編譯、預覽、發佈。
no-code 和 low-code 試錯成本低，在創業時期我更希望使用這兩種方式，隨著我的業務的成長，價值逐漸被認可，對該產品的要求也變高，這時候我也願意投入更多，這時候可以採用 pro-code 方式對我的項目進行精裝修，這種漸進式交付能力將越來越多的被推崇。
在這過程中，有一個關鍵點，no-code 到 low-code 再到 pro-code 始終遵循的是一個標準，在我需要時可以被任意方式打開。
雖然我們期望未來業務研發只有 10% 的工作需要 pro-code 來完成，但 pro-code 的相關技術體系也是不可或缺的，它就是一個全功能開放的底層架構，no-code 和 low-code 在這之上做的更垂直化，所以並不是說 10% 就不需要了，尤其在做企業級研發，pro-code 的存在更是一顆定心丸。
對於 pro-code 核心關鍵點有：
- WebIDE：pro-code 環節設計上是可以使用桌面 IDE 的方式，但未來必定屬於雲開發時代，桌面 IDE 天然的和 PaaS 平臺有割裂感，過去我們擔心 WebIDE 技術不成熟，今天 vscode 引領了新一代的編輯器變革，帶來諸如 coder、theia 等功能和性能都很完備的 WebIDE 技術儲備，技術上沒什麼好擔心的；
- Git 打通：企業級產品，沒有那麼隨意，一般需要強管控，其中版本控制尤為重要，不管是 pro-code 還是 no-code，最終形態都是一種代碼形式的標準產物，都應該託管在 Git 倉庫上，在必要的時候可以進行回溯和對比；
- 可視化編輯打通：可視化編輯是 low-code 和 no-code 的代表功能，通過 Recore （統一 DSL）的技術將可視化和 pro-code 打通，是 pro-code、low-code、no-code 三者之間形成互通的必要條件。
重難點二：服務的集成
在上面提到的產品中，都有這樣的一個設計，無論是自家的服務還是別人家的服務通過一個集成平臺，將他們有機的整合在一起，在任何需要的環節，都能被高效的使用。
圖片源自：https://developers.google.com/
我們也提出 OneService 概念，期望將與數據相關的接口或服務通過 OneService 集成起來，打通生產中的各個環節，如下圖：
重難點三：生命力
我們設計的系統，比較關心兩個問題：
- 能創造多少價值？
- 能活多久？
我認為一個具有頑強生命力的系統，應當在時間維度上持續創造價值，有以下幾個關鍵點：
- 適合的土壤，大風向以及政策鼓勵，有強烈市場需求；
- 持續標準化，標準化不是一個固定結果，而是一個動態過程，需要有一個進化機制，保證標準化的生態具有自潔能力，適應行業發展；
- 行業滲透，打通行業鏈路上下游，將標準、理念融入到行業各節點，能夠反哺自己的生態，並有助於形成規模；
- 共同成長，帶動行業成長，行業的成長就是自己的成長。
五 未來可期
SaaS 化的平臺，以 SAP 和 Salesforce 為代表在歐美國家活的很滋潤，在中國剛起步，從過去一年的變化可以看到，國家越來越多的政策在鼓勵中小型創新企業，意味著未來 toB 市場前景廣闊，阿里整體風向現在也是 toB，釘釘和阿里雲已經在這條路上越走越穩，讓我們看到，在 toB 這件事情上時機已經成熟，而我們現在要做的就是把本土化的 SaaS 平臺做好、做強。
相關參考與鏈接
https://www.sap.cn/products/business-technology-platform.html