今天再談下對(duì)低代碼開發(fā)平臺(tái)的一些思考。

在前些日子，ThoughtWorks 中國(guó)區(qū) CTO 徐昊在接受采訪的時(shí)候談到，低代碼不是一個(gè)新概念，現(xiàn)在也不是低代碼第一次引發(fā)業(yè)界討論，以降低程序員門檻為目的的低代碼從底層邏輯上就是不通的，這類低代碼不是風(fēng)口，而是行業(yè)毒瘤。

這個(gè)在當(dāng)時(shí)引起了廣泛的討論和爭(zhēng)議，當(dāng)然反擊聲音最大的肯定是各種低代碼開發(fā)廠商，這本身也可能極大的影響到這些廠商本身的商業(yè)利益和發(fā)展融資。

實(shí)際上對(duì)于徐昊整個(gè)采訪一直在強(qiáng)調(diào)，以降低程序員門檻為目的的低代碼是最沒(méi)用的。從某種程度上來(lái)講，這類低代碼產(chǎn)品最終會(huì)演變成程序員的工作，甚至引發(fā)新一類程序員的出現(xiàn)，而它本身則從低代碼退化成為真正的代碼。

在10多年前我們就做過(guò)類似的快速開發(fā)平臺(tái)，里面有完整的界面建模，對(duì)象建模，流程建模，規(guī)則建模，組織權(quán)限建模等能力。但是應(yīng)用到后期發(fā)現(xiàn)的一個(gè)關(guān)鍵問(wèn)題就是對(duì)于規(guī)則引擎部分，通過(guò)腳本代碼實(shí)現(xiàn)的規(guī)則越來(lái)越復(fù)雜和龐大，而且極難維護(hù)。也就是說(shuō)很很多業(yè)務(wù)需求或復(fù)雜規(guī)則的實(shí)現(xiàn)很難抽象出統(tǒng)一標(biāo)準(zhǔn)規(guī)則或模型，你必須用腳本代碼去實(shí)現(xiàn)，但是對(duì)于復(fù)雜規(guī)則腳本卻變得越來(lái)越龐大。

在《人月神話》這本書里面提出一個(gè)重要的觀點(diǎn)就是沒(méi)有銀彈，只有焦油坑。當(dāng)時(shí)提出這個(gè)觀點(diǎn)的背景仍然是大型工程類復(fù)雜軟件系統(tǒng)的開發(fā)和實(shí)現(xiàn)。對(duì)于這類系統(tǒng)可以看到的重點(diǎn)已經(jīng)不是后續(xù)的編碼工作，而是整個(gè)系統(tǒng)分析和設(shè)計(jì)過(guò)程。

在我前面一篇對(duì)沒(méi)有銀彈的論述文章里面也談到，整個(gè)從需求到軟件開發(fā)實(shí)現(xiàn)的過(guò)程實(shí)際上可以分為幾個(gè)關(guān)鍵環(huán)節(jié)，即：現(xiàn)實(shí)世界-》業(yè)務(wù)建模-》系統(tǒng)建模-》開發(fā)實(shí)現(xiàn)。

也就是說(shuō)低代碼開發(fā)平臺(tái)并不能省略掉業(yè)務(wù)建模和系統(tǒng)建模這個(gè)動(dòng)作，而這個(gè)建模本身又需要一些業(yè)務(wù) 技術(shù)的雙背景往往才能夠更好去承擔(dān)該任務(wù)。

簡(jiǎn)單來(lái)說(shuō)，隨便一個(gè)人，給你一個(gè)低代碼開發(fā)平臺(tái)，你就能夠?qū)崿F(xiàn)一個(gè)完整的業(yè)務(wù)系統(tǒng)，這個(gè)本身就不現(xiàn)實(shí)。那么是否就說(shuō)低代碼開發(fā)平臺(tái)本身沒(méi)有價(jià)值？

要回答這個(gè)問(wèn)題，還是要將低代碼開發(fā)平臺(tái)分為兩大類。一類是零代碼偏配置的平臺(tái)，一類是真正低代碼面向開發(fā)人員的平臺(tái)。

零代碼偏配置的平臺(tái)

對(duì)于零代碼偏配置類低代碼平臺(tái)，整體來(lái)看，可以看到三類發(fā)展和演進(jìn)方向。

其一是將傳統(tǒng)企業(yè)工作中日常的表單流程實(shí)現(xiàn)電子化，自動(dòng)化，流程化。這里表單流本身更多是表單CRUD邏輯，配置權(quán)限和流程審批，沒(méi)有復(fù)雜的類似ERP系統(tǒng)一樣的后端業(yè)務(wù)規(guī)則需要實(shí)現(xiàn)。因此低代碼平臺(tái)一般能夠勝任。

其二是基于垂直行業(yè)應(yīng)用下擴(kuò)展低代碼開發(fā)能力，比如項(xiàng)目管理應(yīng)用，CRM應(yīng)用，包括復(fù)雜的ERP系統(tǒng)等。在這種場(chǎng)景下底層核心業(yè)務(wù)模型和對(duì)象模型是穩(wěn)定的，不能輕易出現(xiàn)變化，外部人員更多是基于低代碼開發(fā)能力進(jìn)行快速外圍能力擴(kuò)展。

其三是SaaS平臺(tái)類應(yīng)用的外圍生態(tài)構(gòu)建，最典型的就是類似釘釘這種SaaS應(yīng)用，其本身就是面對(duì)類似OA，HR等日常協(xié)同類應(yīng)用，流程表單多而規(guī)則并不復(fù)雜。因此提供一個(gè)低代碼平臺(tái)能力更加方便用戶進(jìn)行能力擴(kuò)展，SaaS平臺(tái)唯一需要考慮的就是底層組織引擎本身的穩(wěn)定性，統(tǒng)一注冊(cè)接入的接口標(biāo)準(zhǔn)和集成等。

真正低代碼面向開發(fā)人員的平臺(tái)

當(dāng)前我們談平臺(tái) 應(yīng)用構(gòu)建模式，談中臺(tái)和能力開放，談云原生平臺(tái)和ServerLess架構(gòu)。而這些都體現(xiàn)出一個(gè)關(guān)鍵特征，即：

應(yīng)用開發(fā)應(yīng)該是分層的，前后端分離的。

后端提供的是各種可復(fù)用的API接口服務(wù)能力，這些能力既包括了類似消息，緩存等技術(shù)服務(wù)能力，也包括了類似人員，組織，規(guī)則處理等業(yè)務(wù)服務(wù)服務(wù)能力。

前端應(yīng)用的開發(fā)更多的應(yīng)該是基于后端的API服務(wù)能力靈活地進(jìn)行組裝和編排來(lái)完成?；谶@個(gè)思路你會(huì)發(fā)現(xiàn)前端實(shí)際包括了兩個(gè)關(guān)鍵事情。

• 其一是低代碼平臺(tái)常說(shuō)的界面建模能力
• 其二是接口服務(wù)本身的組裝，服務(wù)編排能力

而對(duì)于后端來(lái)說(shuō)核心則是提供各種API接口服務(wù)。這些接口本身本身也分為了兩類，一類是在進(jìn)行對(duì)象建模完成后將簡(jiǎn)單對(duì)象或復(fù)合數(shù)據(jù)對(duì)象發(fā)布為API接口服務(wù)。其二是提供規(guī)則引擎來(lái)實(shí)現(xiàn)各種規(guī)則能力并發(fā)布為API接口服務(wù)。

對(duì)象直接發(fā)布為API接口很容易實(shí)現(xiàn)。

而真正困難或難以自動(dòng)化的就是規(guī)則引擎實(shí)現(xiàn)，并將規(guī)則發(fā)布為API接口服務(wù)的過(guò)程。前面已經(jīng)談到對(duì)于復(fù)雜業(yè)務(wù)規(guī)則或邏輯的實(shí)現(xiàn)，即使采用規(guī)則引擎，那么也存在大量手工編寫的規(guī)則實(shí)現(xiàn)腳本代碼，由于是腳本代碼，這些規(guī)則越寫越復(fù)雜，越是難以維護(hù)。

當(dāng)我重新思考這個(gè)問(wèn)題的時(shí)候，發(fā)現(xiàn)面向開發(fā)的低代碼平臺(tái)，核心是規(guī)則引擎和服務(wù)編排，同時(shí)在引入這兩個(gè)關(guān)鍵組件時(shí)候，你也要意識(shí)到對(duì)于復(fù)雜規(guī)則實(shí)現(xiàn)，復(fù)雜的編排，最好的方式仍然是寫代碼來(lái)實(shí)現(xiàn)，最終將其暴露為API接口服務(wù)。

也就是說(shuō)這類規(guī)則服務(wù)或領(lǐng)域服務(wù)能力本身還是可以代碼實(shí)現(xiàn)的，是可以維護(hù)的。

就規(guī)則引擎和服務(wù)編排來(lái)講。

個(gè)人理解前期在自動(dòng)化的實(shí)現(xiàn)中，重點(diǎn)不是規(guī)則引擎，而是可視化的服務(wù)編排能力實(shí)現(xiàn)。當(dāng)前已經(jīng)有不少的微服務(wù)架構(gòu)下的微服務(wù)API編排開源組件實(shí)現(xiàn)，但是前面我文章也分析過(guò)并不是特別的靈活和可配置。

對(duì)于服務(wù)編排場(chǎng)景的詳細(xì)闡述，可以參考下面這篇文章。

從ESB服務(wù)組合編排到NetflixConductor微服務(wù)編排

一個(gè)可視化服務(wù)編排，重點(diǎn)在哪里？

我們可以對(duì)這個(gè)問(wèn)題簡(jiǎn)單思考，比如前端在進(jìn)行界面設(shè)計(jì)建模的時(shí)候，最喜歡的就是各種界面組件，控件，按鈕，能夠直接掛接到一個(gè)統(tǒng)一的組合服務(wù)API上面，而不是說(shuō)前端人員在界面設(shè)計(jì)的時(shí)候還需要去搞清楚點(diǎn)擊安排究竟要調(diào)用幾個(gè)API接口，而且調(diào)用過(guò)程中還需要遵循什么樣的規(guī)則邏輯。

在前后端分離的場(chǎng)景下，前端并不關(guān)心復(fù)雜的后端邏輯。

從這個(gè)道理上來(lái)講，微服務(wù)編排需要考慮的就是將多個(gè)細(xì)粒度的原子服務(wù)或API接口，統(tǒng)一組合或組裝為一個(gè)大的API接口服務(wù)的能力。

這種服務(wù)組裝或組合本身只包括兩大類。

第一類是偏靜態(tài)的數(shù)據(jù)組合，組裝和拆分。比如你點(diǎn)按鈕要獲取數(shù)據(jù)，原來(lái)是要查詢兩次API接口，現(xiàn)在我給你組合下，調(diào)用一個(gè)大API組合服務(wù)，一次給你返回所有數(shù)據(jù)?；蛘哒f(shuō)類似單據(jù)保存過(guò)程，你原來(lái)是需要調(diào)用兩個(gè)API接口分別保存頭和明細(xì)，現(xiàn)在我給你組合下，你一次把完整數(shù)據(jù)對(duì)象送過(guò)來(lái)，我一次給你保存完。這些是屬于典型的傳統(tǒng)基于領(lǐng)域?qū)ο蟮念I(lǐng)域服務(wù)API接口實(shí)現(xiàn)的。

第二類是偏動(dòng)態(tài)的自動(dòng)化業(yè)務(wù)流程處理，類似在傳統(tǒng)SOA架構(gòu)里面說(shuō)的BPEL自動(dòng)化業(yè)務(wù)流程處理。這種業(yè)務(wù)流都是系統(tǒng)后端自動(dòng)完成，不需要人工干預(yù)，比如點(diǎn)擊按鈕要自動(dòng)產(chǎn)生一個(gè)待辦工單，比如提交報(bào)賬前要首先調(diào)用預(yù)算API接口進(jìn)行預(yù)算檢查，比如在單據(jù)保存成功后自動(dòng)化去啟動(dòng)流程API接口等。這類服務(wù)組裝或編排往往體現(xiàn)出一張接口服務(wù)串行調(diào)用的典型特征，即前一個(gè)API接口輸出會(huì)成為一個(gè)接口的輸入。

那么第二類服務(wù)編排究竟應(yīng)該是基于服務(wù)的同步事務(wù)處理，還是基于消息事件的異步編排就變成一個(gè)關(guān)鍵點(diǎn)。如果是同步你需要考慮補(bǔ)償或回退機(jī)制，如果是異步消息，你需要保證消息最終一致性等。

當(dāng)前我沒(méi)看到任何一個(gè)輕量級(jí)的基于微服務(wù)API接口的可視化服務(wù)編排工具，如果有相關(guān)的可以推薦給我進(jìn)行分析和研究。同時(shí)我也再次提出基于微服務(wù)API的輕量，靈活，可視化服務(wù)編排工具，往往是一個(gè)重要的低代碼平臺(tái)發(fā)展趨勢(shì)。