基于 LowCodeEngine 的調(diào)試能力建設(shè)與實(shí)踐

概述

業(yè)務(wù)背景

低代碼由于研發(fā)效能和交付的優(yōu)勢(shì)變得越來(lái)越普及，在降本提效的同時(shí)也帶來(lái)了很多黑盒邏輯。現(xiàn)有的低代碼平臺(tái)普遍缺乏面向用戶的調(diào)試能力，當(dāng)用戶在低代碼搭建遇到問(wèn)題時(shí)，排查和解決問(wèn)題強(qiáng)依賴平臺(tái)的客服答疑或?yàn)g覽器原生的調(diào)試能力，導(dǎo)致非前端用戶使用低代碼平臺(tái)的成本很高。因此我們需要提供更適合低代碼平臺(tái)的調(diào)試能力，降低低代碼平臺(tái)的使用成本。

技術(shù)難點(diǎn)

在阿里低代碼引擎的產(chǎn)品技術(shù)體系中，一方面我們需要提供低代碼平臺(tái)的基礎(chǔ)調(diào)試能力，適用于大多數(shù)低代碼的調(diào)試能力，需要考慮非前端用戶的使用習(xí)慣和學(xué)習(xí)成本；另一方面由于低代碼平臺(tái)的目標(biāo)用戶類型差異較大，不同低代碼平臺(tái)所需的調(diào)試能力也是不一樣的，除了基礎(chǔ)的調(diào)試能力之外，我們需要通過(guò)提供擴(kuò)展定制能力，幫助不同的低代碼平臺(tái)快速建設(shè)適合的調(diào)試能力。

技術(shù)細(xì)節(jié)

在技術(shù)架構(gòu)上，我們通過(guò)分層設(shè)計(jì)，將調(diào)試體系分為 Client、Server、Protocol 等不同層來(lái)承擔(dān)不同的職責(zé)，向下做好協(xié)議的統(tǒng)一收斂，與低代碼引擎的協(xié)議和渲染體系對(duì)接，向上也能支持不同分層下的高度定制。在產(chǎn)品設(shè)計(jì)上，我們?cè)诘痛a引擎標(biāo)準(zhǔn)協(xié)議的基礎(chǔ)上完成了日志查看、錯(cuò)誤碼定位、審查元素、數(shù)據(jù)源查看與修改等低代碼調(diào)試能力上的探索。具體實(shí)踐和分析：低代碼引擎體系下的調(diào)試能力在集團(tuán)內(nèi)的中后臺(tái)平臺(tái) A 落地了半年，活躍用戶總量為 300，占比平臺(tái)總月活的 10%，并大幅度降低了答疑中調(diào)試相關(guān)問(wèn)題的占比。

低代碼引擎介紹

低代碼引擎是一款為低代碼平臺(tái)開(kāi)發(fā)者提供的，具備強(qiáng)大擴(kuò)展能力的低代碼研發(fā)框架。由阿里巴巴終端委員會(huì)（原阿里巴巴前端委員會(huì)）、釘釘宜搭聯(lián)合出品。使用者只需要基于低代碼引擎便可以快速定制符合自己業(yè)務(wù)需求的低代碼平臺(tái)。同時(shí)，低代碼引擎還在標(biāo)準(zhǔn)低代碼設(shè)計(jì)器的基礎(chǔ)上提供了簡(jiǎn)單易用的定制擴(kuò)展能力，能夠滿足業(yè)務(wù)獨(dú)特的功能需要。

開(kāi)源地址：https://github.com/alibaba/lowcode-engine

官網(wǎng)：http://lowcode-engine.cn/#/

點(diǎn)擊文末「閱讀原文」，可直接跳轉(zhuǎn)查看

低代碼調(diào)試背景介紹

在阿里內(nèi)部有很多低代碼平臺(tái)，其中圖中的這款低代碼平臺(tái)是用于開(kāi)發(fā)中后臺(tái)頁(yè)面。由于這個(gè)平臺(tái)沉淀的時(shí)間比較久，因此用戶量相對(duì)比較多，覆蓋的人群類型也比較廣泛。

該低代碼平臺(tái)月活躍用戶有大概 4000 人左右，這 4000 人里面有前端、后端、測(cè)試開(kāi)發(fā)等。其中大概只有 30% 的使用者是前端研發(fā)，而剩下 70% 的使用者都是非前端研發(fā)人員。為了幫助這 4000 人使用該低代碼平臺(tái)，該低代碼平臺(tái)提供了兩個(gè)前端全職進(jìn)行答疑，幫助該平臺(tái)的使用者解決他們遇到的問(wèn)題。

我們可以看到，答疑同學(xué)一個(gè)月大概需要解決 400 多個(gè)答疑工單，這些工單里面有大量的使用問(wèn)題和應(yīng)用調(diào)試問(wèn)題。

那我們來(lái)假設(shè)一下，如果這個(gè)低代碼平臺(tái)沒(méi)有前端同學(xué)來(lái)進(jìn)行答疑，那是不是有至少 400 多個(gè)使用者有可能無(wú)法使用我們的低代碼平臺(tái)。我認(rèn)為是非常有可能的，在這種情況下，如果他們遇到問(wèn)題，找不到渠道來(lái)解決問(wèn)題的，因此對(duì)低代碼平臺(tái)產(chǎn)生不好的印象，他們就很容易拋棄掉這個(gè)低代碼平臺(tái)，甚至拋棄掉所有的的低代碼平臺(tái)也是有可能的。

這樣我們可以看出來(lái)這個(gè)低代碼平臺(tái)有兩個(gè)問(wèn)題：

• 答疑成本高，對(duì)于非前端研發(fā)同學(xué)來(lái)說(shuō)，十分依賴答疑同學(xué)提供的支持，這樣會(huì)導(dǎo)致低代碼平臺(tái)用戶量越多，答疑成本就越高，
• 學(xué)習(xí)門(mén)檻高：就算有足夠的答疑支持，非前端研發(fā)使用低代碼平臺(tái)也有較高的學(xué)習(xí)成本，這就導(dǎo)致低代碼平臺(tái)很難進(jìn)行更大范圍的推廣。

因此，我們需要去減少答疑的成本，為了找到減少答疑的解決方案，我們先來(lái)分析一下答疑的案例。

這是一個(gè)答疑同學(xué)在答疑過(guò)程中和低代碼平臺(tái)的使用者溝通的過(guò)程。

在最開(kāi)始的時(shí)候，用戶會(huì)跟答疑人員說(shuō)遇到了一個(gè)報(bào)錯(cuò)，需要答疑人員幫忙看看問(wèn)題在哪里。這時(shí)候一般都需要用戶提供可以讓答疑人員復(fù)現(xiàn)問(wèn)題的步驟。比如說(shuō)，需要提供報(bào)錯(cuò)頁(yè)面的地址。在大多數(shù)情況下，這些頁(yè)面都有權(quán)限管控，需要找對(duì)應(yīng)的權(quán)限管理員來(lái)添加權(quán)限。甚至有的項(xiàng)目因?yàn)樘砑訖?quán)限太麻煩，只能通過(guò)截圖或者視頻來(lái)查看和定位問(wèn)題。

所以這個(gè)案例暴露出來(lái)的第一個(gè)問(wèn)題是權(quán)限管控會(huì)讓答疑時(shí)間更長(zhǎng)，也讓查看和定位問(wèn)題的難度更高了。

我們繼續(xù)看第二部分，當(dāng)權(quán)限添加完成之后，用戶和答疑人員往往還要溝通復(fù)現(xiàn)路徑，由于用戶和答疑人員溝通過(guò)程往往存在信息差，所以需要反復(fù)溝通才能明確復(fù)現(xiàn)的步驟，答疑人員才能復(fù)現(xiàn)出報(bào)錯(cuò)場(chǎng)景，才能找到到問(wèn)題。

我們可以看出來(lái)，這里暴露的第二個(gè)問(wèn)題是復(fù)現(xiàn)問(wèn)題溝通耗時(shí)且繁瑣。

找到問(wèn)題之后，發(fā)現(xiàn)這些問(wèn)題很有可能是一些對(duì)于前端很簡(jiǎn)單的問(wèn)題，比如說(shuō)標(biāo)點(diǎn)符號(hào)使用錯(cuò)誤，中英文符號(hào)使用錯(cuò)誤等。因?yàn)榇蠖鄶?shù)低代碼平臺(tái)的使用者是非前端開(kāi)發(fā)，他們沒(méi)有前端相關(guān)的基礎(chǔ)。因此對(duì)于前端來(lái)說(shuō)很簡(jiǎn)單的問(wèn)題沒(méi)有辦法自己解決，就只能依賴答疑人員的幫助。那如果缺少了答疑，沒(méi)有前端基礎(chǔ)的使用者想要解決類似的問(wèn)題，學(xué)習(xí)成本還是非常高的

因此，一方面為了減少答疑的溝通成本、另外一方面為了降低非前端研發(fā)同學(xué)的學(xué)習(xí)成本。我們決定為低代碼平臺(tái)提供低代碼調(diào)試工具。

低代碼調(diào)試能力建設(shè)

首先我們來(lái)看一下該低代碼平臺(tái)調(diào)試的現(xiàn)狀。這里我們?cè)O(shè)計(jì)了一個(gè)頁(yè)面，這個(gè)頁(yè)面在設(shè)計(jì)器中是沒(méi)有問(wèn)題的，但是當(dāng)我們?cè)谀骋粋€(gè)組件中配置了一個(gè)錯(cuò)誤的表達(dá)式，我們?cè)陬A(yù)覽的時(shí)候就會(huì)看到頁(yè)面出現(xiàn)報(bào)錯(cuò)。對(duì)于前端來(lái)說(shuō)，可以打開(kāi)控制臺(tái)查看報(bào)錯(cuò)信息，報(bào)錯(cuò)信息就像圖中展示的這樣。

這個(gè)報(bào)錯(cuò)信息能幫助低代碼開(kāi)發(fā)師找到問(wèn)題嗎？實(shí)際上，不管是對(duì)于前端研發(fā)人員來(lái)說(shuō)，還是對(duì)于非前端研發(fā)來(lái)說(shuō)，都是很難直接定位到問(wèn)題的。

一方面，這個(gè)頁(yè)面很有可能有幾百上千個(gè)節(jié)點(diǎn)，每一個(gè)節(jié)點(diǎn)都有很多個(gè)配置。這個(gè)報(bào)錯(cuò)信息沒(méi)有告訴我們這個(gè)報(bào)錯(cuò)的代碼是配置在哪個(gè)組件節(jié)點(diǎn)里面的。也不能讓用戶打開(kāi)每一個(gè)節(jié)點(diǎn)來(lái)檢查每一個(gè)配置。

另外一個(gè)方面，低代碼平臺(tái)可以配置代碼的地方很多，這樣就導(dǎo)致我們的代碼是非常散亂的。我們無(wú)法通過(guò)現(xiàn)有信息知道報(bào)錯(cuò)代碼配置的方式，配置的地方。也就是說(shuō)，就算是前端，也很難找到報(bào)錯(cuò)代碼的。

為了讓低代碼平臺(tái)的使用者能自己解決這類調(diào)試問(wèn)題，我們就需要提供一個(gè)調(diào)試工具，讓用戶可以

• 直觀的知道如何查看報(bào)錯(cuò)的內(nèi)容
• 可以根據(jù)報(bào)錯(cuò)內(nèi)容，知道報(bào)錯(cuò)的代碼在哪里
• 在找到報(bào)錯(cuò)的代碼之后，知道如何去修改代碼，修復(fù)問(wèn)題。

有了這個(gè)工具之后，低代碼平臺(tái)的使用者就可以自己解決問(wèn)題，也就大大減少對(duì)答疑人員的依賴了。

對(duì)于第一個(gè)問(wèn)題，我們需要讓低代碼平臺(tái)的使用者知道“如何查看報(bào)錯(cuò)”，我們提供的解決方案是，在遇到報(bào)錯(cuò)的時(shí)候，我們通過(guò)一個(gè)顯眼的標(biāo)識(shí)來(lái)告訴用戶，你開(kāi)發(fā)的頁(yè)面出現(xiàn)錯(cuò)誤了，其中錯(cuò)誤的個(gè)數(shù)有多少個(gè)。用戶看到這個(gè)標(biāo)識(shí)之后，就會(huì)去點(diǎn)擊這個(gè)標(biāo)識(shí)。當(dāng)用戶點(diǎn)擊之后，就會(huì)在頁(yè)面中出現(xiàn)低代碼調(diào)試工具，來(lái)幫助用戶查看報(bào)錯(cuò)相關(guān)的信息。

在這個(gè)調(diào)試工具中，我們通過(guò)展示日志的方式，來(lái)讓用戶更加直觀的找到跟錯(cuò)誤有關(guān)的信息。并且，慢慢的用戶就知道我們提供了一個(gè)工具來(lái)幫助他們開(kāi)發(fā)低代碼頁(yè)面。之后遇到其他問(wèn)題也會(huì)自己打開(kāi)低代碼調(diào)試工具，相當(dāng)于起到了鍛煉用戶開(kāi)發(fā)習(xí)慣的作用。

在用戶知道如何查看報(bào)錯(cuò)之后，接下來(lái)的問(wèn)題就是如何通過(guò)日志輸出的能力，讓用戶知道錯(cuò)誤的代碼在哪里。

對(duì)于這個(gè)問(wèn)題，我們通過(guò)給不同類型的報(bào)錯(cuò)提供對(duì)應(yīng)的錯(cuò)誤碼，來(lái)幫助用戶找到報(bào)錯(cuò)代碼。

1. 首先對(duì)于不同類型的錯(cuò)誤，我們會(huì)提供一個(gè)單獨(dú)的錯(cuò)誤碼，并且還會(huì)提供對(duì)應(yīng)的上下文信息，比如組件 ID 是多少，用戶配置的表達(dá)式內(nèi)容是什么；
2. 當(dāng)然有了這些信息還是不夠的，我們還需要將上下文信息用更語(yǔ)義化的方式展示給用戶。因此為了更好的組織這些錯(cuò)誤碼、對(duì)應(yīng)的上下文信息以及展示給用戶的描述文案，我們利用錯(cuò)誤碼管理后臺(tái)來(lái)管理這些信息。

有了這些信息，我們?cè)诘痛a調(diào)試工具的日志面板中就可以展示出非常詳細(xì)的信息來(lái)幫助用戶找到報(bào)錯(cuò)的代碼。

比如：之前我們?cè)诳刂婆_(tái)中看到的錯(cuò)誤，在日志面板中展示的內(nèi)容就變成了：某某某組件表達(dá)式執(zhí)行出現(xiàn)錯(cuò)誤，并給出了錯(cuò)誤的原因，給出了錯(cuò)誤的表達(dá)式內(nèi)容，錯(cuò)誤的組件 ID 等信息。用戶通過(guò)組件 ID 就可以在低代碼平臺(tái)中進(jìn)行搜索，就可以找到對(duì)應(yīng)的組件了。也就能找到報(bào)錯(cuò)的代碼了。

對(duì)于非前端研發(fā)來(lái)說(shuō)，我們幫助用戶找到錯(cuò)誤的代碼還不能完全解決問(wèn)題，我們還需要告訴他們?nèi)绾涡薷拇a來(lái)解決錯(cuò)誤。

為了解決這個(gè)問(wèn)題，我們?cè)阱e(cuò)誤日志的基礎(chǔ)上，增加了一個(gè)外鏈功能，用戶可以點(diǎn)擊這個(gè)外鏈，打開(kāi)一個(gè)錯(cuò)誤碼對(duì)應(yīng)的文檔，這個(gè)文檔通過(guò)圖文的方式詳細(xì)的描述了問(wèn)題的解決步驟。這樣對(duì)于一些簡(jiǎn)單的問(wèn)題，用戶就可以找到解決方案。

當(dāng)然，對(duì)于一些相對(duì)復(fù)雜的報(bào)錯(cuò)案例，用戶可能還是無(wú)法自己解決問(wèn)題，還是需要答疑人員的幫助。為了減少用戶和答疑人員來(lái)回溝通的成本，我們還支持用戶上傳頁(yè)面日志，日志中會(huì)攜帶頁(yè)面的關(guān)鍵信息，比如說(shuō)日志內(nèi)容、搭建產(chǎn)生的 json 源碼，環(huán)境信息等等。這樣就可以減少工單處理的時(shí)長(zhǎng)。

第二個(gè)用戶會(huì)遇到的問(wèn)題是？對(duì)于大多數(shù)低代碼產(chǎn)品，他們的在頁(yè)面設(shè)計(jì)時(shí)所看到的效果，和實(shí)際預(yù)覽的時(shí)候看到的效果在一些情況下是不一致的。比如說(shuō)我們?cè)谠O(shè)計(jì)這個(gè)頁(yè)面的時(shí)候，給某個(gè)組件配置了表達(dá)式，而這些表達(dá)式在畫(huà)布中是不會(huì)進(jìn)行計(jì)算的。這樣會(huì)導(dǎo)致一個(gè)問(wèn)題。設(shè)計(jì)時(shí)看到的效果和實(shí)際展示看到的效果是不一致的。

比如這里的按鈕展示的就不一樣。那么當(dāng)我們?cè)陬A(yù)覽的時(shí)候，如果效果和我們的期望的不一樣，我們就想知道

• 這個(gè)組件的配置表達(dá)式是什么？
• 這個(gè)組件展示的文案是怎么計(jì)算出來(lái)的？

之前為了解決這些問(wèn)題，用戶需要回到設(shè)計(jì)器中，找到對(duì)應(yīng)的組件，查看這個(gè)組件的配置才能解決。而對(duì)于一些復(fù)雜的配置，比如三元表達(dá)式，用戶為了找到問(wèn)題，還需要在很多地方添加 Console，查看數(shù)據(jù)源的值。因此為了幫助用戶快速的定位到單個(gè)組件配置的問(wèn)題，我們提供了組件審查功能。

它的效果是這樣的，當(dāng)切換到組件審查面板的時(shí)候，用戶可以點(diǎn)擊頁(yè)面中的元素，或者點(diǎn)擊大綱樹(shù)中對(duì)應(yīng)的組件，就可以看到這個(gè)組件的詳細(xì)信息。

比如這里有一個(gè)低代碼開(kāi)發(fā)的頁(yè)面，我們需要查看頁(yè)面中某一個(gè)按鈕的展示邏輯。

1. 我們就可以點(diǎn)擊這個(gè)按鈕，就可以看到這個(gè)組件的詳細(xì)信息
2. 首先展示的詳細(xì)信息，是這個(gè)組件根據(jù)配置計(jì)算出來(lái)的值，我們可以看到這個(gè)按鈕展示的文案來(lái)源是 content 這個(gè)參數(shù)的值。
3. 第二個(gè)展示的信息是這個(gè)組件配置的原始內(nèi)容，這里我們就可以看到 content 這個(gè)參數(shù)值實(shí)際上配置的是一個(gè)表達(dá)式，也就是 content 的值是根據(jù) state.text 的表達(dá)式計(jì)算來(lái)的。
4. 第三個(gè)我們展示的信息是這個(gè)組件可以訪問(wèn)到的上下文信息，比如 this.state 的值是多少，比如 this.utils 下有哪些函數(shù)等等。

這樣用戶就可以通過(guò)這個(gè)工具，一步步查看組件參數(shù)的配置，也可以推導(dǎo)出它的計(jì)算過(guò)程，如果不符合預(yù)期也可以快速的發(fā)現(xiàn)并知道如何解決問(wèn)題。

除了剛剛提到的這兩個(gè)工具之外，我們還提供了數(shù)據(jù)源面板和 schema 面板兩個(gè)調(diào)試工具。

• 數(shù)據(jù)源面板：數(shù)據(jù)源面板可以讓用戶查看頁(yè)面數(shù)據(jù)源的值，并且為了方便低代碼平臺(tái)的用戶對(duì)數(shù)據(jù)源進(jìn)行調(diào)試，數(shù)據(jù)源面板還支持修改數(shù)據(jù)源的值。
• schema 面板：對(duì)于低代碼平臺(tái)來(lái)說(shuō)，所有的可視化操作和配置，實(shí)際上操作的都是一個(gè) json 對(duì)象，這個(gè) json 對(duì)象我們把它叫做 schema，我們也提供了 schema 面板來(lái)查看頁(yè)面渲染時(shí)使用的 schema 源碼。

以上就是我們針對(duì)該低代碼平臺(tái)建設(shè)的低代碼調(diào)試能力。但是它只能解決一個(gè)低代碼平臺(tái)的問(wèn)題，為了幫助更多的低代碼平臺(tái)解決類似的問(wèn)題，我們還需要提供低代碼調(diào)試擴(kuò)展能力。

低代碼調(diào)試擴(kuò)展能力

在阿里，將近有200多個(gè)低代碼平臺(tái)，而剛剛我們提到的低代碼平臺(tái)只是這里面中的一個(gè)。那么其他低代碼平臺(tái)需要調(diào)試能力嗎？肯定也是需要的，不過(guò)他們需要的不只是我們之前提到的調(diào)試能力，他們還需要根據(jù)自己平臺(tái)的特點(diǎn)，來(lái)定制適合自己平臺(tái)的調(diào)試能力。

比如，

• 有的平臺(tái)的用戶是前端，就期望能通過(guò)瀏覽器插件來(lái)進(jìn)行調(diào)試，這樣更符合前端用戶開(kāi)發(fā)調(diào)試的習(xí)慣；
• 而有的平臺(tái)，提供的是表單搭建能力，比如說(shuō)宜搭。就更需要表單相關(guān)的調(diào)試功能；
• 有的平臺(tái)就想在調(diào)試能力上加一個(gè)按鈕，來(lái)幫助用戶找到答疑入口。

為了滿足不同低代碼平臺(tái)對(duì)調(diào)試能力的訴求，我們需要在低代碼調(diào)試能力的基礎(chǔ)上提供擴(kuò)展能力，讓低代碼平臺(tái)可以定制對(duì)應(yīng)的調(diào)試能力。

• 插件化：首先我們需要將調(diào)試能力進(jìn)行插件化，插件化的意思是將每一個(gè)調(diào)試能力都抽象為一個(gè)插件。這樣可以方便不同的低代碼平臺(tái)選擇不同的調(diào)試能力，并且可以對(duì)調(diào)試能力進(jìn)行插拔，平臺(tái)需要什么調(diào)試能力就可以引用對(duì)應(yīng)的插件。
• 基礎(chǔ)調(diào)試能力：在將調(diào)試能力插件化之后，我們就可以將之前建設(shè)的調(diào)試能力作為基礎(chǔ)調(diào)試能力，并且沉淀成基礎(chǔ)調(diào)試能力插件，比如日志調(diào)試能力插件、元素審查調(diào)試能力插件等等。
• 調(diào)試擴(kuò)展能力：當(dāng)基礎(chǔ)調(diào)試能力不滿足低代碼平臺(tái)的訴求時(shí)，低代碼平臺(tái)就需要利用我們提供的調(diào)試擴(kuò)展能力，來(lái)開(kāi)發(fā)自定義調(diào)試插件。
• 低代碼平臺(tái)開(kāi)發(fā)者：當(dāng)我們有了基礎(chǔ)調(diào)試能力和調(diào)試擴(kuò)展能力之后，低代碼平臺(tái)的開(kāi)發(fā)者就可以基于這兩個(gè)能力開(kāi)發(fā)平臺(tái)的調(diào)試能力了。

首先低代碼平臺(tái)開(kāi)發(fā)者可以看看現(xiàn)有的基礎(chǔ)調(diào)試能力是否適合自己的低代碼平臺(tái)，并且選擇適合自己低代碼平臺(tái)的基礎(chǔ)調(diào)試能力。

基礎(chǔ)調(diào)試能力無(wú)法滿足的部分，低代碼平臺(tái)就需要開(kāi)發(fā)對(duì)應(yīng)的調(diào)試能力插件。自定義調(diào)試插件開(kāi)發(fā)完成之后，就可以和基礎(chǔ)調(diào)試能力組合到一起。這樣，低代碼平臺(tái)就擁有了更適合自己平臺(tái)的調(diào)試能力。

比如：

• 低代碼平臺(tái) A，就選擇了元素審查的基礎(chǔ)調(diào)試能力，并且基于自己平臺(tái)的搭建特點(diǎn)，開(kāi)發(fā)了表單調(diào)試能力。
• 低代碼平臺(tái) B，就選擇的是日志的基礎(chǔ)調(diào)試能力，并開(kāi)發(fā)了圖表調(diào)試能力。

這樣不同的低代碼平臺(tái)就可以擁有更適合自己平臺(tái)的調(diào)試能力，這個(gè)就是我們最終期望實(shí)現(xiàn)的低代碼調(diào)試擴(kuò)展能力，

接下來(lái)的問(wèn)題是：我們要如何實(shí)現(xiàn)低代碼調(diào)試擴(kuò)展能力，并且它還能用于幾十、上百個(gè)低代碼平臺(tái)。

幸運(yùn)的是，在我們建設(shè)低代碼調(diào)試擴(kuò)展能力之前，阿里集團(tuán)大部分低代碼平臺(tái)都是基于低代碼引擎來(lái)建設(shè)的。也就是阿里內(nèi)部 200 個(gè)低代碼平臺(tái)中，有將近 130 個(gè)低代碼平臺(tái)是基于低代碼引擎來(lái)實(shí)現(xiàn)低代碼搭建和渲染的。

有了這個(gè)前提，我們就可以站在巨人的肩膀上，通過(guò)給低代碼引擎這個(gè)體系提供標(biāo)準(zhǔn)的低代碼調(diào)試能力，以及低代碼調(diào)試擴(kuò)展能力，來(lái)服務(wù)越來(lái)越多的低代碼平臺(tái)。

正如我們之前提到的，大多數(shù)低代碼平臺(tái)，可視化拖拽和配置實(shí)際上都是在操作一份 json 文件。低代碼引擎也不例外，并且低代碼引擎還對(duì)這個(gè) json 文件制定了一份標(biāo)準(zhǔn)協(xié)議，也就是「低代碼引擎搭建協(xié)議」。因此通過(guò)低代碼引擎建設(shè)的低代碼平臺(tái)，在可視化操作之后，都會(huì)產(chǎn)生一份符合搭建協(xié)議的 json schema。

這份 json schema 瀏覽器是無(wú)法直接進(jìn)行解析渲染的，因此還需要依托于「渲染引擎」來(lái)解析 schema，將低代碼頁(yè)面繪制到瀏覽器中。那么這個(gè)渲染引擎是不是只有一套呢？并不是。由于渲染引擎在繪制頁(yè)面的時(shí)候，還會(huì)用到大量的基礎(chǔ)組件或者業(yè)務(wù)組件，這些組件用到的技術(shù)?？赡苁遣灰粯拥模瑸榱俗尣煌夹g(shù)棧的物料都能渲染到瀏覽器中，渲染引擎也需要根據(jù)不同的技術(shù)棧實(shí)現(xiàn)多套。

因此，我們有多套渲染引擎。例如 React 渲染引擎、Rax 渲染引擎、以及未來(lái)還會(huì)有 Vue 渲染引擎等。

介紹了那么多關(guān)于渲染引擎的信息，那渲染引擎和調(diào)試能力是什么關(guān)系呢？

調(diào)試能力需要通過(guò)渲染引擎才能獲取到頁(yè)面信息。為什么這么說(shuō)呢，我們先看一下低代碼頁(yè)面繪制的過(guò)程。

1. 首先低代碼平臺(tái)通過(guò)可視化配置，會(huì)產(chǎn)生一份描述頁(yè)面的 json schema。
2. 在頁(yè)面渲染的時(shí)候，渲染引擎會(huì)根據(jù) schema 的內(nèi)容繪制頁(yè)面，并且除了 json schema 之外，渲染引擎還需要知道，json schema 中描述的組件和插件是什么樣的。所以也需要把整個(gè)頁(yè)面會(huì)用到的組件、第三方插件等信息給到渲染引擎。
3. 渲染引擎有了這些信息之后，才會(huì)在瀏覽器上繪制出來(lái)頁(yè)面。

在整個(gè)繪制過(guò)程中，瀏覽器知道 schema 的內(nèi)容嗎？以及知道每一個(gè)組件的參數(shù)值嗎？實(shí)際上，瀏覽器是不知道的，因?yàn)檫@些執(zhí)行和解析的過(guò)程都是由渲染引擎完成的。那么調(diào)試能力需要知道這些信息，就只能通過(guò)渲染引擎來(lái)獲取。

• 比如說(shuō)需要通過(guò)渲染引擎來(lái)獲取頁(yè)面的 schema
• 比如說(shuō)需要跟渲染引擎來(lái)獲取單個(gè)組件的參數(shù)值。

因此調(diào)試能力需要通過(guò)某種方式和渲染引擎進(jìn)行通信，比如通過(guò) API 來(lái)進(jìn)行通信。但是正如之前我們提到的，渲染引擎根據(jù)不同的技術(shù)棧實(shí)現(xiàn)了多套，而每一套渲染引擎提供的 API 都有可能是不一致的。因此我們不能基于渲染引擎的 API 來(lái)開(kāi)發(fā)調(diào)試能力。

這里為什么說(shuō)不能呢？想象一下，如果有這樣一個(gè)低代碼平臺(tái)，它即支持PC頁(yè)面的搭建也支持 H5 頁(yè)面的搭建，但是 PC 頁(yè)面使用的可能是 React 版本的渲染引擎，而 H5 頁(yè)面使用的是 Rax 版本的渲染引擎。那么同樣的調(diào)試能力就需要根據(jù)兩個(gè)不同版本的渲染引擎 API 來(lái)做兼容，或者說(shuō)可能需要開(kāi)發(fā)兩套。這肯定是不合理的，那調(diào)試能力和渲染引擎之間就需要一個(gè)溝通的標(biāo)準(zhǔn)。

這個(gè)通信的標(biāo)準(zhǔn)就是低代碼調(diào)試協(xié)議。它通過(guò)定義渲染引擎和低代碼調(diào)試能力之間通信的標(biāo)準(zhǔn)，來(lái)抹平不同版本渲染引擎在 API 和實(shí)現(xiàn)上的差異。比如：

• 它定義了渲染引擎如何主動(dòng)通知調(diào)試能力；
• 它也定義了調(diào)試能力如何主動(dòng)通過(guò)渲染引擎獲取到相關(guān)的信息。

這樣的好處是，

• 對(duì)于低代碼平臺(tái)的開(kāi)發(fā)者來(lái)說(shuō)，他們?cè)陂_(kāi)發(fā)低代碼調(diào)試能力的時(shí)候可以不用關(guān)注頁(yè)面用的是什么技術(shù)棧的渲染引擎。也不需要做任何兼容和適配的工作；
• 對(duì)于低代碼引擎來(lái)說(shuō)，不同技術(shù)棧得渲染引擎在實(shí)現(xiàn)了低代碼調(diào)試協(xié)議之后，就可以支持所有已經(jīng)開(kāi)發(fā)好的調(diào)試能力。

接下來(lái)讓我們看看調(diào)試協(xié)議是如何進(jìn)行定義的。

首先在定義協(xié)議之前，我們?cè)賮?lái)明確一下我們定義協(xié)議的目的是什么。它的主要的目的還是用來(lái)完成調(diào)試能力的開(kāi)發(fā)。而調(diào)試能力開(kāi)發(fā)需要的主要分為兩個(gè)方面：

1.schema 獲取和操作類型

第一個(gè)是 schema 的獲取或者修改相關(guān)的操作。比如獲取整個(gè)頁(yè)面的 schema，獲取單個(gè)組件節(jié)點(diǎn)的參數(shù)和狀態(tài)。這些操作本質(zhì)上都是在獲取或者操作 schema。

基于低代碼引擎建設(shè)的低代碼平臺(tái)，產(chǎn)生的 schema 是根據(jù)低代碼引擎搭建協(xié)議規(guī)范生成的。因此我們操作 schema 就是操作搭建協(xié)議描述的結(jié)構(gòu)。為了讓調(diào)試能力更方便的操作搭建協(xié)議，我們將搭建協(xié)議分成了三層。

• 第一層是搭建協(xié)議的頂層結(jié)構(gòu)，為了操作這一層結(jié)構(gòu)，我們?cè)谡{(diào)試協(xié)議中定義了 schema 調(diào)試域。這樣就可以通過(guò) schema 調(diào)試域來(lái)獲取整個(gè)頁(yè)面的 json schema 或者說(shuō)修改整個(gè)頁(yè)面的 json schema。
• 第二層是搭建協(xié)議中的容器結(jié)構(gòu)，容器是一類特殊的組件，在組件能力基礎(chǔ)上還增加了一些特殊能力，比如說(shuō)它有單獨(dú)的自定義方法和數(shù)據(jù)源。因此我們定義了 Container 調(diào)試域來(lái)操作容器這一層結(jié)構(gòu)。這樣我們就可以在調(diào)試能力中修改容器的數(shù)據(jù)源或者調(diào)用容器中的自定義方法了。
• 第三層就是搭建協(xié)議中的單個(gè)組件結(jié)構(gòu)，在調(diào)試中肯定需要對(duì)單個(gè)組件進(jìn)行操作，比如說(shuō)需要知道組件計(jì)算后的參數(shù)值，組件的原始配置，獲取組件的 json schema 等等。因此我們定義了 Node 調(diào)試域來(lái)操作這一層結(jié)構(gòu)。

2.輔助類型

除了獲取或者修改 schema 相關(guān)的操作之外，在調(diào)試的時(shí)候，我們還需要一些輔助類型的操作。比如說(shuō)，調(diào)試能力想打開(kāi)一個(gè)新的瀏覽器頁(yè)面，就需要在瀏覽器窗口中執(zhí)行對(duì)應(yīng)的表達(dá)式。這些需要執(zhí)行的表達(dá)式我們就用 Runtime 這個(gè)調(diào)試域來(lái)進(jìn)行通信。比如，當(dāng)我們審查元素的時(shí)候，需要頁(yè)面出現(xiàn)遮罩，來(lái)標(biāo)識(shí)用戶正在查看的組件是哪個(gè)。因此我們定義了 Overlay 調(diào)試域來(lái)進(jìn)行相關(guān)通信。

這樣我們的低代碼調(diào)試協(xié)議就定義好了。接下來(lái)我們看一下根據(jù)低代碼調(diào)試協(xié)議，我們實(shí)際上在調(diào)試過(guò)程中調(diào)試工具和渲染引擎通信的示例。

輔助類型 – Runtime 調(diào)試域

第一個(gè)例子，是一個(gè)輔助類型的域，也就是 Runtime 調(diào)試域。當(dāng)調(diào)試能力期望在新的瀏覽器窗口中打開(kāi)一個(gè)新的頁(yè)面時(shí)，就會(huì)發(fā)送一個(gè) Runtime 域的 JSON，這個(gè) JSON 中的 expression 字段就是定義了需要執(zhí)行的表達(dá)式。當(dāng)渲染引擎接收到這個(gè) JSON 之后，通過(guò)解析，就知道了它的意圖，就會(huì)執(zhí)行 JSON 中的表達(dá)式，執(zhí)行完成之后，也會(huì)發(fā)送一個(gè) JSON 通知調(diào)試面板表達(dá)式執(zhí)行完成。

schema 操作類型 – Schema 調(diào)試域

第二個(gè)例子，是關(guān)于操作低代碼引擎搭建協(xié)議頂層結(jié)構(gòu)的域，也就是 Schema 域，當(dāng) Schema 變化的時(shí)候，渲染引擎就會(huì)發(fā)送圖中的 JSON 給到調(diào)試工具，調(diào)試面板就能知道當(dāng)前頁(yè)面的 Schema 變化了，頁(yè)面渲染的內(nèi)容也就變化了，調(diào)試能力就需要執(zhí)行相關(guān)的操作，比如更新 schema 調(diào)試面板展示的內(nèi)容，更新審查面板的大綱樹(shù)等等。

低代碼調(diào)試協(xié)議目前基本上介紹的差不多了，我們?cè)倏紤]一個(gè)問(wèn)題，之前我們提到這個(gè)協(xié)議由渲染引擎來(lái)發(fā)送，但是這樣是不是合適呢？實(shí)際上是不合適的，因?yàn)閷?duì)于低代碼平臺(tái)來(lái)說(shuō)，線上環(huán)境和開(kāi)發(fā)環(huán)境中用的渲染引擎都是同一個(gè)，在線上環(huán)境有那么多冗余的代碼是有問(wèn)題的。另外這種實(shí)現(xiàn)方案也會(huì)讓渲染引擎有較大的改動(dòng)，同時(shí)也會(huì)讓使用舊版本渲染引擎的頁(yè)面無(wú)法使用調(diào)試能力。

那么由誰(shuí)來(lái)發(fā)送調(diào)試協(xié)議呢，以及它又通過(guò)什么方式來(lái)和渲染引擎進(jìn)行通信呢？

為了解決這個(gè)問(wèn)題，我們新增了一個(gè)代理人的角色，這樣：渲染引擎通知調(diào)試能力的方式就變成了，渲染引擎通過(guò)事件讓代理人知道要發(fā)送調(diào)試協(xié)議了，代理人就發(fā)送對(duì)應(yīng)的調(diào)試協(xié)議。調(diào)試工具想獲取 schema 的內(nèi)容就變成了，調(diào)試工具發(fā)送的調(diào)試協(xié)議，由代理人來(lái)接收，接收之后代理人就會(huì)調(diào)用渲染引擎的 API 來(lái)獲取 schema 的內(nèi)容。得到結(jié)果之后代理人再將結(jié)果通過(guò)調(diào)試協(xié)議發(fā)送給低代碼調(diào)試工具。

增加代理人的好處是：

• 渲染引擎只需要提供相關(guān)的 API，而不需要為了調(diào)試能力進(jìn)行大規(guī)模的改動(dòng)。
• 代理人只有在開(kāi)發(fā)低代碼平臺(tái)頁(yè)面時(shí)才存在，這樣就不會(huì)影響到我們的線上環(huán)境。

我們看一下實(shí)際通信的例子，

1. 首先在頁(yè)面初始化的時(shí)候，代理人會(huì)調(diào)用渲染引擎的 API，來(lái)注冊(cè)日志回調(diào)事件，相當(dāng)于跟渲染引擎說(shuō)，有日志了記得通知我；
2. 當(dāng)渲染引擎出現(xiàn)日志的時(shí)候，就會(huì)調(diào)用代理人注冊(cè)的回調(diào)函數(shù)，相當(dāng)于通知代理人，有日志了，日志內(nèi)容是某某某。
3. 代理人收到通知之后，就會(huì)發(fā)送對(duì)應(yīng)的調(diào)試協(xié)議，也就是圖中的 Json 對(duì)象。
4. 低代碼調(diào)試能力就會(huì)接收到對(duì)應(yīng)的協(xié)議，也就可以執(zhí)行相關(guān)的操作，這里就是將接收到的新日志展示出來(lái)。

我們已經(jīng)定義好了低代碼調(diào)試協(xié)議，也實(shí)現(xiàn)了渲染引擎和調(diào)試能力之間的通信能力。

接下來(lái)我們還需要提供一個(gè)容器來(lái)展示基礎(chǔ)插件和自定義插件。

根據(jù)展示的類型，我們將插件分為兩種：

1. Tab 類型：比如之前的日志面板。對(duì)應(yīng)圖中的黃色區(qū)域。
2. Action 類型：當(dāng)點(diǎn)擊的時(shí)候，它只會(huì)執(zhí)行一些操作，比如上傳日志，比如跳轉(zhuǎn)到答疑頁(yè)面等等。這些插件會(huì)展示在圖中的紅色區(qū)域。

用戶可以根據(jù)自己需要的調(diào)試能力來(lái)選擇開(kāi)發(fā)不同類型的插件。

我們現(xiàn)在基本上已經(jīng)實(shí)現(xiàn)基本的調(diào)試擴(kuò)展能力了，為了讓低代碼平臺(tái)可以更便捷的開(kāi)發(fā)低代碼平臺(tái)調(diào)試能力，我們還提供了調(diào)試相關(guān)研發(fā)的工具鏈，讓用戶可以初始化開(kāi)發(fā)插件，調(diào)試插件以及整合插件。除了工具鏈之外，我們還提供了更方便的 API 來(lái)操作調(diào)試協(xié)議，這樣用戶開(kāi)發(fā)調(diào)試能力的時(shí)候就不用寫(xiě) JSON 了。

這樣我們的低代碼調(diào)試擴(kuò)展能力就建設(shè)完成了。

低代碼調(diào)試能力實(shí)踐

在阿里的這款中后臺(tái)低代碼平臺(tái)中，使用調(diào)試能力的月活躍用戶有 300 人，平臺(tái)的答疑量降低了 10% 左右。

其中一些簡(jiǎn)單的答疑基本上已經(jīng)消失了，比如說(shuō)由于跨域，一些接口請(qǐng)求會(huì)出現(xiàn)錯(cuò)誤，之前也有很多同學(xué)因?yàn)檫@類問(wèn)題找到我們答疑同學(xué)，現(xiàn)在之類答疑已經(jīng)沒(méi)有了，并且由于組件表達(dá)式配置錯(cuò)誤，而導(dǎo)致的頁(yè)面報(bào)錯(cuò)，這種類型的答疑也少了很多。

此外，阿里對(duì)外的商業(yè)化低代碼平臺(tái)，釘釘宜搭，由于大多數(shù)搭建場(chǎng)景是在搭建表單頁(yè)面，他們也根據(jù)表單頁(yè)面的特點(diǎn)，擴(kuò)展了對(duì)應(yīng)的調(diào)試能力?？梢灾С植榭幢韱螖?shù)據(jù)和錯(cuò)誤請(qǐng)求。

目前低代碼調(diào)試能力還處于剛剛萌芽的階段，還需要不斷探索和建設(shè)。就像瀏覽器提供給前端研發(fā)豐富的調(diào)試能力一樣，低代碼領(lǐng)域未來(lái)還會(huì)有非常豐富的調(diào)試能力，這些調(diào)試能力可以幫助越來(lái)越多的低代碼開(kāi)發(fā)師解決低代碼搭建過(guò)程中遇到的問(wèn)題。

下一步我們還會(huì)建設(shè)更多的基礎(chǔ)調(diào)試能力：

• 比如用戶在低代碼中寫(xiě)的 JS 代碼，我們可以在調(diào)試工具中查看和調(diào)試對(duì)應(yīng)的 JS 代碼。而不是需要回到設(shè)計(jì)器中才能查看。
• 比如可以在調(diào)試工具中查看頁(yè)面的數(shù)據(jù)源請(qǐng)求信息。
• 比如可以查看頁(yè)面或者容器生命周期的執(zhí)行等等。

此外，我們還會(huì)提供更多的低代碼調(diào)試容器：

• 比如 Web 容器，適合提供給非前端研發(fā)同學(xué)來(lái)使用。
• 比如瀏覽器插件容器，適合提供給前端研發(fā)來(lái)使用，更適合前端研發(fā)同學(xué)的調(diào)試習(xí)慣。
• 比如說(shuō)客戶端調(diào)試容器，提供給一些特殊調(diào)試場(chǎng)景來(lái)使用，比如用于移動(dòng)端調(diào)試場(chǎng)景。

最后，我們也需要讓更多的渲染引擎支持低代碼調(diào)試能力，比如我們低代碼引擎中不同技術(shù)棧的渲染引擎，React 版本的渲染引擎和 Rax 版本的渲染引擎，以及未來(lái)由社區(qū)支持的 Vue 渲染引擎。