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

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

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

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

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

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

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

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

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

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

零代碼偏配置的平臺

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

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

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

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

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

當(dāng)前我們談平臺 應(yīng)用構(gòu)建模式，談中臺和能力開放，談云原生平臺和ServerLess架構(gòu)。而這些都體現(xiàn)出一個關(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)行組裝和編排來完成。基于這個思路你會發(fā)現(xiàn)前端實際包括了兩個關(guān)鍵事情。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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