深入淺出丨低代碼平臺(tái)的分類與選擇之道（低代碼平臺(tái)的實(shí)現(xiàn)方式）

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

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

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

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

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

不止于應(yīng)用開發(fā)

事實(shí)上，很多用戶通過低代碼/無代碼平臺(tái)創(chuàng)建并運(yùn)行應(yīng)用程序，區(qū)別不僅僅是表面的，因?yàn)樵谶@個(gè)新興市場(chǎng)中的供應(yīng)商遵循兩種完全不同的架構(gòu)來支持開發(fā)環(huán)境中的應(yīng)用程序。

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

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

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

在翻譯模式的平臺(tái)中我們找到了22家供應(yīng)商，包括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。

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

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

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

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

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

根據(jù)平臺(tái)的具體情況，代碼直接生成的應(yīng)用比模型翻譯驅(qū)動(dòng)的模式性能更高，因?yàn)樗鼈兛梢跃幾g成可執(zhí)行代碼，其運(yùn)行速度也比翻譯引擎更快。

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

模型翻譯驅(qū)動(dòng)的優(yōu)點(diǎn)

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

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

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

在模型翻譯驅(qū)動(dòng)的平臺(tái)上運(yùn)行應(yīng)用，也可以享受云計(jì)算的各種優(yōu)勢(shì)，包括橫向擴(kuò)展、按需付費(fèi)或按使用付費(fèi)的定價(jià)模式。

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

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

在其他情況下，模型翻譯模式的平臺(tái)通常還會(huì)與其他第三方平臺(tái)結(jié)合，Agys BlueFabric在IBM BPM平臺(tái)上運(yùn)行，Citent App Builder借助Google的平臺(tái)，而ClaySys則利用Microsoft SharePoint。

業(yè)務(wù)流程背景

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

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

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

低代碼平臺(tái)的后端運(yùn)行能力

一些代碼自動(dòng)生成模式的低代碼平臺(tái)借助行業(yè)標(biāo)準(zhǔn)和開源環(huán)境來運(yùn)行，在某些情況下，這種多樣性是一個(gè)差異點(diǎn)。

比如Kony和Progress Kinvey都提供自己的后端平臺(tái)，他們的背景在于移動(dòng)后端即服務(wù)（MBaaS）市場(chǎng)，MBaaS為app提供后端執(zhí)行環(huán)境的技術(shù)。然而，Kony和Progress Kinvey都通過為前端和后端開發(fā)添加低代碼功能而超越了他們?cè)械腗BaaS服務(wù)范疇。

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

如何做出正確的選擇

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

不要因?yàn)椤澳Ｐ头g驅(qū)動(dòng)”的概念而影響決策，代碼生成模式本身也是模型驅(qū)動(dòng)的，只是通過開發(fā)人員與應(yīng)用的可視化模型交互，將其轉(zhuǎn)換為代碼。不同之處在于執(zhí)行層，因?yàn)槟Ｐ头g驅(qū)動(dòng)的平臺(tái)實(shí)際上要運(yùn)行翻譯引擎，而代碼生成模式則不需要。

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

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

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

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