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

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

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

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

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

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

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

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

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

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

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

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

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

（LCDP for PRO）

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

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

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

整套邏輯編排機制，可以運行在前端，也能運行在后端。

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

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

（計算公式引擎）

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

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

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

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

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

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

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

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

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

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

最后附上葡萄城低代碼專家問答：

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

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

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

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

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

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

Q：這個算是以前針對開發(fā)人員的代碼生成器？能夠加快開發(fā)進度？

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

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