最近一段時(shí)間不少數(shù)字孿生廠商都發(fā)布了自己產(chǎn)品的迭代版本，而在這些產(chǎn)品能力中，“低代碼或者說(shuō)是零代碼”都成為了關(guān)鍵的產(chǎn)品特性。

從百度的搜索指數(shù)上來(lái)看，“低代碼”這個(gè)關(guān)鍵詞從2019年起開始逐漸熱起來(lái)，直至今天“低代碼”依然保持了很高的熱度。

Forrester在2014年首次提出了“低代碼”這個(gè)詞 ，當(dāng)時(shí)對(duì)于“低代碼”的定位則是“通過顯著減少手工代碼編碼量來(lái)加速應(yīng)用程序的交付（accelerate app delivery by dramatically reducing the amount of hand-coding required）”。

其實(shí)這句話可以做兩個(gè)層面的拆解：

第一、針對(duì)開發(fā)語(yǔ)言本身，當(dāng)前這一類編碼語(yǔ)言的開發(fā)效率低；

第二、針對(duì)工作流的，基于手工編碼的軟件交付效率低；

從開發(fā)語(yǔ)言這個(gè)層面上來(lái)說(shuō)，我們當(dāng)前使用的開發(fā)語(yǔ)言大多屬于第三代的高級(jí)變成語(yǔ)言，其中包括一些當(dāng)今最常用的語(yǔ)言，如 JavaScript、Java 和 C#，這一代開發(fā)語(yǔ)言相比于前兩代的開發(fā)語(yǔ)言的特點(diǎn)就是抽象程度更高，同時(shí)也更符合自然語(yǔ)言（大多還是英語(yǔ)），便于人類的理解，但是還是存在一定的門檻，需要經(jīng)過特定的開發(fā)培訓(xùn)之后才能成為正式的軟件開發(fā)工程師。

前兩代編程語(yǔ)言相對(duì)于第三代變成語(yǔ)言來(lái)說(shuō)更適合機(jī)器的理解，但是抽象程度更低，不太適合人類的理解，使用門檻比較高。

雖然第三代語(yǔ)言相對(duì)于前兩代已經(jīng)抽象程度更高了，但是從發(fā)展的角度來(lái)看，還是有一定的門檻，所以James Martin 于 1982 年在他的《無(wú)程序員的應(yīng)用程序開發(fā)（application development without programmers）》一書中介紹了第四代編程語(yǔ)言，他提議使用 第四代編程語(yǔ)言技術(shù)將使非程序員能夠開發(fā)軟件。第四代編程語(yǔ)言旨在通過使用聲明性語(yǔ)句和預(yù)構(gòu)建組件來(lái)提高抽象級(jí)別從而提高生產(chǎn)力和簡(jiǎn)化開發(fā)，這是在開發(fā)語(yǔ)言上的一個(gè)發(fā)展背景和趨勢(shì)。

從工作流這個(gè)層面上來(lái)說(shuō)，工作流過程或者工作流脫節(jié)都會(huì)導(dǎo)致效率過低，所以提高協(xié)同效率或者減少工作流的環(huán)節(jié)就成為了其中關(guān)鍵的環(huán)節(jié)，而這種協(xié)同或者精簡(jiǎn)的核心就是要能夠“統(tǒng)一語(yǔ)言”，以前總是說(shuō)設(shè)計(jì)不懂開發(fā)，交付不懂開發(fā)，開發(fā)成為了交互環(huán)節(jié)上最容易脫鉤的環(huán)節(jié)，如果使用的開發(fā)平臺(tái)是一種大家都可以理解的語(yǔ)言或者模式，這樣很多工作協(xié)同起來(lái)則會(huì)更輕松，對(duì)于一些輕量的應(yīng)用需求，交付人員或者設(shè)計(jì)人員可以不需要開發(fā)人員的參與直接就可以完成項(xiàng)目的交付。

有很多專業(yè)的開發(fā)人員把現(xiàn)階段宣傳的“低（零）代碼”認(rèn)為是一種“智商稅”，其核心的觀點(diǎn)則是“不存在通用的低代碼開發(fā)平臺(tái)”，現(xiàn)在看到的更多的低代碼的應(yīng)用場(chǎng)景更多是BPM中的表單定制、流程定制等；另外一類則是大數(shù)據(jù)領(lǐng)域的一些數(shù)據(jù)面板類應(yīng)用的配置，包括一些BI的工具以及類似組態(tài)這種工具，我們現(xiàn)在所說(shuō)的數(shù)字孿生低代碼平臺(tái)大多數(shù)的應(yīng)用場(chǎng)景也是聚焦在這個(gè)方面。

數(shù)字孿生領(lǐng)域?qū)τ诘痛a概念的引入，其實(shí)核心也是自頂向下的，這個(gè)頂也就是我們事先已經(jīng)定義好了一個(gè)成熟的數(shù)字孿生應(yīng)用的范式或者是模式，然后就是可以通過低代碼的方式來(lái)提供這種生產(chǎn)能力，降低應(yīng)用構(gòu)建的復(fù)雜度和成本。

而對(duì)于軟件開發(fā)人員的邏輯更多是自底向上的，比如一個(gè)專業(yè)的開發(fā)平臺(tái)應(yīng)該從數(shù)據(jù)建模、邏輯編寫、界面開發(fā)、開發(fā)調(diào)試以及應(yīng)用部署各個(gè)流程提供有效的支撐在能夠稱得上是一個(gè)開發(fā)平臺(tái)。

但是從市場(chǎng)的角度而言，低代碼的核心用戶群體就是“非專業(yè)的開發(fā)用戶”，他們可能是實(shí)施交付人員，也可能是產(chǎn)品經(jīng)理，甚至設(shè)UI設(shè)計(jì)人員，所以針對(duì)非專業(yè)開發(fā)用戶而言，“低代碼或者零代碼”進(jìn)行應(yīng)用構(gòu)建的定位是非常合適的，這也是為什么低代碼開始收到歡迎，本質(zhì)上他把應(yīng)用開發(fā)的群體放大了，對(duì)于專業(yè)開發(fā)人員的而言，最大的興趣可能就只是在如何開發(fā)出一個(gè)很好的低代碼平臺(tái)，而不是如何應(yīng)用一個(gè)低代碼平臺(tái)。

從嚴(yán)謹(jǐn)性的角度來(lái)說(shuō)，低代碼更適合做市場(chǎng)的宣傳口號(hào)，因?yàn)檫@樣更容易被理解，直接通過拖拉拽的方式就可以實(shí)現(xiàn)精美應(yīng)用裝配，顯然是一個(gè)很動(dòng)人的故事，而從產(chǎn)品邏輯上來(lái)說(shuō)，到底什么樣的低代碼平臺(tái)才是一個(gè)合格的低代碼平臺(tái)呢？

2020年Gartner 更新發(fā)布了企業(yè)級(jí)低代碼開發(fā)平臺(tái)的關(guān)鍵能力報(bào)告《Critical Capabilities for Enterprise Low-Code Application Platforms》給出了11個(gè)關(guān)鍵指標(biāo)，在這邊我們可以參考借鑒一下（參考知乎@Brian xu）：

1. Intuitive, No-Code App Development

易用性，在不寫代碼的情況下能夠完成的功能。這是低代碼開發(fā)平臺(tái)生產(chǎn)力的關(guān)鍵指標(biāo)，也是應(yīng)用開發(fā)者選擇使用低代碼的初衷。

2. Application User Experience

使用低代碼開發(fā)平臺(tái)所構(gòu)建的應(yīng)用程序的用戶體驗(yàn)，其對(duì)比的標(biāo)的就是和代碼開發(fā)的應(yīng)用進(jìn)行對(duì)比，從經(jīng)驗(yàn)來(lái)說(shuō)低代碼平臺(tái)后期遇到的比較大的麻煩就是性能的優(yōu)化，隨著頁(yè)面和邏輯的復(fù)雜度增加，同時(shí)又由于缺乏必要的代碼優(yōu)化手段，導(dǎo)致程序臃腫，用過微軟自動(dòng)生成代碼的感受會(huì)更深一些。

3. Data Model and Management

數(shù)據(jù)建模和管理能力，這個(gè)指標(biāo)就是通常所講的“模型驅(qū)動(dòng)”。任何一個(gè)應(yīng)用都是要面向一定的領(lǐng)域的，而面向領(lǐng)域的應(yīng)用搭建過程中建模則是最關(guān)鍵的內(nèi)容，對(duì)于預(yù)置組件類型的平臺(tái)核心的就是通常只能夠支持相應(yīng)領(lǐng)域的模型組件，但是很難提供細(xì)顆粒度的通用建模能力。

4. Process and Business Logic

流程應(yīng)用與業(yè)務(wù)邏輯開發(fā)能力和效率。這個(gè)能力分為兩層：第一層是指使用低代碼工具是否可以開發(fā)出復(fù)雜的工作流和業(yè)務(wù)處理邏輯；第二層則關(guān)注開發(fā)這些功能時(shí)的，低代碼工具的便利性和易用性。一般的說(shuō)，第一層決定了企業(yè)級(jí)應(yīng)用項(xiàng)目是否能夠成功交付，而第二層則影響項(xiàng)目的開發(fā)成本。不論如何，使用者都應(yīng)關(guān)注第一層。在此基礎(chǔ)上，如果項(xiàng)目以工作流為主時(shí)，第二層也應(yīng)該作為重要的評(píng)估指標(biāo)。

5. Platform Ecosystem

開發(fā)平臺(tái)的生態(tài)系統(tǒng)。低代碼開發(fā)平臺(tái)的本質(zhì)是開發(fā)工具，內(nèi)置的開箱即用的功能無(wú)法覆蓋更多應(yīng)用場(chǎng)景。此時(shí)，就需要基于該平臺(tái)的完整生態(tài)系統(tǒng)，來(lái)提供更深程度、更全面的開發(fā)賦能。很多開發(fā)平臺(tái)都在建立自己的插件機(jī)制，就是平臺(tái)生態(tài)的一個(gè)典型體現(xiàn)。

6. API and Integration

編程接口與系統(tǒng)集成能力，為了避免“數(shù)據(jù)孤島”現(xiàn)象，企業(yè)級(jí)應(yīng)用通常需要與其他系統(tǒng)進(jìn)行集成，協(xié)同增效。

7. Architecture

系統(tǒng)是否支持更先進(jìn)的架構(gòu)、清晰的分層，以對(duì)接物聯(lián)網(wǎng)IoT、RPA機(jī)器人、ML機(jī)器學(xué)習(xí)等新的技術(shù)。

8. Quality of Service

服務(wù)質(zhì)量，與上一點(diǎn)類似，服務(wù)質(zhì)量也是衡量運(yùn)行于公有云模式下低代碼開發(fā)平臺(tái)的指標(biāo)。這里的服務(wù)質(zhì)量，除了通常所說(shuō)的“無(wú)故障使用時(shí)間”外，還要考慮資源是否支持獨(dú)占模式，避免某一個(gè)應(yīng)用的高負(fù)荷，導(dǎo)致其他應(yīng)用不可用或出現(xiàn)性能劣化。

9. Persona and SDLC

用戶模型與軟件開發(fā)周期支持。軟件開發(fā)的生命周期中，除了開發(fā)和交付，還需要包含設(shè)計(jì)、反饋、測(cè)試、運(yùn)維等多個(gè)環(huán)節(jié)。

10. Governance

開發(fā)管理。企業(yè)級(jí)軟件的項(xiàng)目規(guī)模通常比較大，而且業(yè)務(wù)更關(guān)鍵，這就對(duì)開發(fā)團(tuán)隊(duì)管理提出了更高的要求?，F(xiàn)代軟件開發(fā)中主推的敏捷開發(fā)是否能在低代碼中落地，是衡量開發(fā)管理能力的重要指標(biāo)。這通常包含了代碼庫(kù)權(quán)限管理，版本權(quán)限管理，發(fā)布權(quán)限管理等一系列功能，幫助開發(fā)團(tuán)隊(duì)負(fù)責(zé)人降低軟件開發(fā)管理過程中帶來(lái)的各種人為風(fēng)險(xiǎn)。開發(fā)團(tuán)隊(duì)規(guī)模越大，越推薦開發(fā)者關(guān)注這一指標(biāo)。

11. Security and Compliance

安全與合規(guī)。低代碼開發(fā)平臺(tái)需要在部署方式、系統(tǒng)安全機(jī)制和權(quán)限管理和控制功能等層面發(fā)力，全方位賦能開發(fā)者構(gòu)建安全的，符合企業(yè)規(guī)則的企業(yè)級(jí)應(yīng)用。

另外一個(gè)需要聊的就是目前出現(xiàn)一個(gè)很重要的趨勢(shì)就是數(shù)字孿生低代碼這種應(yīng)用模式和云平臺(tái)的aPaaS層是緊密相連的，所謂的aPaaS可以理解為PaaS的一種，即“平臺(tái)應(yīng)用即服務(wù)（application Platform as a Service）”，Gartner對(duì)其所下的定義是：“這是基于PaaS（平臺(tái)即服務(wù)）的一種解決方案，支持應(yīng)用程序在云端的開發(fā)、部署和運(yùn)行，提供軟件開發(fā)中的基礎(chǔ)工具給用戶，包括數(shù)據(jù)對(duì)象、權(quán)限管理、用戶界面等?！?/p>

這種一體化或者融合趨勢(shì)背后的原因可以如下理解：

1、面向非專業(yè)用戶的流程閉環(huán)，低代碼面對(duì)的都是非專業(yè)的的開發(fā)人員，這種非專業(yè)性可以這么理解：

你是一個(gè)專業(yè)的開發(fā)，但是在數(shù)字孿生領(lǐng)域你是非專業(yè)，比如很多JAVA開發(fā)可能對(duì)于3D開發(fā)就相對(duì)比較陌生，所這種情況下，集成方更多希望你給我個(gè)鏈接我們集成一下就好了，最多API交互一下，3D相關(guān)更深入的內(nèi)容，我不想了解的很深入；

你不是一個(gè)開發(fā)人員，你不懂開發(fā)，但是最后你還是需要交付一個(gè)開發(fā)成果，這個(gè)時(shí)候應(yīng)用部署的難度就會(huì)很大，如果是基于云平臺(tái)則可以保證開發(fā)流程和運(yùn)行的流程是一體化的，而不用管下層的細(xì)節(jié)了，這樣難度會(huì)大大降低，而且也是個(gè)低代碼應(yīng)用開發(fā)的必要條件了；

2、云渲染基礎(chǔ)設(shè)施需要，數(shù)字孿生云渲染天生就是要基于云環(huán)境，所以在這中情況下這就是部署的必要條件了；

3、生態(tài)的整合，數(shù)字孿生通常是在應(yīng)用構(gòu)建的下游，所以在生態(tài)上和其他應(yīng)用是互生關(guān)系，尤其是和數(shù)據(jù)依賴比較緊，所以現(xiàn)在很多的中臺(tái)都會(huì)提供低代碼這樣的平臺(tái)用于數(shù)據(jù)的洞察分析。

從當(dāng)前的情況來(lái)看，低代碼的通用應(yīng)用構(gòu)建深度還不夠，但是從上面的理解來(lái)看，當(dāng)前模式的低代碼構(gòu)建一定是和相應(yīng)的領(lǐng)域強(qiáng)相關(guān)的，比如構(gòu)建數(shù)字孿生類型的應(yīng)用，然后通過aPaaS平臺(tái)進(jìn)行更豐富的ISV應(yīng)用整合從而覆蓋更大的業(yè)務(wù)場(chǎng)景，這可能也是以前潛在的路徑。

來(lái)源：GIS小丸子