Catégories
Start-up et applications

3 principaux pièges du développement d'applications low-code et comment les éviter

https://sdtimes.com/ "srcset =" http://www.cardagram.fr/wp-content/uploads/2020/11/3-principaux-pieges-du-developpement-d39applications-low-code-et-comment-les.jpg 490w, https://sdtimes.com /wp-content/uploads/2020/11/pexels-andrea-piacquadio-3755755-300x200.jpg 300w, https://sdtimes.com/wp-content/uploads/2020/11/pexels-andrea-piacquadio-3755755- 150x100.jpg 150w, https://sdtimes.com/wp-content/uploads/2020/11/pexels-andrea-piacquadio-3755755-120x80.jpg 120w, https://sdtimes.com/wp-content/uploads/ 2020/11 / pexels-andrea-piacquadio-3755755-400x266.jpg 400w, https://sdtimes.com/wp-content/uploads/2020/11/pexels-andrea-piacquadio-3755755-270x180.jpg 270w, https: //sdtimes.com/wp-content/uploads/2020/11/pexels-andrea-piacquadio-3755755-75x50.jpg 75w, https://sdtimes.com/wp-content/uploads/2020/11/pexels-andrea -piacquadio-3755755.jpg 640w "tailles =" (largeur maximale: 490px) 100vw, 490px "/>

<p><span style=Le développement low-code existe depuis de nombreuses années et a connu des flux et des reflux de popularité, mais a récemment repris de la vitesse. à cause du COVID-19. Les entreprises cherchent à intensifier leurs efforts de transformation numérique, qu'il s'agisse de simplement lancer une initiative ou d'apporter des changements ou des améliorations significatifs aux produits numériques déjà utilisés. Le développement low-code peut être un excellent moyen construire rapidement des prototypes qui aident à faire passer les plans innovants de l'idéation à la validation.

Une chose est sûre: les créateurs d'applications low-code simplifient et démocratisent le développement traditionnel, en mettant une grande part de responsabilité sur les développeurs de plates-formes low-code pour que tout fonctionne correctement.

Cet article détaille trois problèmes majeurs que les développeurs low-code doivent prendre en compte pour offrir la meilleure expérience utilisateur possible.

Intégration avec des services tiers
L'intégration d'une application mobile avec des services tiers est un must absolu. Les utilisateurs finaux et les clients doivent pouvoir se connecter à des applications mobiles avec Google ou Facebook, intégrer des cartes Google, récupérer des données sur le Web, etc. Une application moderne typique doit s'interfacer avec entre cinq et 10 services tiers.

Atteindre le nombre optimal d'intégrations n'est pas une mince affaire. Il y a plusieurs étapes compliquées à suivre: créer un compte avec le service tiers, créer des actifs de développement et tout configurer correctement.

Un problème omniprésent avec l'intégration tierce est que les développeurs n'ont aucun contrôle sur les services tiers – l'API ou la politique de sécurité peut être modifiée à tout moment. C'est la prérogative du tiers de le faire pour protéger sa sécurité et sa réputation, et quand il le fait, il est de votre responsabilité de mettre à jour votre application dès que possible.

Transmettre la responsabilité de rester à jour aux développeurs low-code est une très grosse demande. Néanmoins, il s'agit de l'approche par défaut pour maintenir une intégration fluide avec des services tiers.

Assistants et middleware
La meilleure solution à ce problème est double.

Tout d'abord, pour rendre la configuration de l'application simple et indolore, les propriétaires de plates-formes low-code peuvent cacher toute la complexité de la configuration à leurs utilisateurs. À sa place, ils peuvent mettre un assistant de configuration ou d'autres outils qui aident les développeurs à naviguer dans chaque étape de configuration.

Deuxièmement, et surtout, les propriétaires de plates-formes peuvent utiliser un middleware qui se situe entre les services tiers et les développeurs low-code. Cela signifie que lorsqu'un tiers apporte des modifications, les propriétaires de plates-formes low-code peuvent mettre à jour le middleware et les développeurs n'ont pas à se soucier de changer quoi que ce soit. La plupart des API notifient à l'avance qu'elles apporteront des modifications, ce qui laisse aux propriétaires suffisamment de temps pour mettre leur middleware en ordre.

Si les propriétaires de plate-forme manquent une modification dans un service tiers, ils seront informés par tous les développeurs low-code de l'existence d'un problème. Ils peuvent ensuite apporter des modifications au middleware qui seront automatiquement appliquées à tous les produits utilisant ce service tiers. Il n'est pas nécessaire de gérer l'ennui de la mise à jour individuelle de chaque application.

Enfin, les propriétaires de plates-formes mettent généralement en cache les données des services tiers dans leur middleware, de sorte que les produits low-code afficheront les données, même si elles ne sont pas à jour. En règle générale, les applications informeront les utilisateurs finaux que les données sont obsolètes, mais tout le monde peut convenir qu'il est préférable d'afficher les données d'hier plutôt que d'afficher un lien brisé et grisé.

Composants personnalisés
Les développeurs low-code souhaitent souvent utiliser les mêmes composants d'interface utilisateur, les mêmes écrans et la même logique dans différentes applications. Pour répondre à ce besoin, les plates-formes de création d'applications utilisent des composants personnalisés pour rationaliser l'expérience utilisateur.

L'approche panacée
La première option pour créer des composants personnalisés consiste à créer un écran intelligent avancé avec des éléments personnalisables. Pour ce faire, les propriétaires de plates-formes doivent tenter de prédire tout ce dont un développeur low-code pourrait avoir besoin, puis créer un énorme composant configurable.

Le problème avec cette approche est que la configuration du composant est presque aussi difficile que la création de l'interface utilisateur à partir de zéro. Premièrement, les développeurs low-code disposeront d’une longue liste de propriétés à personnaliser, ainsi que de toute la documentation qu’ils devront lire, internaliser et appliquer. Il est pratiquement impossible de couvrir chaque cas d'utilisation avec un composant, ce qui signifie que cette approche crée souvent plus de problèmes qu'elle n'en résout.

Composant de bricolage personnalisé
La deuxième option, plus raisonnable, consiste à demander aux utilisateurs de créer leurs propres composants personnalisés. De cette façon, les propriétaires de plates-formes fournissent les éléments de base pour la fabrication des composants plutôt que les composants eux-mêmes.

Cela fait gagner du temps et peut aider les développeurs à faible code à résoudre les erreurs. Les développeurs qui trouvent des erreurs dans les composants qu'ils utilisent dans de nombreuses applications peuvent résoudre le problème une fois dans un composant personnalisé, et le correctif se répercutera sur toutes leurs applications.

De plus, les développeurs soucieux de la communauté peuvent partager leurs composants avec d'autres, créer une bibliothèque de leurs propres composants et contrôler les paramètres sous lesquels les personnes extérieures peuvent les voir, les utiliser et les manipuler. Ils peuvent le faire avec l'open source total ou l'open source restreint.

Il y a un compromis avec cette approche: les développeurs low-code doivent avoir une compréhension plus approfondie de l'image globale pour créer d'excellents composants personnalisés sans options prédéfinies. Mais avec ce travail supplémentaire, ils gagneront beaucoup plus de flexibilité.

Distinction entre le temps de conception et le temps réel
Le troisième problème majeur avec le développement d'applications low-code est de distinguer le temps de conception et le temps réel. Lorsque les développeurs low-code sont en train de créer une application, ce qu'ils voient (au moment de la conception) est différent de ce que les utilisateurs voient lorsqu'ils utilisent l'application (en temps réel). En termes simples, les applications ont un aspect différent lorsqu'elles sont dans l'éditeur et lorsqu'elles sont utilisées sur des appareils.

Pourquoi la différence?
Cela se produit car les deux environnements utilisent une logique, des bibliothèques et des infrastructures différentes pour exprimer l'interface utilisateur. Par exemple, si une application est créée dans React Native, l'interface utilisateur utilisera des composants HTML, car les interfaces utilisateur du navigateur sont écrites en HTML. En temps réel, les développeurs voient la vraie application native (par exemple, un bouton iOS), mais au moment du design, ils regarderont un bouton HTML.

En règle générale, les outils low-code utilisent différentes bibliothèques, une pour la conception, une pour iOS et une autre pour Android.

Une bibliothèque, moins d'expression
Pour contourner ce problème, les plates-formes low-code peuvent utiliser la même bibliothèque d'interface utilisateur dans l'éditeur que les téléphones mobiles utilisent dans toutes les situations: au moment du design, iOS et Android.

C'est extrêmement avantageux lors du développement d'une application, car les développeurs savent exactement ce que l'utilisateur final vivra, il n'y a donc pas de surprises. Ils obtiennent également exactement la même interface utilisateur sous iOS et Android.

Pourtant, cette approche présente des inconvénients importants. Les bibliothèques sont comme des langues; il y a souvent des phrases et des expressions qui ne peuvent pas être traduites d'une langue à une autre. La limitation des applications à une seule bibliothèque échange un langage idiomatique unique pour une clarté et une cohérence maximales.

Faire le travail
L'approche low-code comporte des avantages et des inconvénients, mais en fin de compte, c'est un moyen puissant d'arriver à une fin. Low-code permet aux développeurs de créer des applications fonctionnelles rapidement, efficacement et avec une expertise relativement faible. Même les problèmes majeurs liés au développement low-code peuvent être abordés et résolus. À l'ère du numérique, le low-code est sans aucun doute un acteur clé.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *