低代碼開發(fā)行業(yè)的創(chuàng)新正在爆炸式增長，并為其使用者帶來更大的價值，但這也增加了行業(yè)分析師的困惑。

Gartner一直堅持將低代碼詮釋為 “高生產(chǎn)力應用平臺即服務”的分類，對應的HPaPaaS縮寫更不容易被行業(yè)所理解。

而Forrester則為市場帶來了更加清晰的觀點，低代碼開發(fā)的概念自Forrester提出后，業(yè)界對“低代碼”、“無代碼”、“移動開發(fā)”等內容更不容易被混淆。

我自己曾多次為福布斯寫過關于低代碼或無代碼的內容，我曾指出低代碼和無代碼的區(qū)別，更多是由專業(yè)開發(fā)者還是平民開發(fā)者來創(chuàng)建應用程序，而并非是對于編寫代碼上的差別。

隨著低代碼/無代碼平臺更加先進與通用性，低代碼與無代碼開發(fā)的優(yōu)勢與區(qū)別變得難以分辨；但是，有一個更重要的區(qū)別變得越來越明顯，而主流分析公司則忽略了這一點。

不止于應用開發(fā)

事實上，很多用戶通過低代碼/無代碼平臺創(chuàng)建并運行應用程序，區(qū)別不僅僅是表面的，因為在這個新興市場中的供應商遵循兩種完全不同的架構來支持開發(fā)環(huán)境中的應用程序。

首先，有些供應商采用代碼生成方法。這些供應商提供了一個可視化的應用程序開發(fā)環(huán)境，簡化了應用程序的創(chuàng)建，一旦完成，平臺就會生成可執(zhí)行代碼。這些代碼可能是可編輯的源代碼，或者在某些情況下，是在Java虛擬機（JVM）上或在Microsoft公共語言運行（CLR）環(huán)境中運行的字節(jié)碼。

目前這種自動生成代碼的模式大致有12個供應商，包括：OutSystems、APICloud、Alpha、AppGyver、Graphite GTC、Kony、Kuika、Lansa、OrangeGrid、Progress Kinvey、Vantiq和Zuznow。

在低代碼賽道的競爭中，另一個陣營則是采用將模型進行翻譯的模式。在這種情況下，通過可視化的應用創(chuàng)建環(huán)境，生成app的特定中間域形態(tài)，平臺在運行時直接翻譯、執(zhí)行為可編輯的代碼。

在翻譯模式的平臺中我們找到了22家供應商，包括Mendix、AgilePoint、Agiloft、Agys BlueFabric、Appian、AppSheet、Betty Blocks、Bizagi、BP Logix、Breakthrough Technologies Loco、Caspio、Citent App Builder、ClaySys、Apple FileMaker、Kintone、Metavine、QuickBase、Salesforce Lightning Platform、ServiceNow、WaveMaker和Zudy。

這兩種模式其實不分上下，每個架構都有各自的優(yōu)缺點。因此，從采購方的角度來看，了解每種方法如何解決自身的需求非常重要。

代碼生成的優(yōu)勢

“代碼生成”讓我們聯(lián)想到20世紀70到80年代的計算機輔助軟件工程（CASE）工具，這些工具生成的低質量代碼總是需要開發(fā)人員再去修改和完善的。

相比之下，今天的技術很少再需要人工編輯的方式生成代碼，需要手動進行的編碼都在可視化環(huán)境中實現(xiàn)了，平臺只需將其合并到自動生成的代碼中。

代碼自動生成方式的優(yōu)點在于它創(chuàng)建的應用程序可以獨立于平臺運行。因此，代碼生成對于創(chuàng)建原生App或可在斷網(wǎng)情況下運行的App是必要的。

根據(jù)平臺的具體情況，代碼直接生成的應用比模型翻譯驅動的模式性能更高，因為它們可以編譯成可執(zhí)行代碼，其運行速度也比翻譯引擎更快。

代碼生成還讓客戶可以放心，即使平臺供應商倒閉，他們創(chuàng)建的所有應用程序也將繼續(xù)運行；在平臺提供可編輯源碼的典型情況下，使用者甚至可以在沒有平臺供應商參與的情況下更新或修改應用程序。

模型翻譯驅動的優(yōu)點

盡管少數(shù)供應商也提供私有云和本地部署的方案，但模型翻譯驅動的平臺主要在公有云環(huán)境下運行。因此，應用程序可以在開發(fā)人員拼裝部分功能后立即運行，從而簡化并加快開發(fā)、測試以及使用者的交互。

這些平臺還提供了一些 “future-proofing”能力，即為若低代碼平臺發(fā)生更新、應用安全補丁，而在平臺所開發(fā)的應用仍可正常運行。

相反，對于代碼自動生成的模式，任何此類補丁都需要使用者重新創(chuàng)建和重新部署應用程序的每個實例（諸如OutSystems代碼生成模式的成熟平臺，雖提供了“一鍵式”的部署功能來簡化這一流程，但仍不可避免）。

在模型翻譯驅動的平臺上運行應用，也可以享受云計算的各種優(yōu)勢，包括橫向擴展、按需付費或按使用付費的定價模式。

雖然模型翻譯驅動無法創(chuàng)建獨立的原生app，但這樣的平臺通常更適合實現(xiàn)在移動設備上運行基于瀏覽器的web app。

對于像Salesforce和ServiceNow這樣的供應商，提供的平臺遠遠超出了通過低代碼接口創(chuàng)建應用程序的能力。，因此，客戶可以充分利用這些平臺實現(xiàn)更廣泛的需求。

在其他情況下，模型翻譯模式的平臺通常還會與其他第三方平臺結合，Agys BlueFabric在IBM BPM平臺上運行，Citent App Builder借助Google的平臺，而ClaySys則利用Microsoft SharePoint。

業(yè)務流程背景

低代碼市場的快速成長，一定程度上要歸功于成熟的業(yè)務流程管理的（BPM）背景，像Appian和BP Logix這樣的低代碼開發(fā)平臺其前身均是BPM供應商，而Pegasystems等一些BPM供應商將他們的低代碼視為其平臺的一項能力。

追溯這些低代碼開發(fā)平臺的歷史，他們的底層技術強調業(yè)務邏輯的設計、協(xié)調以及運行時環(huán)境中的集成能力，這是只有執(zhí)行平臺（而不是開發(fā)平臺）才能提供的功能。

了解這些供應商的歷史背景非常重要，那些沒有BPM歷史的公司，其產(chǎn)品發(fā)展方向會更專注于基于表單或業(yè)務層面的交互，而不是工作流程。

低代碼平臺的后端運行能力

一些代碼自動生成模式的低代碼平臺借助行業(yè)標準和開源環(huán)境來運行，在某些情況下，這種多樣性是一個差異點。

比如Kony和Progress Kinvey都提供自己的后端平臺，他們的背景在于移動后端即服務（MBaaS）市場，MBaaS為app提供后端執(zhí)行環(huán)境的技術。然而，Kony和Progress Kinvey都通過為前端和后端開發(fā)添加低代碼功能而超越了他們原有的MBaaS服務范疇。

AppGyver和AgilePoint也是提供前端和后端開發(fā)的低代碼/無代碼平臺，AppGyver采用代碼生成的方式，而AgilePoint則是模型翻譯驅動的前后端開發(fā)平臺?？紤]到企業(yè)后端的復雜性，低代碼平臺構建后端服務能力并不容易，這可能包括傳統(tǒng)服務器、基于VM運行以及在Kubernetes和Docker上運行的基于云的PaaS或容器環(huán)境。

如何做出正確的選擇

代碼生成和模型翻譯驅動模式的區(qū)別很大，但基于不同企業(yè)IT環(huán)境的特性，還需要綜合各種內、外部需求進行決策。

不要因為“模型翻譯驅動”的概念而影響決策，代碼生成模式本身也是模型驅動的，只是通過開發(fā)人員與應用的可視化模型交互，將其轉換為代碼。不同之處在于執(zhí)行層，因為模型翻譯驅動的平臺實際上要運行翻譯引擎，而代碼生成模式則不需要。

此外，選擇低代碼開發(fā)平臺時，還必須考慮應用創(chuàng)建者（專業(yè)開發(fā)者還是平民開發(fā)者）的主要角色、所需應用程序的類型（以數(shù)據(jù)為中心還是以流程為中心）以及所得應用程序的復雜性（簡單易用的模板還是復雜且完全自定義的產(chǎn)品）。

除了以上那些因素，在執(zhí)行環(huán)境中兩種模式同樣各具優(yōu)勢；基于云端的模型翻譯驅動模式兼具更好的銜接與切換能力，而代碼生成方式的靈活性和獨立性也同樣顯著。

不要被HPaPaaS的概念所誤導，如今所有企業(yè)都在追求更高的生產(chǎn)力，其與aPaaS的區(qū)別并不明朗，有些代碼生成模式的平臺提供公有云的開發(fā)環(huán)境，而有些模型翻譯驅動的平臺則可以提供私有化部署。

無論基于哪種模式，關注這些低代碼平臺是否能真正解決企業(yè)的自身的需求，才是最佳的選擇。