低代碼:可視化邏輯編排選型

21 評論 22113 瀏覽 50 收藏 11 分鐘

編輯導(dǎo)讀:業(yè)務(wù)邏輯的代碼繁瑣且無用,只能讓程序員在做低水平的重復(fù)工作。有痛點(diǎn)就會有需求,一些低代碼平臺推出了可視化邏輯編排能力,能夠很好地解決這個(gè)問題。本文作者對此進(jìn)行了分析,希望對你有幫助。

一、業(yè)務(wù)邏輯代碼在軟件工程中的地位

在企業(yè)中開發(fā)一個(gè)業(yè)務(wù)系統(tǒng),公認(rèn)最頻繁和最無用的就是寫業(yè)務(wù)邏輯的代碼,這些代碼工作本身并不能提升程序員的綜合實(shí)力,只能讓程序員在做低水平的重復(fù)鍛煉,這里面的業(yè)務(wù)邏輯代碼可能會涉及很多很多框架、性能、新技術(shù)上的處理,但是應(yīng)用這些內(nèi)容和業(yè)務(wù)邏輯代碼本身沒有關(guān)系,程序員應(yīng)該更多地把精力放在提升自己的核心競爭力上。

那么有需求就有市場,一些服務(wù)能力也順應(yīng)而生,我們這次來認(rèn)識一下低代碼平臺中的可視化邏輯編排能力。

二、什么是可視化邏輯編排

如果把程序猿寫代碼的過程視作不可視的,那可視就是把程序猿寫代碼的過程做了一層交互設(shè),讓普羅大眾看著更容易去理解程序猿寫代碼這個(gè)過程甚至能上手操作,那可視化邏輯編排,就是在可視化的基礎(chǔ)上加入特點(diǎn)場景,比如無腦的P圖軟件就是把PS這種針對像素點(diǎn)的處理能力做了一層簡單的封裝,降低了用戶的使用門檻;低代碼平臺的可視化邏輯編排,就是把程序猿通過IDE寫代碼的過程做了一層封裝,降低用戶的使用門檻甚至提升開發(fā)效率。

三、類代碼的可視化邏輯編排

1. 微搭-事件

微搭的事件由【觸發(fā)條件】+【執(zhí)行動作】&【動作參數(shù)】組成。

業(yè)務(wù)場景舉例:當(dāng)前按鈕點(diǎn)擊后需要重定向至指定頁面。

我們可以通過平臺提供的重定向的方法,給按鈕組件配置一個(gè)觸發(fā)條件,如【tap點(diǎn)擊】,當(dāng)組件被點(diǎn)擊事件觸發(fā)后,則會重定向到我們配置的定向頁面去,即:

從下圖看到微搭的邏輯編排是以組件的動作為主體來進(jìn)行活動的,多個(gè)動作會進(jìn)行排列展示,也就意味著整個(gè)業(yè)務(wù)邏輯編排會變成一個(gè)個(gè)散點(diǎn)分布在頁面組件上,用戶如果需要知道具體的邏輯需要點(diǎn)進(jìn)去每個(gè)組件的每個(gè)動作進(jìn)行查看。

2. Ivx-事件流

Ivx的事件流由【觸發(fā)事件】+【前置條件】+【目標(biāo)對象】+【執(zhí)行動作】&【動作參數(shù)】組成。

場景舉例:每觸發(fā)一次按鈕點(diǎn)擊,則自動新增一行表單錄入來給用戶錄入,以達(dá)到添加多條記錄的效果。

Ivx的編排機(jī)制比較復(fù)雜,這里我們需要先構(gòu)建一個(gè)區(qū)塊,這個(gè)區(qū)塊包含了我們需要的按鈕與表單輸入控件,然后我們需要實(shí)現(xiàn)的效果是點(diǎn)擊按鈕自動新增對應(yīng)的表單組件來錄入多條記錄(注意這里不是表格組件新增行);Ivx這里提供的是一種按編程思維進(jìn)行的邏輯編排形式,我們需要在上面創(chuàng)建好的區(qū)塊內(nèi)創(chuàng)建好表單錄入對應(yīng)的數(shù)據(jù)源組件(二維數(shù)組組件)以及邏輯組件(for循環(huán)創(chuàng)建組件),然后通過按鈕的事件流來觸發(fā)數(shù)組的數(shù)據(jù)改變,再通過數(shù)組組件的數(shù)據(jù)變化來觸發(fā)循環(huán)創(chuàng)建行為,從而添加多行表單記錄組件。

其中按鈕的事件流我們可以看到它通過【點(diǎn)擊】事件觸發(fā)【二維數(shù)組】這個(gè)對象,讓它做【添加一行數(shù)據(jù)】的行為。

四、流程圖化的可視化邏輯編排

1. Mendix-微流

Mendix的微流采用了BPMN標(biāo)準(zhǔn)化圖形符號來進(jìn)行業(yè)務(wù)邏輯的編排,這里需要普及一下BPMN是個(gè)啥東西:BPMN – Business Process Modeling Notation,業(yè)務(wù)流程建模符號,粗暴一點(diǎn)理解,BPM要通過流程圖表達(dá),BPMN定義好了標(biāo)準(zhǔn)的圖例,用戶使用標(biāo)準(zhǔn)圖例來畫流程圖,只是這個(gè)流程圖表達(dá)了一個(gè)強(qiáng)業(yè)務(wù)語義強(qiáng)邏輯的流程。

場景舉例:在詳情頁中當(dāng)用戶輸入姓名失焦后時(shí)間字段自動獲取當(dāng)前時(shí)間。

Mendix的邏輯編排的核心思想是把控制顆粒度細(xì)化到后端實(shí)體屬性然后把設(shè)計(jì)好的微流掛載在前端頁面元素的事件上進(jìn)行觸發(fā),所以我們先進(jìn)入Mendix的微流設(shè)計(jì)器,針對我們的場景我們做了這樣的一個(gè)邏輯假設(shè),當(dāng)系統(tǒng)判斷姓名字段不是空的時(shí)候,就給時(shí)間字段賦值當(dāng)前系統(tǒng)時(shí)間;那懂流程圖的看圖應(yīng)該也能看出來這個(gè)條件判斷邏輯,再選中節(jié)點(diǎn)來看具體節(jié)點(diǎn)的邏輯,就能知道我們這個(gè)微流是怎么轉(zhuǎn)的,最后系統(tǒng)怎么執(zhí)行這個(gè)微流,就是靠頁面上的【姓名】字段的輸入框組件對應(yīng)的【on change aciton】上,當(dāng)輸入框的值變化時(shí)則會觸發(fā)對應(yīng)的微流,從而實(shí)現(xiàn)我們上述的場景。

2. 宜搭-審批流

相比起Mendix的微流,宜搭的審批流就像是微流的定制版,只用于一些審批流程的設(shè)置。

場景舉例:公司采購進(jìn)出貨商品流程,根據(jù)一定進(jìn)貨商品數(shù)量做審批。

雖說宜搭的審批流像是Mendix微流的定制版,但是用法卻大大不同,宜搭不是領(lǐng)域驅(qū)動設(shè)計(jì)導(dǎo)向,而是表單驅(qū)動設(shè)計(jì),所以它的審批流是建立在流程表單已經(jīng)設(shè)計(jì)好的基礎(chǔ)上,根據(jù)用戶設(shè)計(jì)的流程表單進(jìn)行審批流的編排;宜搭的審批流設(shè)計(jì)就是拉一堆節(jié)點(diǎn)出來做條件判斷和具體執(zhí)行,比如我設(shè)置進(jìn)貨數(shù)量大于等于200個(gè)的情況需要兩個(gè)角色審批,進(jìn)貨數(shù)量小于200個(gè)的情況只需一個(gè)角色審批,即可通過以下流程圖實(shí)現(xiàn)。

五、文字表達(dá)與圖形表達(dá)

大家看完上面兩大類的可視化編排形式,有沒有什么感受呢?如果說類代碼的可視化編排是一種文字表達(dá),流程圖話的邏輯編排是一種圖形表達(dá),那這個(gè)分析點(diǎn)就可以轉(zhuǎn)換為文字表達(dá)與圖形表達(dá)兩種表達(dá)方式的對比了。

這里不得不從文字的起源說起,象形文字,就是對原始圖形的一個(gè)符號性的描述,一開始的象形文字都和對應(yīng)的實(shí)物長得很像,往后發(fā)展才變成了我們現(xiàn)在的文字,然后我們又會用文字來描述圖形,同樣的也會用圖形的表達(dá)文字;那么圖形和文字哪個(gè)的表達(dá)力更強(qiáng)呢?其實(shí)沒有一個(gè)絕對的說法;比如古代詩人的詩詞寥寥數(shù)語,要用什么圖形才能清晰表達(dá)呢?又好像“太極”兩個(gè)字,再說一百遍都不如黑白兩儀圖形生動。

六、針對兩類邏輯編排工具進(jìn)行分析比對

那既然從原始的表達(dá)形式來討論分析不出個(gè)優(yōu)劣,那我們從應(yīng)用層面來反證:邏輯編排,都少不了節(jié)點(diǎn),那么節(jié)點(diǎn)的顆粒度大小就很影響編排的實(shí)現(xiàn)形式;

如果邏輯節(jié)點(diǎn)的抽象程度足夠高,不需要過多地去定制化邏輯節(jié)點(diǎn),那么流程圖化的邏輯編排則適用;

如果數(shù)據(jù)流線路畢竟復(fù)雜,邏輯節(jié)點(diǎn)無法通過抽象進(jìn)行復(fù)用,再應(yīng)用流程圖化的邏輯編排則會使得整個(gè)邏輯編排變得十分復(fù)雜,幾乎不可維護(hù);這時(shí)候就需要類代碼的邏輯編碼,并且邏輯節(jié)點(diǎn)的顆粒度也得足夠細(xì);

原則:流程圖編排不適合過于復(fù)雜的邏輯編排,太多復(fù)雜的邏輯需要使用類代碼的可視化編排。

七、感悟

企業(yè)在考慮應(yīng)用低代碼平臺或者自己生產(chǎn)低代碼平臺,建議尋找某些原則之后才來進(jìn)行相對應(yīng)的規(guī)劃設(shè)計(jì)與落地,上述原則不一定適用每個(gè)場景,只是希望每個(gè)低代碼領(lǐng)域的踐行者都能往前踏一步,哪怕是一小步,大家去探索不一樣的方向,給這個(gè)領(lǐng)域添燈添火!

 

本文由 @陳起gogogo 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

本文由 @陳起gogogo 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議。

該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 2024 年來看這篇文章 受益匪淺~

    來自廣東 回復(fù)
  2. 低代碼目標(biāo)客戶是產(chǎn)品經(jīng)理 還有些出路。一般業(yè)務(wù)人員不具備系統(tǒng)思維

    來自山東 回復(fù)
  3. 脫離場景談工具,都是耍流氓

    來自廣東 回復(fù)
    1. 專業(yè)了

      來自江蘇 回復(fù)
  4. mendix的microflow不是bpmn的業(yè)務(wù)流,mendix的流程編排是圖形化的開發(fā)語言,bpmn是可視化業(yè)務(wù)流程標(biāo)準(zhǔn),二者完全不同。

    來自廣東 回復(fù)
  5. 只是介紹了下編排的方式,沒有對比優(yōu)劣,如果能更多分享下就好了。
    其實(shí)在個(gè)人看來,先把無代碼平臺放一邊,對于低代碼平臺的用戶——開發(fā)人員而言,有個(gè)原則是,不改變用戶的認(rèn)知和前后端的分工。
    如果按這個(gè)原則,實(shí)際上mendix類的就是強(qiáng)行讓前端人員關(guān)心后端邏輯了,是改變了用戶的認(rèn)知,還是有上手難度的。
    個(gè)人看到目前的業(yè)界最佳實(shí)踐:
    對于后端來說,提供類似于微服務(wù)編排的可視化流程設(shè)計(jì)器,編排的顆粒度為領(lǐng)域?qū)ο蟮男袨?,可以組裝為一個(gè)業(yè)務(wù)服務(wù)
    對于前端來說,還是事件觸發(fā)寫js來的更為方便,通過事件或js來使用編排好的業(yè)務(wù)服務(wù),或者,直接使用領(lǐng)域?qū)ο蟮男袨?/p>

    來自廣東 回復(fù)
    1. 其實(shí)比對那里已經(jīng)說明了優(yōu)劣,但是優(yōu)劣也是對應(yīng)場景來說相對優(yōu)劣而已;
      然后如果把低代碼平臺的用戶定位為開發(fā)人員,那的確如你所說的,用更靠近開發(fā)人員技術(shù)實(shí)現(xiàn)的方式來實(shí)現(xiàn)(微服務(wù)和JS)更友好;
      但是我想表達(dá)的是,世界應(yīng)該向一個(gè)趨同的方式去發(fā)展,平臺只是提供能力,能力越強(qiáng)大,對人的要求越低,我就一個(gè)普通人都能來用清楚,就不需要關(guān)心是否強(qiáng)行讓前端人員關(guān)心后端邏輯這些東西,只需要關(guān)心應(yīng)用好不好用,合不合理,穩(wěn)不穩(wěn)定即可,只是目前還有局限和門檻在而已;
      如果平臺側(cè)一直局限在后端的邏輯編排應(yīng)該用微服務(wù),前端的邏輯寫JS,那么就永遠(yuǎn)就跳脫不出這個(gè)框架去尋找突破點(diǎn),當(dāng)前現(xiàn)實(shí)如此無可厚非哈哈哈哈,但是總會有人站出來的

      來自廣東 回復(fù)
    2. 同意,還是要按場景來討論。滿足toC的個(gè)人開發(fā)者進(jìn)行全棧開發(fā),和滿足2b大型軟件項(xiàng)目交付,是完全不同的解決方案。ivx其實(shí)已經(jīng)很強(qiáng)大了,號稱事件流能窮舉所有邏輯場景,其實(shí)可以看到個(gè)人開發(fā)者還是挺多的,但沒有2b公司敢拿去做項(xiàng)目交付。

      來自廣東 回復(fù)
  6. 適用簡單的業(yè)務(wù)流程

    來自福建 回復(fù)
  7. 作為一個(gè)前“低代碼”產(chǎn)品經(jīng)理,其實(shí)低代碼遠(yuǎn)沒想象中那么美好
    因?yàn)檎鎸?shí)場景的復(fù)雜化,很難用可視化的托拉拽來實(shí)現(xiàn)各種個(gè)性化的業(yè)務(wù)需求,有時(shí)候代碼中簡單的if else,卻要在流程配置中用大量的分支+分支的方式來覆蓋所有場景,而且配置人員多數(shù)為業(yè)務(wù)人員,業(yè)務(wù)并沒有那么強(qiáng)的邏輯思維去拆解想要配置的需求,上手難度極難

    來自廣東 回復(fù)
    1. 十分認(rèn)可,所以在未來也許會通過一些AI的賦能來降低這塊邏輯編排的上手門檻,通過“人機(jī)對話”來實(shí)現(xiàn)哈哈!未來可期!

      來自廣東 回復(fù)
    2. 你說到這個(gè),我在想系統(tǒng)自動補(bǔ)全邏輯是否可行

      來自廣東 回復(fù)
    3. 應(yīng)該不是說自動補(bǔ)全,我說的“人機(jī)對話”是指,人口述然后機(jī)器識別出來然后自行編排對應(yīng)的邏輯

      來自廣東 回復(fù)
    4. 贊同

      來自福建 回復(fù)
    5. 你這個(gè)不是低代碼哦,是無代碼。無代碼平臺目前最大的阻力,是業(yè)務(wù)人員沒有編程邏輯思維。。

      來自廣東 回復(fù)
    6. 低代碼也是一樣,目前對于邏輯補(bǔ)全的方案還是不太成熟

      來自廣東 回復(fù)
    7. 低代碼對于專業(yè)開發(fā)用戶而言,更傾向于coding來實(shí)現(xiàn)復(fù)雜邏輯,也許追求完美高效的邏輯補(bǔ)全方案也永遠(yuǎn)無法滿足專業(yè)開發(fā)用戶

      來自廣東 回復(fù)
    8. 對的,我贊同你的說法,這是一個(gè)悖論也困擾了我很久
      目前我的想法更偏向于小領(lǐng)域內(nèi)的低代碼/無代碼,比如表格、表單、審批之類的。
      用戶不是希望沒有程序員就可以搭建一個(gè)系統(tǒng),而是可以自己針對小文案或者小流程進(jìn)行小修小改
      或者可以有一套現(xiàn)成的模板,來根據(jù)自己的需要進(jìn)行小修小改(類似于有贊、shopify)

      來自廣東 回復(fù)
    9. 贊同~!

      來自廣東 回復(fù)
  8. 挺好的,感覺比較容易上手,還很方便,對與對編程要求不高的工種來說是一個(gè)利器。

    來自廣東 回復(fù)
    1. 還是要辯證地去看,真實(shí)落地的時(shí)候,不一定比寫代碼容易,希望有意向的企業(yè)要慎重設(shè)計(jì)和應(yīng)用

      來自廣東 回復(fù)