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

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

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

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

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

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

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

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

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

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

零代碼偏配置的平臺

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

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

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

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

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

當前我們談平臺 應用構建模式，談中臺和能力開放，談云原生平臺和ServerLess架構。而這些都體現(xiàn)出一個關鍵特征，即：

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

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

前端應用的開發(fā)更多的應該是基于后端的API服務能力靈活地進行組裝和編排來完成。基于這個思路你會發(fā)現(xiàn)前端實際包括了兩個關鍵事情。

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

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

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

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

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

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

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

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

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

從ESB服務組合編排到NetflixConductor微服務編排

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

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

在前后端分離的場景下，前端并不關心復雜的后端邏輯。

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

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

第一類是偏靜態(tài)的數據組合，組裝和拆分。比如你點按鈕要獲取數據，原來是要查詢兩次API接口，現(xiàn)在我給你組合下，調用一個大API組合服務，一次給你返回所有數據?；蛘哒f類似單據保存過程，你原來是需要調用兩個API接口分別保存頭和明細，現(xiàn)在我給你組合下，你一次把完整數據對象送過來，我一次給你保存完。這些是屬于典型的傳統(tǒng)基于領域對象的領域服務API接口實現(xiàn)的。

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

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

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