【51CTO.com快譯】 低代碼開發(fā)已存在了多年，但最近因新冠疫情而再次受到關(guān)注。企業(yè)在竭力加大數(shù)字化轉(zhuǎn)型的力度，無論這意味著啟動(dòng)項(xiàng)目，還是大幅更改或改進(jìn)已在使用的數(shù)字化產(chǎn)品。低代碼開發(fā)可能是快速構(gòu)建有助于創(chuàng)新計(jì)劃從構(gòu)思進(jìn)入到驗(yàn)證的原型的好方法。

[[353702]]

有一點(diǎn)可以肯定：低代碼應(yīng)用構(gòu)建工具簡(jiǎn)化和普及了傳統(tǒng)開發(fā)，這使低代碼平臺(tái)開發(fā)人員肩負(fù)重任，確保一切順利運(yùn)行。

本文詳細(xì)介紹了低代碼開發(fā)人員為提供最佳用戶體驗(yàn)而需要考慮的三大問題。

一、與第三方服務(wù)集成

將移動(dòng)應(yīng)用程序與第三方服務(wù)集成絕對(duì)必要。最終用戶和客戶需要能夠使用谷歌或Facebook登錄到移動(dòng)應(yīng)用程序、集成谷歌地圖以及從網(wǎng)上檢索數(shù)據(jù)等。一個(gè)典型的現(xiàn)代應(yīng)用程序要與5到10個(gè)第三方服務(wù)實(shí)現(xiàn)接口交互。

實(shí)現(xiàn)最佳集成并非易事。要遵循幾個(gè)復(fù)雜的步驟：針對(duì)第三方服務(wù)創(chuàng)建帳戶，創(chuàng)建開發(fā)資產(chǎn)，以及正確配置一切。

第三方集成普遍存在的問題是，開發(fā)人員無法控制第三方服務(wù)――API或安全策略可能隨時(shí)有變。這么做以保護(hù)安全和聲譽(yù)是第三方的特權(quán);第三方這么做時(shí)，盡快更新您的應(yīng)用程序是您的責(zé)任。

將更新的責(zé)任推給低代碼開發(fā)人員是很難滿足的要求。即使如此，這仍是與第三方服務(wù)保持順暢集成的默認(rèn)方法。

向?qū)Ш椭虚g件

解決該問題的最佳方法分兩方面。

首先，為了使應(yīng)用程序的配置簡(jiǎn)單而輕松，低代碼平臺(tái)所有者可以向用戶隱藏所有配置復(fù)雜性。他們可以添加設(shè)置向?qū)Щ蚱渌ぞ撸瑤椭_發(fā)人員瀏覽每個(gè)配置步驟。

其次，也是最重要的是，平臺(tái)所有者可以使用介于第三方服務(wù)和低代碼開發(fā)人員之間的中間件。這意味著第三方更改時(shí)，低代碼平臺(tái)所有者可以更新中間件，開發(fā)人員無需為更改任何內(nèi)容操心。大多數(shù)API會(huì)事先通知它們將進(jìn)行更改，這使所有者有足夠的時(shí)間來安排中間件。

如果平臺(tái)所有者錯(cuò)過了第三方服務(wù)的更改，所有低代碼開發(fā)人員會(huì)通知他們存在問題。然后，他們可以更改中間件，更改的內(nèi)容會(huì)自動(dòng)應(yīng)用于使用該第三方服務(wù)的所有產(chǎn)品。無需處理單獨(dú)更新每個(gè)應(yīng)用程序這項(xiàng)繁瑣工作。

最后，平臺(tái)所有者通常會(huì)將來自第三方服務(wù)的數(shù)據(jù)緩存在中間件中，那樣低代碼產(chǎn)品會(huì)顯示數(shù)據(jù)，即使不是最新數(shù)據(jù)。通常，應(yīng)用程序會(huì)通知最終用戶數(shù)據(jù)已過時(shí)，但大家可能一致認(rèn)為，顯示昨天的數(shù)據(jù)勝過顯示令人沮喪的灰色斷鏈。

二. 自定義組件

低代碼開發(fā)人員常常希望在不同的應(yīng)用程序中使用相同的UI組件、相同的屏幕和相同的邏輯。為了滿足這一需求，應(yīng)用程序構(gòu)建平臺(tái)使用自定義組件來簡(jiǎn)化用戶體驗(yàn)。

萬靈藥方法

創(chuàng)建自定義組件的第一個(gè)方法是，創(chuàng)建帶有可定制元素的高級(jí)智能屏幕。為此，平臺(tái)所有者須嘗試預(yù)測(cè)低代碼開發(fā)人員可能需要的一切，然后制作龐大的可配置組件。

這種方法的問題在于，配置組件幾乎與從頭創(chuàng)建UI一樣難。首先，低代碼開發(fā)人員會(huì)有要定制的一長(zhǎng)串屬性，以及要閱讀、內(nèi)化和應(yīng)用的所有說明文檔。想用一個(gè)組件覆蓋每個(gè)使用場(chǎng)景幾乎不可能，這意味著這種方法帶來的問題常常多過它所解決的問題。

自定義DIY組件

第二個(gè)也是更合理的方法是讓用戶自行創(chuàng)建自定義組件。這樣，平臺(tái)所有者提供了用于制造組件的構(gòu)建模塊，而不是組件本身。

這可以節(jié)省時(shí)間，并幫助低代碼開發(fā)人員解決錯(cuò)誤。在許多應(yīng)用程序中使用的組件中發(fā)現(xiàn)錯(cuò)誤的開發(fā)人員可以解決自定義組件中的問題，而解決方法適用于所有應(yīng)用程序。

此外，關(guān)注社區(qū)的開發(fā)人員可能與其他人共享組件、構(gòu)建自己的組件庫(kù)，并控制外人可以查看、使用和操縱組件的參數(shù)。他們可以使用完全開源或受限開源做到這一點(diǎn)。

這種方法有個(gè)缺點(diǎn)：低代碼開發(fā)人員需要更深入地了解整體情況，才能在沒有預(yù)定義選項(xiàng)的情況下構(gòu)建出色的自定義組件。但是這么做的好處是，可大大提高靈活性。

三. 設(shè)計(jì)時(shí)與實(shí)時(shí)的區(qū)別

低代碼應(yīng)用程序開發(fā)的第三大問題是區(qū)別設(shè)計(jì)時(shí)和實(shí)時(shí)。低代碼開發(fā)人員在構(gòu)建應(yīng)用程序時(shí)，他們看到的(設(shè)計(jì)時(shí))與用戶使用應(yīng)用程序時(shí)看到的內(nèi)容(實(shí)時(shí))不一樣。簡(jiǎn)而言之，應(yīng)用程序在編輯器中和在設(shè)備中使用時(shí)看起來不一樣。

為什么會(huì)不一樣?

這是由于兩個(gè)環(huán)境使用不同的邏輯、庫(kù)和框架來表示UI。比如說，如果應(yīng)用程序用React Native創(chuàng)建，UI將使用HTML組件，因?yàn)闉g覽器的UI是用HTML編寫的。實(shí)時(shí)狀態(tài)下，開發(fā)人員看到真正的原生應(yīng)用程序(比如iOS按鈕)，而設(shè)計(jì)時(shí)狀態(tài)下，他們看到的是HTML按鈕。

通常，低代碼工具使用不同的庫(kù)，一個(gè)用于設(shè)計(jì)時(shí)，一個(gè)用于iOS，另一個(gè)用于安卓。

一個(gè)庫(kù)，更少的表達(dá)

要解決該問題，低代碼平臺(tái)可以在編輯器中使用與所有情況下都與手機(jī)使用場(chǎng)景同樣的UI庫(kù)：設(shè)計(jì)時(shí)、iOS和安卓。

開發(fā)應(yīng)用程序時(shí)，這非常有利，因?yàn)殚_發(fā)人員準(zhǔn)確地知道最終用戶的體驗(yàn)，因此不會(huì)感到驚訝。他們?cè)趇OS和安卓中也獲得完全同樣的UI。

不過這種方法存在明顯的缺陷。庫(kù)就像語(yǔ)言，常常有短語(yǔ)和表達(dá)無法由一種語(yǔ)言翻譯成另一種語(yǔ)言。將應(yīng)用程序限制在一個(gè)庫(kù)是拿獨(dú)特的慣用語(yǔ)言換取最大的清晰度和一致性。

完成工作

低代碼方法有一些優(yōu)缺點(diǎn)，但到頭來，它是實(shí)現(xiàn)目的的有效手段。低代碼讓開發(fā)人員能夠以較少的專業(yè)知識(shí)快速高效地構(gòu)建實(shí)用的應(yīng)用程序。甚至可以解決低代碼開發(fā)方面的大問題。在數(shù)字化時(shí)代，低代碼無疑是關(guān)鍵角色。

原文標(biāo)題：3 major low-code app development pitfalls and how to avoid them，作者：Eldar Chernitsky和Alexander Ancipov

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】