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

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

Forrester在2014年首次提出了“低代碼”這個詞 ，當時對于“低代碼”的定位則是“通過顯著減少手工代碼編碼量來加速應用程序的交付（accelerate app delivery by dramatically reducing the amount of hand-coding required）”。

其實這句話可以做兩個層面的拆解：

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

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

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

前兩代編程語言相對于第三代變成語言來說更適合機器的理解，但是抽象程度更低，不太適合人類的理解，使用門檻比較高。

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

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

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

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

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

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

從嚴謹性的角度來說，低代碼更適合做市場的宣傳口號，因為這樣更容易被理解，直接通過拖拉拽的方式就可以實現(xiàn)精美應用裝配，顯然是一個很動人的故事，而從產(chǎn)品邏輯上來說，到底什么樣的低代碼平臺才是一個合格的低代碼平臺呢？

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

1. Intuitive, No-Code App Development

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

2. Application User Experience

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

3. Data Model and Management

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

4. Process and Business Logic

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

5. Platform Ecosystem

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

6. API and Integration

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

7. Architecture

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

8. Quality of Service

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

9. Persona and SDLC

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

10. Governance

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

11. Security and Compliance

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

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

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

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

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

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

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

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

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

來源：GIS小丸子