[[401052]]

本文轉自雷鋒網，如需轉載請至雷鋒網官網申請授權。

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

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

低代碼平臺有以下這么幾類：一是用于快速開發Web和移動端用戶界面及工作負載的工具；二是數據可視化、數據集成和數據準備的工具；三是支撐一些新興的應用如機器學習、物聯網和IT自動化。

文本將重點介紹實現應用開發、支持和增強的低代碼開發平臺。

1、識別和評估多個用例

低代碼有助于企業組織加速應用開發，并讓個性化需求的滿足變得更加容易，但這需要針對客戶想要的最終用戶體驗、數據準備、工作負載功能等因素對應用開發進行評估。

在研究和測試低代碼平臺時，必須考慮多個應用開發團隊的需求和用例，這點非常重要。因為有可能會發現平臺無法執行或無法輕松執行的操作，這就需要事先了解其優缺點及各項能力。

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

在研究和測試低代碼平臺時，必須考慮多個應用程序開發人員的需求和用例，這一點很重要。最重要的是，發現平臺無法執行或無法輕松執行的操作，并了解其范圍，優點和缺點。選擇低代碼方法是因為它適用于一個用例，但不能保證它是滿足持續需求的最佳標準。     

2、明確應用開發的負責人

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

這種情況只是一方面，更重要的是，需要確定誰來設計、開發和維護應用程序。一些低代碼平臺是面向專業開發者的工具，其需要具備軟件開發技能的專業人士。還有一些低代碼平臺則面向公民開發者，目的是讓業務分析人員或領域專家完整應用開發的全流程。某些平臺會支持這兩種選項，而每個角色都有不同的工具和功能。

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

3、研究客戶體驗

實際情況中，用戶很難會找到一些消極負面的聲音，但找到數百個正面評價卻很容易。因為在市場宣傳中，某些平臺會強調其服務的客戶和開發者的數量；有些平臺會分享客戶滿意度的評分報告；還有一些更大更成熟的平臺可能還會出現在第三方分析報告的測評中，如Gartner的魔力象限圖、Forrester的Waves等等。

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

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

低代碼平臺具有非常不同的業務和定價模式。有些依據最終用戶使用量定價，因此使用的越多費用越高。還有的依據開發規模（如應用數量或開發席位）對平臺定價；還有一些會提供組合式產品，都可以單獨購買。

所以，盡管許多工具為試驗和概念驗證提供了最低的門檻，但了解最終狀態的開發和生產要求也很重要。

此外，不要陷入僅憑價格評估低代碼平臺的陷阱。因為這些平臺核心仍是需要提供令人愉悅的體驗、開發生產力工具和強大運營能力。如果必須要計算出總擁有成本，那么請將財務因素也考慮進來。

5、調查并確定集成需求的優先級

沒有誰愿意在孤島中進行低代碼開發。開發出的應用程序需要與企業核心系統、數據中心數據庫、云平臺、第三方數據源集成。比如物聯網數據pipeline或機器學習模型的的開發中，就很有可能需要與低代碼進行集成。

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

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

6、審查托管、開發和治理選項

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

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

對應用程序進行版本控制或與版本控制系統集成；

支持跨開發、測試和其他環境的開發生命周期；

通過連接到管理積壓和路線圖的工具來實現敏捷開發流程；

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

啟用數據快照，或提取、轉換、加載流程以支持災難恢復和數據科學。

不要期望低代碼平臺像Java、.NET或JavaScript在DevOps中的使用那樣靈活。進入低代碼平臺確實需要權衡，因為其目的是簡化支持應用程序開發和運營所需的所有框架。問題是它們是否滿足業務和技術需求，而不是它們是否符合為編碼和軟件開發而設計的工具和流程。 

最后，如果計劃授權業務部門的人員來構建和支持應用，可查看平臺的公民開發治理選項。

7、了解合規性和安全性要求

評估平臺的順序很重要。不要誤解合規性和安全性是最后或最不重要的問題。實際上，評估平臺的核心在于確定什么是必須的，什么是應該的，以及何時評估不同的標準。  

如果開發需要HIPAA合規性、數據沿襲功能、審核功能、數據主權合規性、目錄集成、托管約束或其他不可協商性問題，應事先評估這些要求。

當你實施應用程序時，需要了解低代碼平臺如何處理基于角色的管理、數據屏蔽和其他安全注意事項。