起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標(biāo)識低代碼：可視化邏輯編排選型
編輯導(dǎo)讀：業(yè)務(wù)邏輯的代碼繁瑣且無用，只能讓程序員在做低水平的重復(fù)工作。有痛點就會有需求，一些低代碼平臺推出了可視化邏輯編排能力，能夠很好地解決這個問題。本文作者對此進行了分析，希望對你有幫助。
一、業(yè)務(wù)邏輯代碼在軟件工程中的地位
在企業(yè)中開發(fā)一個業(yè)務(wù)系統(tǒng)，公認最頻繁和最無用的就是寫業(yè)務(wù)邏輯的代碼，這些代碼工作本身并不能提升程序員的綜合實力，只能讓程序員在做低水平的重復(fù)鍛煉，這里面的業(yè)務(wù)邏輯代碼可能會涉及很多很多框架、性能、新技術(shù)上的處理，但是應(yīng)用這些內(nèi)容和業(yè)務(wù)邏輯代碼本身沒有關(guān)系，程序員應(yīng)該更多地把精力放在提升自己的核心競爭力上。
那么有需求就有市場，一些服務(wù)能力也順應(yīng)而生，我們這次來認識一下低代碼平臺中的可視化邏輯編排能力。
二、什么是可視化邏輯編排
如果把程序猿寫代碼的過程視作不可視的，那可視就是把程序猿寫代碼的過程做了一層交互設(shè)，讓普羅大眾看著更容易去理解程序猿寫代碼這個過程甚至能上手操作，那可視化邏輯編排，就是在可視化的基礎(chǔ)上加入特點場景，比如無腦的P圖軟件就是把PS這種針對像素點的處理能力做了一層簡單的封裝，降低了用戶的使用門檻；低代碼平臺的可視化邏輯編排，就是把程序猿通過IDE寫代碼的過程做了一層封裝，降低用戶的使用門檻甚至提升開發(fā)效率。
三、類代碼的可視化邏輯編排
1. 微搭-事件
微搭的事件由【觸發(fā)條件】+【執(zhí)行動作】&【動作參數(shù)】組成。
業(yè)務(wù)場景舉例：當(dāng)前按鈕點擊后需要重定向至指定頁面。
我們可以通過平臺提供的重定向的方法，給按鈕組件配置一個觸發(fā)條件，如【tap點擊】，當(dāng)組件被點擊事件觸發(fā)后，則會重定向到我們配置的定向頁面去，即：
從下圖看到微搭的邏輯編排是以組件的動作為主體來進行活動的，多個動作會進行排列展示，也就意味著整個業(yè)務(wù)邏輯編排會變成一個個散點分布在頁面組件上，用戶如果需要知道具體的邏輯需要點進去每個組件的每個動作進行查看。
2. Ivx-事件流
Ivx的事件流由【觸發(fā)事件】+【前置條件】+【目標(biāo)對象】+【執(zhí)行動作】&【動作參數(shù)】組成。
場景舉例：每觸發(fā)一次按鈕點擊，則自動新增一行表單錄入來給用戶錄入，以達到添加多條記錄的效果。
Ivx的編排機制比較復(fù)雜，這里我們需要先構(gòu)建一個區(qū)塊，這個區(qū)塊包含了我們需要的按鈕與表單輸入控件，然后我們需要實現(xiàn)的效果是點擊按鈕自動新增對應(yīng)的表單組件來錄入多條記錄（注意這里不是表格組件新增行）；Ivx這里提供的是一種按編程思維進行的邏輯編排形式，我們需要在上面創(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)建行為，從而添加多行表單記錄組件。
其中按鈕的事件流我們可以看到它通過【點擊】事件觸發(fā)【二維數(shù)組】這個對象，讓它做【添加一行數(shù)據(jù)】的行為。
四、流程圖化的可視化邏輯編排
1. Mendix-微流
Mendix的微流采用了BPMN標(biāo)準(zhǔn)化圖形符號來進行業(yè)務(wù)邏輯的編排，這里需要普及一下BPMN是個啥東西：BPMN – Business Process Modeling Notation，業(yè)務(wù)流程建模符號，粗暴一點理解，BPM要通過流程圖表達，BPMN定義好了標(biāo)準(zhǔn)的圖例，用戶使用標(biāo)準(zhǔn)圖例來畫流程圖，只是這個流程圖表達了一個強業(yè)務(wù)語義強邏輯的流程。
場景舉例：在詳情頁中當(dāng)用戶輸入姓名失焦后時間字段自動獲取當(dāng)前時間。
Mendix的邏輯編排的核心思想是把控制顆粒度細化到后端實體屬性然后把設(shè)計好的微流掛載在前端頁面元素的事件上進行觸發(fā)，所以我們先進入Mendix的微流設(shè)計器，針對我們的場景我們做了這樣的一個邏輯假設(shè)，當(dāng)系統(tǒng)判斷姓名字段不是空的時候，就給時間字段賦值當(dāng)前系統(tǒng)時間；那懂流程圖的看圖應(yīng)該也能看出來這個條件判斷邏輯，再選中節(jié)點來看具體節(jié)點的邏輯，就能知道我們這個微流是怎么轉(zhuǎn)的，最后系統(tǒng)怎么執(zhí)行這個微流，就是靠頁面上的【姓名】字段的輸入框組件對應(yīng)的【on change aciton】上，當(dāng)輸入框的值變化時則會觸發(fā)對應(yīng)的微流，從而實現(xiàn)我們上述的場景。
2. 宜搭-審批流
相比起Mendix的微流，宜搭的審批流就像是微流的定制版，只用于一些審批流程的設(shè)置。
場景舉例：公司采購進出貨商品流程，根據(jù)一定進貨商品數(shù)量做審批。
雖說宜搭的審批流像是Mendix微流的定制版，但是用法卻大大不同，宜搭不是領(lǐng)域驅(qū)動設(shè)計導(dǎo)向，而是表單驅(qū)動設(shè)計，所以它的審批流是建立在流程表單已經(jīng)設(shè)計好的基礎(chǔ)上，根據(jù)用戶設(shè)計的流程表單進行審批流的編排；宜搭的審批流設(shè)計就是拉一堆節(jié)點出來做條件判斷和具體執(zhí)行，比如我設(shè)置進貨數(shù)量大于等于200個的情況需要兩個角色審批，進貨數(shù)量小于200個的情況只需一個角色審批，即可通過以下流程圖實現(xiàn)。
五、文字表達與圖形表達
大家看完上面兩大類的可視化編排形式，有沒有什么感受呢？如果說類代碼的可視化編排是一種文字表達，流程圖話的邏輯編排是一種圖形表達，那這個分析點就可以轉(zhuǎn)換為文字表達與圖形表達兩種表達方式的對比了。
這里不得不從文字的起源說起，象形文字，就是對原始圖形的一個符號性的描述，一開始的象形文字都和對應(yīng)的實物長得很像，往后發(fā)展才變成了我們現(xiàn)在的文字，然后我們又會用文字來描述圖形，同樣的也會用圖形的表達文字；那么圖形和文字哪個的表達力更強呢？其實沒有一個絕對的說法；比如古代詩人的詩詞寥寥數(shù)語，要用什么圖形才能清晰表達呢？又好像“太極”兩個字，再說一百遍都不如黑白兩儀圖形生動。
六、針對兩類邏輯編排工具進行分析比對
那既然從原始的表達形式來討論分析不出個優(yōu)劣，那我們從應(yīng)用層面來反證：邏輯編排，都少不了節(jié)點，那么節(jié)點的顆粒度大小就很影響編排的實現(xiàn)形式；
如果邏輯節(jié)點的抽象程度足夠高，不需要過多地去定制化邏輯節(jié)點，那么流程圖化的邏輯編排則適用；
如果數(shù)據(jù)流線路畢竟復(fù)雜，邏輯節(jié)點無法通過抽象進行復(fù)用，再應(yīng)用流程圖化的邏輯編排則會使得整個邏輯編排變得十分復(fù)雜，幾乎不可維護；這時候就需要類代碼的邏輯編碼，并且邏輯節(jié)點的顆粒度也得足夠細；
原則：流程圖編排不適合過于復(fù)雜的邏輯編排，太多復(fù)雜的邏輯需要使用類代碼的可視化編排。
七、感悟
企業(yè)在考慮應(yīng)用低代碼平臺或者自己生產(chǎn)低代碼平臺，建議尋找某些原則之后才來進行相對應(yīng)的規(guī)劃設(shè)計與落地，上述原則不一定適用每個場景，只是希望每個低代碼領(lǐng)域的踐行者都能往前踏一步，哪怕是一小步，大家去探索不一樣的方向，給這個領(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é)議。
該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
2024 年來看這篇文章 受益匪淺～
低代碼目標(biāo)客戶是產(chǎn)品經(jīng)理 還有些出路。一般業(yè)務(wù)人員不具備系統(tǒng)思維
脫離場景談工具，都是耍流氓
專業(yè)了
mendix的microflow不是bpmn的業(yè)務(wù)流，mendix的流程編排是圖形化的開發(fā)語言，bpmn是可視化業(yè)務(wù)流程標(biāo)準(zhǔn)，二者完全不同。
只是介紹了下編排的方式，沒有對比優(yōu)劣，如果能更多分享下就好了。
其實在個人看來，先把無代碼平臺放一邊，對于低代碼平臺的用戶——開發(fā)人員而言，有個原則是，不改變用戶的認知和前后端的分工。
如果按這個原則，實際上mendix類的就是強行讓前端人員關(guān)心后端邏輯了，是改變了用戶的認知，還是有上手難度的。
個人看到目前的業(yè)界最佳實踐：
對于后端來說，提供類似于微服務(wù)編排的可視化流程設(shè)計器，編排的顆粒度為領(lǐng)域?qū)ο蟮男袨?，可以組裝為一個業(yè)務(wù)服務(wù)
對于前端來說，還是事件觸發(fā)寫js來的更為方便，通過事件或js來使用編排好的業(yè)務(wù)服務(wù)，或者，直接使用領(lǐng)域?qū)ο蟮男袨?/p>
其實比對那里已經(jīng)說明了優(yōu)劣，但是優(yōu)劣也是對應(yīng)場景來說相對優(yōu)劣而已；
然后如果把低代碼平臺的用戶定位為開發(fā)人員，那的確如你所說的，用更靠近開發(fā)人員技術(shù)實現(xiàn)的方式來實現(xiàn)（微服務(wù)和JS）更友好；
但是我想表達的是，世界應(yīng)該向一個趨同的方式去發(fā)展，平臺只是提供能力，能力越強大，對人的要求越低，我就一個普通人都能來用清楚，就不需要關(guān)心是否強行讓前端人員關(guān)心后端邏輯這些東西，只需要關(guān)心應(yīng)用好不好用，合不合理，穩(wěn)不穩(wěn)定即可，只是目前還有局限和門檻在而已；
如果平臺側(cè)一直局限在后端的邏輯編排應(yīng)該用微服務(wù)，前端的邏輯寫JS，那么就永遠就跳脫不出這個框架去尋找突破點，當(dāng)前現(xiàn)實如此無可厚非哈哈哈哈，但是總會有人站出來的
同意，還是要按場景來討論。滿足toC的個人開發(fā)者進行全棧開發(fā)，和滿足2b大型軟件項目交付，是完全不同的解決方案。ivx其實已經(jīng)很強大了，號稱事件流能窮舉所有邏輯場景，其實可以看到個人開發(fā)者還是挺多的，但沒有2b公司敢拿去做項目交付。
適用簡單的業(yè)務(wù)流程
作為一個前“低代碼”產(chǎn)品經(jīng)理，其實低代碼遠沒想象中那么美好
因為真實場景的復(fù)雜化，很難用可視化的托拉拽來實現(xiàn)各種個性化的業(yè)務(wù)需求，有時候代碼中簡單的if else，卻要在流程配置中用大量的分支+分支的方式來覆蓋所有場景，而且配置人員多數(shù)為業(yè)務(wù)人員，業(yè)務(wù)并沒有那么強的邏輯思維去拆解想要配置的需求，上手難度極難
十分認可，所以在未來也許會通過一些AI的賦能來降低這塊邏輯編排的上手門檻，通過“人機對話”來實現(xiàn)哈哈！未來可期！
你說到這個，我在想系統(tǒng)自動補全邏輯是否可行
應(yīng)該不是說自動補全，我說的“人機對話”是指，人口述然后機器識別出來然后自行編排對應(yīng)的邏輯
贊同
你這個不是低代碼哦，是無代碼。無代碼平臺目前最大的阻力，是業(yè)務(wù)人員沒有編程邏輯思維。。
低代碼也是一樣，目前對于邏輯補全的方案還是不太成熟
低代碼對于專業(yè)開發(fā)用戶而言，更傾向于coding來實現(xiàn)復(fù)雜邏輯，也許追求完美高效的邏輯補全方案也永遠無法滿足專業(yè)開發(fā)用戶
對的，我贊同你的說法，這是一個悖論也困擾了我很久
目前我的想法更偏向于小領(lǐng)域內(nèi)的低代碼/無代碼，比如表格、表單、審批之類的。
用戶不是希望沒有程序員就可以搭建一個系統(tǒng)，而是可以自己針對小文案或者小流程進行小修小改
或者可以有一套現(xiàn)成的模板，來根據(jù)自己的需要進行小修小改（類似于有贊、shopify）
贊同~！
挺好的，感覺比較容易上手，還很方便，對與對編程要求不高的工種來說是一個利器。
還是要辯證地去看，真實落地的時候，不一定比寫代碼容易，希望有意向的企業(yè)要慎重設(shè)計和應(yīng)用