從許多調(diào)查報(bào)告上看，開(kāi)發(fā)人員群體對(duì)低代碼的評(píng)估維度集中在幾個(gè)點(diǎn)上：頁(yè)面的靈活性、業(yè)務(wù)邏輯的靈活性和技術(shù)架構(gòu)的專業(yè)性。而這幾個(gè)點(diǎn)也是不同的低代碼廠商和產(chǎn)品差異性最明顯的領(lǐng)域。今天，我們以活字格為例，將目光聚焦在可視化業(yè)務(wù)邏輯構(gòu)建的原理和體驗(yàn)上和大家聊聊。

從Forrester在2014年提出低代碼概念到現(xiàn)在，低代碼的定義逐漸清晰。

低代碼的主要特征是全程可視化開(kāi)發(fā)，本質(zhì)上講，是一套元數(shù)據(jù)驅(qū)動(dòng)的可視化開(kāi)發(fā)解決方案。這里的元數(shù)據(jù)是一個(gè)泛化的概念，不單指數(shù)據(jù)字段的定義，還要包含業(yè)務(wù)邏輯。業(yè)務(wù)邏輯在元數(shù)據(jù)中，主要體現(xiàn)為組件的配置和編排。

（低代碼的本質(zhì)：元數(shù)據(jù)驅(qū)動(dòng)的可視化開(kāi)發(fā)解決方案）

組件是低代碼中最關(guān)鍵的關(guān)鍵，在不同的產(chǎn)品中，這些組件有不同的名字，比如節(jié)點(diǎn)、命令等。低代碼平臺(tái)在學(xué)習(xí)門檻、應(yīng)用場(chǎng)景和使用群體的差異化主要源于這些組件的抽象程度不同。抽象程度越高，應(yīng)對(duì)復(fù)雜應(yīng)用場(chǎng)景的靈活性也就越差。與之對(duì)應(yīng)，抽象程度偏低的話，必然會(huì)引入IT技術(shù)概念，導(dǎo)致學(xué)習(xí)門檻顯著提升。所以，低代碼內(nèi)置組件是否引入IT技術(shù)概念，特別是軟件開(kāi)發(fā)概念，是區(qū)分面向技術(shù)人員的低代碼和無(wú)代碼（面向業(yè)務(wù)人員的低代碼在市場(chǎng)端正在更名為無(wú)代碼，是Forrester和中軟協(xié)的共識(shí)）的重要標(biāo)志。

（組件的抽象層次是關(guān)鍵：業(yè)務(wù)語(yǔ)言 vs 技術(shù)語(yǔ)言）

面向業(yè)務(wù)人員的組件，在設(shè)計(jì)上傾向于現(xiàn)實(shí)中可以看到的東西，比如頁(yè)面上的元素和操作，如字段、規(guī)則、增刪改查等。封裝層次過(guò)高，能覆蓋的場(chǎng)景就會(huì)變少。通常來(lái)說(shuō)，可配置的項(xiàng)目隨著封裝的層次增長(zhǎng)，比如我們將4個(gè)各自有3個(gè)配置項(xiàng)目的元素封裝在一起，需要提供的選項(xiàng)是3^4=81。如果封裝到第一層，那么提供的配置項(xiàng)目只有3*4=12?，F(xiàn)實(shí)中的可配置性遠(yuǎn)不止這么3-4個(gè)，這種高封裝的組件顯然無(wú)法提供這種指數(shù)增長(zhǎng)的配置性，最終也就表現(xiàn)為靈活性更差，可配置性不足了。

（圖片來(lái)源于網(wǎng)絡(luò)）

從另一個(gè)角度看，主要編碼命令就是常見(jiàn)的命令式語(yǔ)言和聲明式語(yǔ)言。廣義上講，這兩種都可以成為元數(shù)據(jù)，比如C#需要編譯成IL，CLR加載IL來(lái)執(zhí)行動(dòng)作，這里的IL就是元數(shù)據(jù)。因?yàn)榉庋b層次太低，用戶對(duì)此無(wú)法感知。在命令式語(yǔ)言的基礎(chǔ)上，還有一種類型是聲明式語(yǔ)言。聲明式語(yǔ)言的封裝層次有一定提升，通常面向特定的領(lǐng)域，提供足夠的靈活性。比如在頁(yè)面渲染中的HTML，數(shù)據(jù)庫(kù)操作中的SQL。相比于命令式語(yǔ)言，聲明式語(yǔ)言的優(yōu)缺點(diǎn)很明確，整體上看在現(xiàn)在的軟件開(kāi)發(fā)領(lǐng)域之中使用聲明式語(yǔ)言是利大于弊的。

（元數(shù)據(jù)驅(qū)動(dòng)）

最初桌面應(yīng)用開(kāi)發(fā)，不管是MFC還是WinForm，都采用了命令式語(yǔ)言。后來(lái)WPF、H5、Android、iOS，全都切換成了聲明式語(yǔ)言，可以看出聲明式語(yǔ)言在界面展示上是有優(yōu)勢(shì)的。

造成這個(gè)情況一個(gè)不容忽視的原因是早期的終端設(shè)備計(jì)算能力太差，很難承擔(dān)解析的工作；現(xiàn)在交互終端的計(jì)算能力越來(lái)越強(qiáng)，解析聲明式語(yǔ)言的性能開(kāi)銷已經(jīng)客戶忽略不計(jì)了。

回到低代碼的話題，低代碼平臺(tái)提供的組件封裝是介于業(yè)務(wù)模型和聲明式語(yǔ)言中間的。我們以駕照識(shí)別為例，抽象程度可以簡(jiǎn)單地分為四層。越往下封裝粒度越低，往上越高。不同的低代碼平臺(tái)在這個(gè)事情上有什么不一樣呢？按照低代碼概念提出者Forrester的觀點(diǎn)，低代碼平臺(tái)可以分為面向?qū)I(yè)開(kāi)發(fā)者和業(yè)務(wù)人員兩類。在這個(gè)問(wèn)題上，封裝層次有非常顯著的差異。前者通常會(huì)提供全部四層，而后者則通常提供上兩層。

（LCDP for PRO）

所以，對(duì)于面向業(yè)務(wù)人員的低代碼來(lái)說(shuō)，不支持復(fù)雜的業(yè)務(wù)邏輯和WebAPI構(gòu)建能力，也就很好理解了。不是技術(shù)無(wú)法實(shí)現(xiàn)，而是市場(chǎng)定位不需要做。

作為Forrester LCDP for PRO的代表產(chǎn)品之一，活字格為復(fù)雜業(yè)務(wù)邏輯構(gòu)建提供了什么樣的組件和編排體驗(yàn)?zāi)?？首先在設(shè)計(jì)時(shí)，活字格將組件的封裝層次下沉到了接近編碼開(kāi)發(fā)的層面，在此基礎(chǔ)上提供一些常用的高層次能力。在體驗(yàn)上，用表達(dá)式樹(shù)的形式，模擬編碼開(kāi)發(fā)的縮進(jìn)層級(jí)。

（可視化構(gòu)建業(yè)務(wù)處理邏輯）

整套邏輯編排機(jī)制，可以運(yùn)行在前端，也能運(yùn)行在后端。

除了組件和編排，我們還需要提供一些可以與組件進(jìn)行交互的函數(shù)。為了盡可能多地覆蓋多樣化的應(yīng)用場(chǎng)景，函數(shù)庫(kù)的完備性是一個(gè)不小的挑戰(zhàn)。.NET和VBA的函數(shù)庫(kù)太過(guò)分散，而且過(guò)于龐大了，于是我們選擇了參考另一個(gè)在企業(yè)信息化中常用的方案——Excel。

于是，我們將Excel公式作為范本，實(shí)現(xiàn)了400多個(gè)計(jì)算公式。選擇這條路還有一個(gè)重要的原因，那就是在過(guò)去的30年里，我們?cè)陂_(kāi)發(fā)Spread表格控件的同時(shí)，積累下了一套完善的表達(dá)式引擎。直接拿過(guò)來(lái)，放到業(yè)務(wù)邏輯引擎里，事半功倍，而且成熟度高。如果你自己做類似的功能，也可以使用SpreadJS，直接調(diào)用里面的CalcEngine。

（計(jì)算公式引擎）

復(fù)雜的業(yè)務(wù)邏輯通常無(wú)法保證一步到位，所以在解決了構(gòu)建問(wèn)題后，我們還需要解決調(diào)試和自測(cè)的問(wèn)題。調(diào)試是聲明式語(yǔ)言相對(duì)于命令式語(yǔ)言的劣勢(shì)，如我們無(wú)法調(diào)試HTML的渲染過(guò)程。但是，SQL Management Studio給了我們一個(gè)解決的思路：將執(zhí)行日志完整的打出來(lái)。這里的“完整”，指的是輸出每一步的變量，每一個(gè)分支條件以及每一個(gè)組件的執(zhí)行耗時(shí)，還有對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作的所有SQL語(yǔ)句。

這種日志不但可以用于自測(cè)和調(diào)試，在后期需要維護(hù)這段業(yè)務(wù)邏輯，甚至接手他人開(kāi)發(fā)的業(yè)務(wù)邏輯時(shí)，可視化的表達(dá)式樹(shù)加完整的執(zhí)行日志，都能起到很大的作用。

在復(fù)雜業(yè)務(wù)能力的基礎(chǔ)上，WebAPI的構(gòu)建就水到渠成了。我們只需要在運(yùn)行在服務(wù)端的業(yè)務(wù)邏輯的基礎(chǔ)上，提供WebAPI所需的“殼子”。

介紹到這里，我們可以明確地感覺(jué)到，構(gòu)建WebAPI和復(fù)雜業(yè)務(wù)邏輯，用到組件都是面向開(kāi)發(fā)人員的語(yǔ)言體系，這再次印證了面向業(yè)務(wù)人員的低代碼和無(wú)代碼平臺(tái)通常不會(huì)提供類似功能的判斷。畢竟，想要給沒(méi)有任何IT基礎(chǔ)的業(yè)務(wù)人員培訓(xùn)這么一套體系，投入是巨大的，回報(bào)風(fēng)險(xiǎn)是很大的。

回到產(chǎn)品需求，如果只是開(kāi)發(fā)復(fù)雜業(yè)務(wù)邏輯，我們似乎無(wú)需構(gòu)建WebAPI。那么，為什么活字格會(huì)專門搞出WebAPI構(gòu)建能力，它可以用來(lái)做什么，只是為了做前端后端分離，讓低代碼開(kāi)發(fā)和編碼開(kāi)發(fā)進(jìn)行配合嗎？明確這一點(diǎn)很重要，這是為咱們團(tuán)隊(duì)從編碼開(kāi)發(fā)向低代碼轉(zhuǎn)型增加了一條更現(xiàn)實(shí)的路徑，低代碼的能力僅限于此嗎？

（雙向WebAPI集成-水平分割的混合開(kāi)發(fā)模式）

答案顯然是否定的， WebAPI最主要的應(yīng)用場(chǎng)景是系統(tǒng)集成。企業(yè)信息化走到今天，每家企業(yè)都已經(jīng)擁有了各類軟件應(yīng)用，如何與這些不同時(shí)代，不同技術(shù)架構(gòu)的系統(tǒng)做集成，減少數(shù)據(jù)孤島？這是低代碼平臺(tái)必須要解決的問(wèn)題，至少不能造新的數(shù)據(jù)孤島。在做集成的時(shí)候，除了主動(dòng)調(diào)用其他系統(tǒng)外，為其他系統(tǒng)提供WebAPI接口，供其調(diào)用是很常見(jiàn)的場(chǎng)景。

總結(jié)一下，今天我們探討了低代碼與元數(shù)據(jù)驅(qū)動(dòng)的關(guān)系，組件的抽象程度與應(yīng)用場(chǎng)景和靈活性的關(guān)系，用來(lái)支撐復(fù)雜業(yè)務(wù)邏輯的組件設(shè)計(jì)和編排方式，輸出詳細(xì)日志輔助調(diào)試的機(jī)制，將業(yè)務(wù)邏輯封裝為WebAPI的要點(diǎn)和系統(tǒng)集成的應(yīng)用場(chǎng)景。最后用一段視頻，直觀展示了使用活字格構(gòu)建WebAPI的用戶體驗(yàn)。

在之前的內(nèi)容中，我們推出過(guò)一個(gè)公開(kāi)課，詳細(xì)介紹使用活字格構(gòu)建WebAPI的過(guò)程。搭配視頻和活字格低代碼平臺(tái)，感興趣的朋友可以親身體驗(yàn)一下。

———————————————————————————–

最后附上葡萄城低代碼專家問(wèn)答：

Q：老師您好，看了你講的內(nèi)容獲益匪淺，我有兩個(gè)問(wèn)題：（一）低代碼工具提升項(xiàng)目開(kāi)發(fā)效率方面有沒(méi)有已經(jīng)量化的指標(biāo)？（二）如果需要程序員解決自定義的功能問(wèn)題，是否有對(duì)應(yīng)的開(kāi)發(fā)語(yǔ)言的接入機(jī)制？

A：?jiǎn)栴}1，我這有幾個(gè)項(xiàng)目的實(shí)際案例，效率提升的幅度主要看項(xiàng)目需求的類型，增刪改查占比越高，提升越大。界面精細(xì)化要求越低，提升越大。這里的第二個(gè)和第三個(gè)，規(guī)模類似，復(fù)雜度類似，只是因?yàn)榈谌齻€(gè)是面向連鎖醫(yī)美會(huì)員客戶的，界面要求高，開(kāi)發(fā)效率受到了很大影響；問(wèn)題2，低代碼平臺(tái)哪有全靠廠商自己搞的。大多提供各層級(jí)的編程接口。讓你可以接管、替換任何一次層次，來(lái)滿足低代碼平臺(tái)內(nèi)置能力搞不定的場(chǎng)景。前端需要提供JS接口，能操作頁(yè)面元素；后端需要提供Java/C#接口，實(shí)現(xiàn)特殊API集成；數(shù)據(jù)庫(kù)端還得支持直接執(zhí)行SQL語(yǔ)句，提升性能；用戶認(rèn)證層面支持安全接口，實(shí)現(xiàn)用戶集成。再“高級(jí)”一點(diǎn)，還得支持插件接口，能直接擴(kuò)展低代碼平臺(tái)的能力，提供給自己用之外，還能賣給其他開(kāi)發(fā)者，獲得盈利。

Q：這種低代碼平臺(tái)，跟RPA廠商的低代碼平臺(tái)有什么區(qū)別呀？

A：RPA廠商，低代碼是為了擴(kuò)充自己RPA的能力，通常會(huì)和自己家的產(chǎn)品或場(chǎng)景深度綁定。

Q：我想問(wèn)一下，低代碼是云廠商才能做還是公司自己就可以做？現(xiàn)在看到的基本上都云廠商在做？

A：從Forrester的報(bào)告上看，云廠商只是其中一個(gè)分類。只是，互聯(lián)網(wǎng)大廠的市場(chǎng)宣傳能力，實(shí)在不是其他類型廠商可以比擬的。

Q：這個(gè)算是以前針對(duì)開(kāi)發(fā)人員的代碼生成器？能夠加快開(kāi)發(fā)進(jìn)度？

A：可以理解為，這個(gè)是代碼生成器的“進(jìn)階版”。代碼生成器是一次性的工具，一旦在生成的代碼上再開(kāi)發(fā)，通常就沒(méi)有辦法再享受可視化的效率提升了。低代碼走了元數(shù)據(jù)驅(qū)動(dòng)的路線，可以在后續(xù)的開(kāi)發(fā)和維護(hù)中，一直用可視化的方式進(jìn)行。

大家如果有更多想法歡迎在評(píng)論區(qū)交流。