作者：行云創(chuàng)新 杜欣

在今天，“低代碼” 技術(shù)已經(jīng)很難被描述為?種新興的技術(shù)服務(wù)形式了。

“低代碼”這?概念，早在1982 年，便由 James Martin 在《?程序員的應(yīng)?程序開 發(fā)》?書中正式提出。?從 90 年代起，國外在不同的軟件開發(fā)發(fā)展階段中，都分別研究并嘗試推出了對應(yīng)的低代碼解決?案。但真正的時間拐點，要來到 2015 年前 后，隨著基礎(chǔ)技術(shù)設(shè)施的不斷演進(jìn)，低代碼相關(guān)技術(shù)逐漸露出曙光，且微軟、?歌等巨頭正式?局，低代碼賽道正式打開。

同期，國內(nèi)的低代碼?商也開始嘗試布局，2018 年左右，互聯(lián)?巨頭阿?、騰訊、百度的紛紛?局，也間接為整個?業(yè)奠定了?向。據(jù)艾瑞咨詢《2021 年低代碼?業(yè)研究 報告》中所?，截? 2020 年，中國低代碼市場共有 59 起融資事件，融資規(guī)模達(dá)億元 以上者依然有 13 起之多。?同期市場規(guī)模也逐年增? 15.9 億（2020年），據(jù)測算， 該市場規(guī)模將于 2025 年達(dá)到 131 億，未來 5 年復(fù)合增速為52.6%。

截?截稿，36 氪企服點評的低代碼開發(fā)板塊中，已錄?國內(nèi)?商/產(chǎn)品共計 109 款。 種種跡象都表明，低代碼市場，已經(jīng)逐漸??中場。

作為?種商業(yè)服務(wù)，低代碼?疑是明確的，提供完善的可視化開發(fā)界?，使?戶能夠 以?傳統(tǒng)開發(fā)的模式進(jìn)?應(yīng)?開發(fā)，從?達(dá)成低成本、?效率的應(yīng)?開發(fā)。但對于真 正的開發(fā)模式??，低代碼這?概念卻是開放的，市?上的產(chǎn)品不論從技術(shù)?案、使 ??式還是應(yīng)?場景??，都早已百花?放。

那么，什么樣的低代碼平臺才是更適合開發(fā)者的呢？我們不妨先從國內(nèi)市?上最流? 的兩種低代碼平臺形態(tài)，來聊聊當(dāng)前的低代碼平臺。

表單驅(qū)動 - 企業(yè)信息化的新中臺

?般認(rèn)為，表單驅(qū)動是作為 BPM 系統(tǒng)的延續(xù)者出現(xiàn)的，再向前溯源的話，更像是早期使? Excel 來進(jìn)?數(shù)據(jù)管理的做法：多個參與者按某種約定，通過在電腦上編輯、 傳遞?檔、信息或者任務(wù)，來實現(xiàn)指定的業(yè)務(wù)?標(biāo)。

?些從 BPM 系統(tǒng)或者電?表格類產(chǎn)品轉(zhuǎn)型?來的低代碼開發(fā)平臺，?多延續(xù)了這種表單驅(qū)動的模式。當(dāng)前市?上主要采?這種模式的低代碼平臺，常?的有：簡道云、 明道云、宜搭、氚云、得帆云等。

表單驅(qū)動型的低代碼平臺?出現(xiàn)伊始，就有著明確的客戶群體和應(yīng)?場景。如果說當(dāng)前哪種低代碼平臺最適合讓從未從事過軟件開發(fā)的?戶能夠快速的完成?款?應(yīng)?的開發(fā)，那么，?表單驅(qū)動型低代碼平臺莫屬。

表單驅(qū)動型平臺的核?編輯界?其實只有兩個，表單設(shè)計與流程設(shè)計，通過對表單的 設(shè)計完成對其抽象數(shù)據(jù)的建模，并同步綁定數(shù)據(jù)的創(chuàng)建/編輯界?，再借由流程設(shè)計， 來定義數(shù)據(jù)的流程狀態(tài)，以及不同狀態(tài)下的可操作??，字段的可?/可編輯權(quán)限等。

在業(yè)界的通?觀點中，“表單驅(qū)動”具有更低的使?門檻和技術(shù)門檻，但是應(yīng)?場景的局限性更?，通常僅?于開發(fā)簡單的數(shù)據(jù)填報系統(tǒng)，很難應(yīng)?在企業(yè)級應(yīng)?的開發(fā)過程中。

在理想化的企業(yè)內(nèi)部使?場景中，該平臺會由企業(yè)中的多個業(yè)務(wù)部門同時使?，每個部門按照??的數(shù)字化需求來設(shè)計表單，同時參與其它部門的表單填寫、流傳過程。 從?使企業(yè)中的每?個業(yè)務(wù)相關(guān)?員都可以在平臺上看到與??相關(guān)的所有表單，作為??的?作任務(wù)項或關(guān)注事項。?這，也是企業(yè)信息數(shù)字化的切實需求。

為了滿?上述場景，表單驅(qū)動型的低代碼平臺的設(shè)計思路也就變得明確了。

1. 為了能夠讓企業(yè)的任意?個員?都能夠很快上?，平臺需要最?化的降低實際使?者的學(xué)習(xí)成本。在?戶使?過程中，需要盡量取消抽象的軟件設(shè)計過程，甚?以犧牲靈活性為代價（?如界?與動態(tài)數(shù)據(jù)的綁定設(shè)計），讓?戶能夠與企業(yè)業(yè)務(wù)做直接對應(yīng)，來達(dá)成設(shè)計?的。

2. 最好是單?平臺 + 多個同構(gòu)微應(yīng)?的模式。這樣才能夠有效的聚合信息，讓企業(yè)信息流轉(zhuǎn)效率上升。單?的表單收集型服務(wù)（如：問卷星、騰訊問卷等）雖然也能解決信息的收集問題，但對于信息同步，以及流程控制就會顯得乏?，?這卻是企業(yè)提升信息流轉(zhuǎn)的綜合效率所不可或缺的能?部分。

?表單驅(qū)動的局限也同樣明顯：

1. 受限于表單與數(shù)據(jù)模型強(qiáng)綁定的設(shè)計與使??式，在實際使?過程中，往往難以設(shè)計出拓展性佳、復(fù)雜關(guān)聯(lián)的數(shù)據(jù)模型。?量的表單，???會形成?量的數(shù)據(jù)冗余（不同的表單設(shè)計背后所映射的是相同的業(yè)務(wù)數(shù)據(jù)），另????容易形成數(shù)據(jù)孤島（表單設(shè)計過程中的關(guān)聯(lián)性設(shè)計缺失，?法在其它業(yè)務(wù)中進(jìn)?數(shù)據(jù)復(fù)?）。同時，由于表單與數(shù)據(jù)模型的直接對應(yīng)，也使得對數(shù)據(jù)的展?、操作界?只能借由當(dāng)前表單執(zhí)?，難以設(shè)計復(fù)雜的數(shù)據(jù)檢索與數(shù)據(jù)交互。

2. 表單驅(qū)動型的低代碼平臺，通常只能處理數(shù)據(jù)的采集與展?，??法基于數(shù)據(jù)進(jìn)?更為智能化、?動化的衍?邏輯設(shè)計。為了彌補(bǔ)缺陷，低代碼平臺往往會增加 ?些可編程界?，以便?戶通過代碼途徑來解決上述問題。但伴隨著編碼功能的開放，平臺用戶的體驗也會開始割裂。更真實的情況是，大量對數(shù)據(jù)建模都算不上擅長的用戶，并沒有匹配的技術(shù)能力來完成代碼的編寫。

當(dāng)然，不論如何，在企業(yè)數(shù)字化場景下，表單驅(qū)動型的低代碼平臺依然能解決?常企業(yè)業(yè)務(wù)中?部分簡單的信息流轉(zhuǎn)需求。但是對于開發(fā)者??，表單驅(qū)動型低代碼平臺與開發(fā)者的?作場景卻往往是互斥的。

???，表單驅(qū)動的?標(biāo)?戶并不是開發(fā)者本?，甚?平臺本?，就是為了在企業(yè)不具備開發(fā)能?，或降低開發(fā)成本時?出現(xiàn)的。

另???，則是因為表單驅(qū)動型平臺中，應(yīng)?設(shè)計模式較傳統(tǒng)軟件開發(fā)??，進(jìn)?了?量簡化甚?是閹割，這導(dǎo)致開發(fā)者在使?表單驅(qū)動型平臺的過程中，往往有?量的軟件設(shè)計思想?法在平臺中實現(xiàn)。

??以蔽之，開發(fā)者與表單驅(qū)動，可能真的沒有什么緣分。

模型驅(qū)動 - 傳統(tǒng)軟件開發(fā)的模式再造

不同于表單驅(qū)動從早期電?表格模式的逐步進(jìn)化，模型驅(qū)動則是從傳統(tǒng)軟件開發(fā)模式中提煉和總結(jié)?來的。

模型驅(qū)動型平臺使?可視化建模技術(shù)來定義數(shù)據(jù)關(guān)系、流程邏輯和構(gòu)建?戶界?，使開發(fā)?員和業(yè)務(wù)?戶能夠快速交付應(yīng)?程序，?不需要代碼。

在當(dāng)前市場中，如：Mendix、OutSystems、活字格、ClickPass、微搭等，都屬于模型驅(qū)動的范疇。

相對于表單驅(qū)動??，模型驅(qū)動與開發(fā)者可能要親近許多。如果說表單驅(qū)動是為了讓不具備開發(fā)能?的?戶也能夠開發(fā)應(yīng)?，那么模型驅(qū)動，則是為開發(fā)者提供了另?套形不似但神似的開發(fā)?具。

模型驅(qū)動型的低代碼平臺，更像是對傳統(tǒng)軟件開發(fā)模式的業(yè)務(wù)再造，將?量原來只存在于開發(fā)者腦海中的設(shè)計模式，實際地構(gòu)建出?戶界?來進(jìn)?設(shè)計操作。同時，平臺還將開發(fā)過程中各環(huán)節(jié)的設(shè)計?作進(jìn)?了范式定義，使得各設(shè)計模塊可以更好的集成。

換個?度來說，模型驅(qū)動對開發(fā)者的軟件設(shè)計知識要求并沒有降低，?是改造了編程?式，使得以前開發(fā)者需要編寫代碼的?作，可以通過可視化界?來定義和配置，從 ?加速了應(yīng)?開發(fā)的過程，提升了整體效率。

以數(shù)據(jù)模型與?戶界?的綁定?式來舉例：

在表單驅(qū)動的設(shè)計中，?戶需要先進(jìn)?表單設(shè)計，當(dāng)表單確定后，對應(yīng)的數(shù)據(jù)模型也會被?動推斷確認(rèn)完畢。?此，表單就與數(shù)據(jù)模型完全綁定，表單的修改亦會直接影響數(shù)據(jù)模型。?數(shù)據(jù)實體也僅?持表單進(jìn)?修改。

但在模型驅(qū)動的設(shè)計中，數(shù)據(jù)建模與?戶界?設(shè)計是完全分離的。?戶可以?由的通 過單獨(dú)數(shù)據(jù)模型設(shè)計界?進(jìn)?建模，并單獨(dú)利?戶界?設(shè)計器進(jìn)?界?設(shè)計，最后通過平臺的數(shù)據(jù)綁定機(jī)制，為指定的界?綁定數(shù)據(jù)模型，以實現(xiàn)最終的數(shù)據(jù)展?。

?這種模型驅(qū)動的綁定?式，與傳統(tǒng)軟件開發(fā)中的 MVC 設(shè)計模式，其實保持了?致的：分別設(shè)計模型（Model）層，與視圖（View）層，并通過控制層（ Controller） 層來控制模型層與視圖層的綁定關(guān)系。只不過，在模型驅(qū)動的低代碼平臺，模型層、 視圖層、控制層都可以分別使?可視化界?直接進(jìn)?設(shè)計，??需編寫代碼。

不過，如果在專業(yè)開發(fā)者的眼中，這可能會有?些開倒?的嫌疑。

?論是表單驅(qū)動，還是模型驅(qū)動，希望構(gòu)建的應(yīng)?設(shè)計模式都是讓模型層與視圖層直接產(chǎn)?綁定關(guān)系。模型驅(qū)動相?于表單驅(qū)動的優(yōu)勢，也在于其?持模型的動態(tài)拼裝， 讓模型層與視圖層的綁定關(guān)系更靈活。

但在真正的企業(yè)級應(yīng)?開發(fā)中，在模型層與視圖層之間，其實還存在著?層業(yè)務(wù)層。 除了控制視圖與模型的關(guān)系，業(yè)務(wù)層最?的作?，在于單獨(dú)對業(yè)務(wù)?為進(jìn)?了定義。 既可以是由終端?戶直接與應(yīng)?交互產(chǎn)?的業(yè)務(wù)?為，也可以是由系統(tǒng)主動根據(jù)數(shù)據(jù) 模型、業(yè)務(wù)特征?動觸發(fā)的業(yè)務(wù)?為。

同時，業(yè)務(wù)層的出現(xiàn)，使得業(yè)務(wù)?為可以單獨(dú)控制不同數(shù)據(jù)的處理邏輯，?如多重判 斷、事務(wù)管理、兼容容錯等等。這也是軟件?程領(lǐng)域中對”?內(nèi)聚、低耦合“這?設(shè)計?標(biāo)的直接實踐。

最后，業(yè)務(wù)層通過對業(yè)務(wù)?為與數(shù)據(jù)操作進(jìn)?定義，可以極?的提升模塊邏輯的復(fù)? 性。?如在常?的復(fù)雜業(yè)務(wù)中，往往需要對多個數(shù)據(jù)模型同時進(jìn)?操作，如果?法單 獨(dú)設(shè)計業(yè)務(wù)層，就只能在不同的視圖位置中，重復(fù)多次的設(shè)計數(shù)據(jù)模型操作過程，? 重復(fù)設(shè)計過程中，些許的不?致，往往就容易導(dǎo)致更復(fù)雜的業(yè)務(wù)錯誤。

所以回到模型驅(qū)動的語境?，誠然數(shù)據(jù)模型與視圖的動態(tài)綁定模式，已經(jīng)像極了傳統(tǒng) 軟件開發(fā)模式，甚?在做?型應(yīng)?時，開發(fā)者已經(jīng)能夠直觀的感受到效率提升。但對 開發(fā)者??，這依然不是最終的?具。

業(yè)務(wù)層的缺失，并不只是業(yè)務(wù)?為定義的缺失。使應(yīng)?更具智能化、?動化的運(yùn)算能 ?，也會因此?處安放。?如對數(shù)據(jù)的哈希摘要算法、對?量數(shù)據(jù)的批處理算法、? 常規(guī)數(shù)據(jù)的編解碼能?、條件化定時任務(wù)甚?是?戶推薦算法、?戶畫像?成、多要 素智能推送等，在傳統(tǒng)軟件開發(fā)中雖然屢?不鮮，但在低代碼平臺中，卻?處施展， 需要另辟它徑。

當(dāng)然，隨著市場發(fā)展，相信各?低代碼?商依然會逐步拓展??平臺的能?版圖，讓 越來越多的應(yīng)?能?可以在??平臺中被開發(fā)者使?。但?少在今天，即便是模型驅(qū) 動，也還是?法完全滿?開發(fā)者的需求。

第三種可能性是什么？

雖然在國內(nèi)，低代碼平臺主要指向表單驅(qū)動與模型驅(qū)動兩?類低代碼平臺，但在海外，?及低代碼，卻是另外?番景象。

與國內(nèi)低代碼的普遍認(rèn)知不同的是，海外更推崇的模式是將低代碼能??具化，并盡可能做到領(lǐng)域?qū)伲??全能。雖然在國外也不乏有 OutSystems、Mendix 這樣的? 型低代碼平臺，但近些年更得開發(fā)者?睞的，卻是?些特定領(lǐng)域內(nèi)的低代碼/?代碼服務(wù)。

在資訊?站 nocode.tech 中所收錄的低代碼?具中，根據(jù)?具的能?范圍，將其分為如表單設(shè)計、應(yīng)?設(shè)計、市場?具、客戶?持?具、分析?具、?動化?具、數(shù)據(jù)庫?具等在內(nèi)的 37 種類型，截??前，已收錄的低代碼/?代碼?具服務(wù)超過 200 款。

在?具之上，國外也逐步誕?了圍繞低代碼?具進(jìn)?應(yīng)?開發(fā)的社區(qū)、教學(xué)乃??業(yè)。通過使?多種低代碼?具，并借由 API 進(jìn)?拼裝，使之形成完整的業(yè)務(wù)應(yīng)?，也是當(dāng)今流?的低代碼開發(fā)趨勢。有意思的是，為了提升 API 拼裝效率，市場中還同步涌現(xiàn)了?量?于拼裝 API 的低代碼?具，使整體開發(fā)效率可以進(jìn)?步的提升。

在國內(nèi)市場，也逐漸涌現(xiàn)出了類似的服務(wù)形態(tài)。如低代碼電?表格服務(wù)維格表，就將??定位為?向 API 的多維表格，?軟件集成服務(wù)集簡云，也開始嘗試提供國內(nèi)各在線服務(wù)的 API 集成能?。

相?于使?獨(dú)?的低代碼平臺，選擇集成多種低代碼?具，會極?的拓展應(yīng)?的能?半徑。在單個低代碼平臺中，其能?半徑和應(yīng)?設(shè)計界?都?度依賴于平臺本?。但選擇多個低代碼?具相互集成的?案，則可以極?的規(guī)避這個問題。

同時，使? API 的對接模式，也為業(yè)務(wù)深度提供了可靠保證。在傳統(tǒng)開發(fā)中，API 的出現(xiàn)，使能?的提供?與使??真正分離。我們既可以在業(yè)務(wù)應(yīng)?中直接調(diào)? API 實現(xiàn)能?，也可以??編寫代碼來接? API 的能?，再向業(yè)務(wù)應(yīng)?提供更合適的 API。 通過這樣的業(yè)務(wù)封裝，可以有效的保障業(yè)務(wù)的層次與隔離性。

不?如此，隨著微服務(wù)架構(gòu)的流?，API 同時也變成了企業(yè)?研應(yīng)?中的?等公?。通過 API 來封裝能?，體現(xiàn)業(yè)務(wù)，?被其他業(yè)務(wù)進(jìn)?集成，?直都是傳統(tǒng)開發(fā)中的最佳實踐之?。

所以我們不免會提出這樣的假設(shè)，當(dāng)開發(fā)者真正邁?低代碼的領(lǐng)域時，更合理的結(jié)合模式，依然是能?領(lǐng)域獨(dú)?，API 先?，集成性?于封閉性的架構(gòu)形態(tài)。

Methodot，API 先?的新?代開發(fā)平臺

為了能夠讓低代碼能?真正的提升?線開發(fā)者的?常開發(fā)效率，?云趣碼認(rèn)真的研究 了?量市?上現(xiàn)有的低代碼平臺，以及海內(nèi)外的?業(yè)趨勢。

在開發(fā)者世界中，能夠快速的補(bǔ)???的能?短板，但?能發(fā)揮??真正擅?的專業(yè)領(lǐng)域，?直都是開發(fā)者最期望出現(xiàn)的研發(fā)模式。?當(dāng)前市?上的?部分低代碼平臺， 雖然能夠達(dá)到快速完成特定?作任務(wù)的能?，但平臺本?的出現(xiàn)，卻也對開發(fā)者原本擅?的領(lǐng)域，形成了限制。

能不能有?款平臺，可以讓開發(fā)者在享受低代碼?具效率的同時，也能通過編寫代碼和能?集成來提升應(yīng)?能?的上限呢？如果有的話，那么它不應(yīng)該是?款低代碼平 臺，?是?款富含低代碼?具能?的開發(fā)平臺。

Methodot?正是這樣的?款?站式在線開發(fā)平臺，平臺本?內(nèi)置了多款低代碼開發(fā)?具，也同時具備完整的編程開發(fā)能?。

在 Methodot 中，開發(fā)者可以?由的選擇使?低代碼?式或是代碼?式來完成特定?作的開發(fā)，可以是前端界?、可以是數(shù)據(jù)建模、也可以是 API 集成。與此同時，平臺也上架了?量的開源低代碼?具套件，讓開發(fā)者按需要進(jìn)?集成。

同時，Mehtodot 還提供了微服務(wù)架構(gòu)可視化編輯器，讓服務(wù)能?真正的作為了應(yīng)?設(shè)計?程中的?級對象，?論是傳統(tǒng)開發(fā)，還是低代碼開發(fā)，是?研應(yīng)?，還是第三?服務(wù)對接，都可以快速的進(jìn)?集成，??需擔(dān)?業(yè)務(wù)系統(tǒng)的拓展性。

不僅如此，Methodot 還深度整合了云原?技術(shù)能?，通過對軟件開發(fā)模式進(jìn)?完整的再造， 集研發(fā)?具、交付引擎、運(yùn)?環(huán)境三維?體，為開發(fā)者打造出了新?代的研發(fā)空間。換句話說，在 Methodot 中，可以同時進(jìn)?代碼編寫、編譯、構(gòu)建，并直接進(jìn)?部署直?對外提供服務(wù)，?需準(zhǔn)備編碼、調(diào)試環(huán)境，更?需單獨(dú)購置服務(wù)器資源。

當(dāng)前，Methodot 已經(jīng)正式上線，以期為??開發(fā)者提供傳統(tǒng)開發(fā)與低代碼開發(fā)相融合的在線開發(fā)服務(wù)。

同時，Methodot 已同步推出了免費(fèi)版本，并保證基礎(chǔ)功能完全開放，歡迎??開發(fā)者前來試?。

云原?，低代碼，寫得少，做得快。

這就是 Methdoot，您的?站式云原?應(yīng)?在線開發(fā)平臺。

-------------------------

Methdoot，社區(qū)版免費(fèi)使用，獲取地址（www.cloudtogo.cn）