本文是一篇立場文件，作者借由第一屆低代碼研討會的召開，討論了關(guān)于在模型驅(qū)動工程領(lǐng)域定位低代碼運(yùn)動的想法，并試圖給出了部分問題的答案。

自從低代碼（Low-code）成為新的流行術(shù)語之后，我就想知道“低代碼”運(yùn)動與我們過去所說的“模型驅(qū)動的工程/開發(fā)”相比，是否真的有什么不同。第一屆低代碼研討會（屬于2020年模型大會的一部分）是讓我花時間思考并寫作這個主題想法的一個很好的借口。

接下來你將閱讀的是我思考的結(jié)果。里面還嵌入了我準(zhǔn)備發(fā)表的論文的演講幻燈片（見底部）。兩者都包含了我在發(fā)布本文的第一版時得到的一些反饋（感謝大家給我的寶貴反饋?。?。我相信這（低代碼在模型驅(qū)動領(lǐng)域的定位）是我們作為一個社區(qū)所必須繼續(xù)討論的話題。即使我們不能達(dá)成任何共識。

免責(zé)聲明：

1. 這是一份簡短的立場文件，大家應(yīng)該據(jù)此來閱讀和解釋。

2. 這可能是有爭議的。如果你閱讀時覺得被冒犯了，就說明我的工作做得很好。我認(rèn)為，立場文件的重點(diǎn)是發(fā)表有力且大膽的聲明，以幫助展開討論。

3. 當(dāng)其中一個術(shù)語（“低代碼”）沒有被科學(xué)定義，但需要通過研究一組稱之為低代碼的工具集來進(jìn)行推斷時，很難“科學(xué)地”比較這兩個術(shù)語。

說到這里，請繼續(xù)閱讀我關(guān)于在模型驅(qū)動工程領(lǐng)域定位低代碼運(yùn)動的想法。特別是，我試圖給出這些問題的部分答案

• 在低代碼運(yùn)動的背后有什么根本的新東西嗎?

• 它與模型驅(qū)動工程或模型驅(qū)動開發(fā)等其他概念有什么關(guān)系？

• 這對建模界的研究人員來說意味著什么?

介 紹

低代碼應(yīng)用程序平臺通過大幅降低所需的手工編碼量來加速應(yīng)用程序交付（該定義來自Forrester報告[5]，被認(rèn)為是低代碼一詞的起源）。這顯然不是軟件工程界第一次試圖通過結(jié)合可視化開發(fā)技術(shù)（我們稱之為“模型”）和代碼自生成來減少手工編碼。事實(shí)上，正如GradyBooch所說，軟件工程的整個歷史都是關(guān)于提高抽象層次的。

低代碼是降低開發(fā)軟件應(yīng)用程序所需的手工編碼量的最新嘗試。這是我們從軟件工程開始之初就一直追求的目標(biāo)。

來自TWEET

低代碼可以追溯到模型驅(qū)動工程。但是模型驅(qū)動工程本身可以追溯到CASE（Computer-Aided Software Engineering，計算機(jī)輔助軟件工程）工具。早在1991年，在著名的CAiSE會議的第1版中，我們就可以找到這樣的論文：“給定最終模型，可以自生成完整的計算機(jī)化信息系統(tǒng)”[2]或“我們得出了一個可自動生成可執(zhí)行代碼的規(guī)范”[4]。

同時，低代碼在當(dāng)今商業(yè)世界中的影響也很明顯，包括了一些大膽的預(yù)測，但也包括了最近投資于低代碼工具的相關(guān)實(shí)際數(shù)據(jù)，其中一些工具的商業(yè)成功或許僅僅是因?yàn)樗凶畲蟮能浖径荚诖_保他們在提供該領(lǐng)域的某種產(chǎn)品。

低代碼vs模型驅(qū)動vs基于模型vs無代碼

對于所有的MD*概念，我們并沒有通用的定義。我自己的（非正式）定義如下：

• 模型驅(qū)動工程（Model-driven engineering，MDE）：任何一種軟件工程過程，其中模型起著基礎(chǔ)性的作用并驅(qū)動著工程任務(wù)。

• 模型驅(qū)動開發(fā)（Model-driven development，MDD）：MDE應(yīng)用于正向工程，即用于軟件開發(fā)的模型驅(qū)動。

• MDA是OMG對MDD的特定設(shè)想，因此依賴于OMG標(biāo)準(zhǔn)的使用。

• 基于模型的工程/開發(fā)：前面各個概念的軟版本。在MBE過程中，軟件模型扮演著重要的角色，盡管它們不一定是工程/開發(fā)的關(guān)鍵工件（即它們不“驅(qū)動”過程）。

能區(qū)分MBE與MDE的一個例子是開發(fā)過程，在分析階段，設(shè)計人員指定了獨(dú)立于平臺的系統(tǒng)模型，但是這些模型會直接交給程序員來手工編寫代碼（不涉及代碼自生成，也不明確定義任何特定于平臺的模型）。在這個過程中，模型仍然發(fā)揮著重要的作用，但不是開發(fā)過程的基礎(chǔ)。

基于以上定義，我認(rèn)為低代碼是模型驅(qū)動開發(fā)的同義詞。如果有什么區(qū)別的話，我們可以把低代碼看作是MDD中的一個更嚴(yán)格的視圖，其中我們僅針對某種特定類型的軟件應(yīng)用程序：數(shù)據(jù)密集型Web/移動應(yīng)用程序。

注意，術(shù)語“無代碼”有時被用作低代碼的細(xì)微變化。實(shí)際上，我們經(jīng)常會看到工具將自己定義為無代碼/低代碼工具。然而，對我來說，無代碼方法的關(guān)鍵特征是應(yīng)用程序設(shè)計人員應(yīng)該編寫零代碼來創(chuàng)建和部署應(yīng)用程序。這在很大程度上限制了使用無代碼工具的實(shí)際效果。我們基本上是在研究基于模板的框架或創(chuàng)建工作流，這些工作流將預(yù)定義的連接器與外部應(yīng)用程序混合在一起，在這些應(yīng)用程序中，設(shè)計人員最多是決定何時以及如何觸發(fā)某些操作。

比較這些不同范例的另一種方法是查看你需要編寫多少手工代碼。在MBE中，你可能需要編寫所有代碼。相反，在MDD和低代碼中，大部分代碼都應(yīng)該是自動生成的，但是你可能仍然需要定制并完成所生成的代碼（大多數(shù)MDD工具都包含某種黑盒建模原語，你可以在生成過程中編寫任何應(yīng)該添加到其中的自定義代碼）。在無代碼中，你應(yīng)該編寫零代碼。

顯然，需要進(jìn)行更多的研究來評估市場上的低代碼工具，并更好地將其描述為比這里介紹的工具更細(xì)粒度的類別。事實(shí)上，目前基本上還沒有關(guān)于低代碼運(yùn)動的研究（快速搜索只會發(fā)現(xiàn)一些關(guān)于將自己歸類為低代碼工具的論文，而不是將低代碼本身作為研究對象），我相信這個研討會將會使這一點(diǎn)開始改變。

低代碼趨勢

如圖1所示，對低編碼的興趣達(dá)到了頂峰，即使如圖2所示，這個峰值遠(yuǎn)小于對模型驅(qū)動的注意力達(dá)到頂峰時的峰值。

谷歌趨勢圖顯示了對低代碼術(shù)語的搜索興趣

但是，如果從技術(shù)上講，低代碼并沒有真正帶來什么新東西，為什么會如此流行呢？

• 首先，我認(rèn)為低代碼所傳達(dá)的信息比模型驅(qū)動/基于模型的信息要清晰得多 。模型是一個非常模糊的詞，因此模型驅(qū)動的概念比低代碼更難解釋（每個人對什么是代碼都有清晰的認(rèn)識，低代碼就變得不言而喻了）。

• 其次，我們知道建模會嚇跑開發(fā)人員。相反，低代碼聽起來更熟悉。他們已經(jīng)在做同樣的事情了（編碼），只是更少。

• 此外，低代碼的應(yīng)用場景也更加清晰。低代碼不是說你可以用MDD做任何事情（這最終會產(chǎn)生不信任），而是通過針對特定類型的應(yīng)用程序（即行業(yè)中最需要的應(yīng)用程序）來其使可信度更高。

• 低代碼也是一種典型的一次性建模方法，這意味著你擁有模型和生成的代碼，沒有復(fù)雜的細(xì)化鏈，沒有模型轉(zhuǎn)換，也沒有其他任何東西。

• 平均而言，低代碼工具比我們傳統(tǒng)的重型建模工具更好。例如，大多數(shù)都是基于Web的，并且不依賴于EMF。

總而言之，在低代碼工具中，我還沒有看到任何在模型驅(qū)動領(lǐng)域找不到的符號、概念、模型類型或生成技術(shù)。但可以肯定的是，這些相同的技術(shù)以不同的方式呈現(xiàn)、配置、調(diào)整和“銷售”，這最終會使人們對低代碼的新穎性和實(shí)用性在認(rèn)知上產(chǎn)生巨大的差異。MDE項目的成功通常更多地取決于社會和管理方面，而不是純粹的技術(shù)方面[3]。這并不是免費(fèi)的（缺乏互操作性、供應(yīng)商鎖定、昂貴的商業(yè)模式等等），但目前看來這并沒有阻止社區(qū)的發(fā)展。

低編碼是一個機(jī)會

如前所述，我不認(rèn)為MDD和低代碼趨勢之間存在根本的技術(shù)差異。事實(shí)上，我們可以應(yīng)用模型驅(qū)動工程中幾乎所有的開放性挑戰(zhàn)[1]，只需將“模型驅(qū)動”變更為“低代碼”即可免費(fèi)獲得低代碼開發(fā)的研究路線圖（例如，我們需要更好的方法將人工智能集成到低代碼工具中，或者我們應(yīng)該作為一個社區(qū)努力構(gòu)建低代碼示例的共享存儲庫用于未來研究）。

但是我不認(rèn)為這是消極的。恰恰相反。顯然，低代碼吸引了很多人的關(guān)注，包括那些從未參與過建模的人。從這個意義上說，低代碼是降低進(jìn)入建模技術(shù)領(lǐng)域的門檻。因此，對我來說，低代碼是將建模（以及我們的建模專業(yè)知識）引入新領(lǐng)域和社區(qū)的巨大機(jī)會。如果我們能通過將自己塑造成低代碼專家以獲得更多的資金/曝光/用戶/反饋，我完全贊成。這正是許多知名的所謂的低代碼公司所采用的方法（你可以隨意使用互聯(lián)網(wǎng)時光機(jī)，看看他們的網(wǎng)站在過去幾年中是如何從可視化建模、敏捷開發(fā)、CASE工具和類似關(guān)鍵字轉(zhuǎn)變?yōu)榈痛a的）。讓我們也借此機(jī)會更好地理解使類似建模技術(shù)在廣泛的軟件社區(qū)中引起共鳴的因素，并從中學(xué)習(xí)。

低代碼是一個巨大的機(jī)會，可以將建模（以及我們的建模專業(yè)知識）帶到新的領(lǐng)域和社區(qū)

來自TWEET

在我們這么做的同時，讓我們關(guān)注一下未來的市場趨勢。一些低代碼供應(yīng)商正在（再一次）改變他們的營銷工作。也許用不了多久，我們就會開始高呼：低代碼已死，多體驗(yàn)開發(fā)萬歲！

比較低代碼與模型驅(qū)動工程的幻燈片

Low-code vs Model-Driven Engineering 來自 Jordi Cabot

參考文獻(xiàn)

1. Antonio Bucchiarone、Jordi Cabot、Richard F. Paige和Alfonso Pierantonio。《模型驅(qū)動工程的重大挑戰(zhàn)：研究現(xiàn)狀分析》?！盾浖拖到y(tǒng)建?！?9，1（2020），5-13。https://doi.org/10.1007/s10270-019-00773-6

2. Jon Atle Gulla、Odd Ivar Lindland和Geir Willumsen。 1991年。《PPP：一個集成的CASE環(huán)境》。《高級信息系統(tǒng)工程》，CAiSE'91，挪威特隆赫姆，1991年5月13-15日，論文集（計算機(jī)科學(xué)講座，第498卷）。Springer（194-221）。https://doi.org/10.1007/3-540-54059-8_86

3. John Edward Hutchinson、Jon Whittle和Mark Rouncefield。2014?！豆I(yè)中模型驅(qū)動的工程實(shí)踐：導(dǎo)致成功或失敗的社會、組織和管理因素》?！犊茖W(xué)、計算機(jī)、程序》89（2014年），144–161。https://doi.org/10.1016/j.scico.2013.03.017

4. John Krogstie、Peter McBrien、Richard Owens和Anne Helga Seltveit。1991?！妒褂眠^程和基于規(guī)則的方法相結(jié)合的信息系統(tǒng)開發(fā)》?！陡呒壭畔⑾到y(tǒng)工程》，CAiSE'91，特隆赫姆，挪威，1991年5月13-15日，論文集（計算機(jī)科學(xué)課堂講稿，第498卷）。Springer，319-335。https://doi.org/10.1007/3-540-54059-8

5. Clay Richardson和John RRymer。2014《面向客戶的應(yīng)用程序的新開發(fā)平臺應(yīng)運(yùn)而生》。 Forrester：劍橋，馬薩諸塞州，美國（2014年）。

原文鏈接：

https://modeling-languages.com/low-code-vs-model-driven/

關(guān)注我并轉(zhuǎn)發(fā)此篇文章，私信我“領(lǐng)取資料”，即可免費(fèi)獲得InfoQ價值4999元迷你書，點(diǎn)擊文末「了解更多」，即可移步InfoQ官網(wǎng)，獲取最新資訊～