雷鋒網(wǎng)按：如今，市面上有關(guān)低代碼的功能或產(chǎn)品平臺十分繁雜，盡管說長遠(yuǎn)看對企業(yè)IT效率提升存在一定的優(yōu)勢性，但不同產(chǎn)品功能的差異性很大。正如任何一家廠商都在吹捧表示自家的產(chǎn)品具備與眾不同之處，選型時我們更需要花費(fèi)一定時間研究其中奧妙。

微服務(wù)、客開、創(chuàng)新的客戶體驗(yàn)、企業(yè)工作流以及部署專有數(shù)據(jù)庫等等，通常對企業(yè)降本增效有一定成效。但在有些情況下，業(yè)務(wù)和IT團(tuán)隊(duì)也會考慮使用無代碼和低代碼平臺來加速開發(fā)，提供開箱即用的技術(shù)最佳實(shí)踐，簡化開發(fā)流程并持續(xù)提供新功能。

低代碼平臺有以下這么幾類：一是用于快速開發(fā)Web和移動端用戶界面及工作負(fù)載的工具；二是數(shù)據(jù)可視化、數(shù)據(jù)集成和數(shù)據(jù)準(zhǔn)備的工具；三是支撐一些新興的應(yīng)用如機(jī)器學(xué)習(xí)、物聯(lián)網(wǎng)和IT自動化。

文本將重點(diǎn)介紹實(shí)現(xiàn)應(yīng)用開發(fā)、支持和增強(qiáng)的低代碼開發(fā)平臺。

1、識別和評估多個用例

低代碼有助于企業(yè)組織加速應(yīng)用開發(fā)，并讓個性化需求的滿足變得更加容易，但這需要針對客戶想要的最終用戶體驗(yàn)、數(shù)據(jù)準(zhǔn)備、工作負(fù)載功能等因素對應(yīng)用開發(fā)進(jìn)行評估。

在研究和測試低代碼平臺時，必須考慮多個應(yīng)用開發(fā)團(tuán)隊(duì)的需求和用例，這點(diǎn)非常重要。因?yàn)橛锌赡軙l(fā)現(xiàn)平臺無法執(zhí)行或無法輕松執(zhí)行的操作，這就需要事先了解其優(yōu)缺點(diǎn)及各項(xiàng)能力。

低代碼平臺應(yīng)有助于您的組織加速應(yīng)用程序開發(fā)，并使其更易于支持增強(qiáng)功能。但這需要針對您想要的最終用戶體驗(yàn)，數(shù)據(jù)要求，工作流功能和其他因素的應(yīng)用程序類型進(jìn)行評估。

在研究和測試低代碼平臺時，必須考慮多個應(yīng)用程序開發(fā)人員的需求和用例，這一點(diǎn)很重要。最重要的是，發(fā)現(xiàn)平臺無法執(zhí)行或無法輕松執(zhí)行的操作，并了解其范圍，優(yōu)點(diǎn)和缺點(diǎn)。選擇低代碼方法是因?yàn)樗m用于一個用例，但不能保證它是滿足持續(xù)需求的最佳標(biāo)準(zhǔn)。

2、明確應(yīng)用開發(fā)的負(fù)責(zé)人

有一些平臺本身就需要低代碼，這意味著開發(fā)應(yīng)用程序可能需要一些編程技能。而有一些平臺則可能還不太需要低代碼或者任何可視化工具，用于構(gòu)建用戶界面、工作負(fù)載或系統(tǒng)集成。

這種情況只是一方面，更重要的是，需要確定誰來設(shè)計(jì)、開發(fā)和維護(hù)應(yīng)用程序。一些低代碼平臺是面向?qū)I(yè)開發(fā)者的工具，其需要具備軟件開發(fā)技能的專業(yè)人士。還有一些低代碼平臺則面向公民開發(fā)者，目的是讓業(yè)務(wù)分析人員或領(lǐng)域?qū)＜彝暾麘?yīng)用開發(fā)的全流程。某些平臺會支持這兩種選項(xiàng)，而每個角色都有不同的工具和功能。

因此，無論是哪一類開發(fā)人員選擇了使用低代碼，都應(yīng)該確保他們使用這些工具來支撐優(yōu)先級業(yè)務(wù)，在這個過程中的較早階段就能夠快速有效地降低其低代碼開發(fā)的學(xué)習(xí)成本。

3、研究客戶體驗(yàn)

實(shí)際情況中，用戶很難會找到一些消極負(fù)面的聲音，但找到數(shù)百個正面評價卻很容易。因?yàn)樵谑袌鲂麄髦?，某些平臺會強(qiáng)調(diào)其服務(wù)的客戶和開發(fā)者的數(shù)量；有些平臺會分享客戶滿意度的評分報告；還有一些更大更成熟的平臺可能還會出現(xiàn)在第三方分析報告的測評中，如Gartner的魔力象限圖、Forrester的Waves等等。

從作者的角度，他更建議關(guān)注客戶滿意度的評分。他認(rèn)為，一個擁有出色用戶滿意度的低代碼平臺，意味著廠商需要提供出色的最終用戶體驗(yàn)，讓技術(shù)人員在某些方面表現(xiàn)突出，并向企業(yè)決策者證明其長短期價值。某些低代碼平臺可能無法贏得這些角色的話，這意味著企業(yè)也很難套用其技術(shù)來復(fù)制同樣商業(yè)上的成功。

4、定義使用要求并估算價格

低代碼平臺具有非常不同的業(yè)務(wù)和定價模式。有些依據(jù)最終用戶使用量定價，因此使用的越多費(fèi)用越高。還有的依據(jù)開發(fā)規(guī)模（如應(yīng)用數(shù)量或開發(fā)席位）對平臺定價；還有一些會提供組合式產(chǎn)品，都可以單獨(dú)購買。

所以，盡管許多工具為試驗(yàn)和概念驗(yàn)證提供了最低的門檻，但了解最終狀態(tài)的開發(fā)和生產(chǎn)要求也很重要。

此外，不要陷入僅憑價格評估低代碼平臺的陷阱。因?yàn)檫@些平臺核心仍是需要提供令人愉悅的體驗(yàn)、開發(fā)生產(chǎn)力工具和強(qiáng)大運(yùn)營能力。如果必須要計(jì)算出總擁有成本，那么請將財務(wù)因素也考慮進(jìn)來。

5、調(diào)查并確定集成需求的優(yōu)先級

沒有誰愿意在孤島中進(jìn)行低代碼開發(fā)。開發(fā)出的應(yīng)用程序需要與企業(yè)核心系統(tǒng)、數(shù)據(jù)中心數(shù)據(jù)庫、云平臺、第三方數(shù)據(jù)源集成。比如物聯(lián)網(wǎng)數(shù)據(jù)pipeline或機(jī)器學(xué)習(xí)模型的的開發(fā)中，就很有可能需要與低代碼進(jìn)行集成。

幾乎所有平臺都提供API集成。但如何提升性能、如何支撐開發(fā)卻大有不同。首先核心需要考慮的是，需要開發(fā)一款能夠集成復(fù)雜且可持續(xù)維護(hù)的低代碼應(yīng)用。

然后，要查看該應(yīng)用的的開發(fā)支持哪種類型的動作和觸發(fā)器，能夠進(jìn)一步了解低代碼平臺是否與其他平臺進(jìn)行了集成。

6、審查托管、開發(fā)和治理選項(xiàng)

低代碼曾經(jīng)是SaaS和云托管，以及少數(shù)提供混合云和數(shù)據(jù)中心選型的代名詞。如今，情況也不再如故。低代碼平臺現(xiàn)在在托管靈活性方面具備很強(qiáng)的競爭力。

DevOps是另一個需要著重考慮的因素。就DevOps功能而言，并沒有所有低代碼平臺的功能性是平等的。尤其在以下領(lǐng)域：

對應(yīng)用程序進(jìn)行版本控制或與版本控制系統(tǒng)集成；

支持跨開發(fā)、測試和其他環(huán)境的開發(fā)生命周期；

通過連接到管理積壓和路線圖的工具來實(shí)現(xiàn)敏捷開發(fā)流程；

與持續(xù)集成/持續(xù)部署、持續(xù)測試或IT服務(wù)管理變更管理流程集成；

啟用數(shù)據(jù)快照，或提取、轉(zhuǎn)換、加載流程以支持災(zāi)難恢復(fù)和數(shù)據(jù)科學(xué)。

不要期望低代碼平臺像Java、.NET或JavaScript在DevOps中的使用那樣靈活。進(jìn)入低代碼平臺確實(shí)需要權(quán)衡，因?yàn)槠淠康氖呛喕С謶?yīng)用程序開發(fā)和運(yùn)營所需的所有框架。問題是它們是否滿足業(yè)務(wù)和技術(shù)需求，而不是它們是否符合為編碼和軟件開發(fā)而設(shè)計(jì)的工具和流程。

最后，如果計(jì)劃授權(quán)業(yè)務(wù)部門的人員來構(gòu)建和支持應(yīng)用，可查看平臺的公民開發(fā)治理選項(xiàng)。

7、了解合規(guī)性和安全性要求

評估平臺的順序很重要。不要誤解合規(guī)性和安全性是最后或最不重要的問題。實(shí)際上，評估平臺的核心在于確定什么是必須的，什么是應(yīng)該的，以及何時評估不同的標(biāo)準(zhǔn)。

如果開發(fā)需要HIPAA合規(guī)性、數(shù)據(jù)沿襲功能、審核功能、數(shù)據(jù)主權(quán)合規(guī)性、目錄集成、托管約束或其他不可協(xié)商性問題，應(yīng)事先評估這些要求。

當(dāng)你實(shí)施應(yīng)用程序時，需要了解低代碼平臺如何處理基于角色的管理、數(shù)據(jù)屏蔽和其他安全注意事項(xiàng)。

（雷鋒網(wǎng)雷鋒網(wǎng)雷鋒網(wǎng)）