Les plateformes low-code: une panacée ou un pari risqué?

Les plates-formes à faible code (plates-formes d'application à faible code, LCAP) sont apparues en réaction à la complexité et à la variété des outils modernes de développement de logiciels.


Selon Gartner, l'un des joueurs les plus célèbres dans ce domaine est Mendix . La vente de Siemens pour un espace de 700 millions de dollars le confirme. Je vais donc utiliser cette plate-forme comme exemple, bien que des conclusions similaires soient vraies pour Outsystems, Appian, Kony, Betty Blocks et autres.


image


Ainsi, en ciblant les ventes auprès des cadres supérieurs, les fournisseurs de plates-formes à faible code promettent que même les utilisateurs ordinaires pourront créer eux-mêmes des applications métier.


Autrement dit, les développeurs ne sont plus nécessaires?!


Eh bien ... après quelques années, Mendix est obligé d'admettre:


texte
"Désormais, les développeurs ont besoin de plus que jamais."


C'est une torsion!


Il semble que Mendix ait reconnu que pour quelque chose de plus difficile que le travail de base avec les données, un développeur professionnel est toujours requis, tout comme un mécanicien professionnel est nécessaire pour entretenir une voiture.


Malheureusement, les plates-formes modernes de code bas ne sont tout simplement pas conçues pour les développeurs, et compter sur elles à long terme est risqué pour les entreprises. Si votre entreprise envisage sérieusement d'utiliser des plates-formes à faible code en fonctionnement industriel, il convient de peser à nouveau cette solution. Ci-dessous, je vais essayer de discuter de cela.


Excellent outil de prototypage


Mendix est une très bonne option pour automatiser des processus simples ou le prototypage, disponible pour les analystes ou les utilisateurs avancés.


L'éditeur visuel vous permet de décrire le modèle de données, de créer rapidement des écrans à l'aide d'un ensemble de widgets et de modèles, et même de décrire la logique à l'aide des soi-disant microflux :


texte


Une fois terminé, vous pouvez déployer votre application dans le cloud Mendix en un clic et commencer à travailler avec. Si simple que ça ressemble à de la magie! Et on dirait qu'il se vend bien.


Cependant, après avoir traversé l'étape du prototype, l'interaction du système avec l'utilisateur et la logique métier sont presque inévitablement compliquées. Pour développer davantage le projet, un professionnel est requis. Alors, regardons Mendix à travers les yeux d'un développeur.


Développement lent


Toute logique - qu'il s'agisse de calcul ou d'interaction avec l'utilisateur - doit être décrite dans un organigramme de microflux, comme indiqué ci-dessus.


Il y a plusieurs problèmes ici.


Tout d'abord, c'est long . De toute évidence, il est plus rapide d'écrire 10 lignes de code dans un bon IDE que de glisser-déposer, de personnaliser et de joindre des dizaines de blocs.


Deuxièmement, la lisibilité . Les blocs sont beaux, mais que signifie cette Sub_RegistrationValidation ? Il est impossible de comprendre cela sans tomber dans le bloc. Dès que le nombre de blocs atteint plusieurs dizaines, la compréhension de la logique devient extrêmement difficile.


Comme alternative pour les cas complexes, Mendix prend en charge les appels de code Java à partir de microflux. Vous pouvez écrire du code dans Eclipse, ce qui est généralement bon, bien que beaucoup préfèrent un IDE plus populaire. L'inconvénient est le manque de transparence: tous les points d'entrée sont en microflux, donc la logique est dispersée entre deux environnements faiblement couplés. Par conséquent, le débogage et le suivi des dépendances sont difficiles.


La dernière chose que je voulais mentionner était le contrôle de version.


La bonne nouvelle, c'est qu'il l'est. La mauvaise chose est que c'est une version allégée de Subversion. Oubliez Git Flow.


Manque de contrôle


Quiconque connaît l'écosystème Java ne peut pas sous-estimer la puissance de l'open source. Lorsqu'une erreur apparaît quelque part sur la pile, vous voyez dans quelle partie du code cela s'est produit. Le code peut être débogué pour comprendre exactement ce qui se passe. Vous pouvez rechercher la solution sur Google. Vous pouvez envoyer une demande d'extraction. Dans les cas extrêmes, vous pouvez bifurquer la bibliothèque. Vous êtes en plein contrôle du projet.


Avec Mendix, vous pouvez l'oublier. Il s'agit d'un cadre commercial fermé et ce qui se passe à l'intérieur est une véritable boîte noire. Il ne vous reste plus qu'à acheter un support payant ou attendre que quelqu'un vous aide sur un forum avec ~ 200 questions par mois (comparer avec la balise #spring sur stackoverflow !).


Dépendance du fournisseur


Mendix lui reproche probablement assez souvent. Ils ont même publié un article disant qu'il n'y a vraiment pas de dépendance. Si vous lisez entre le terme, il lit:


Vous pouvez obtenir vos données, DDL, ressources d'interface utilisateur et code (microflow converti comme par magie en code Java).


Sera-t-il exécuté ou compilé sans runtime et API Mendix? Peut-elle être maintenue et développée? Les questions sont rhétoriques. En fait, vous devrez tout réécrire complètement. Vous dépendez d'une plateforme propriétaire. Vous n'êtes pas propriétaire du système que vous avez créé.


Évolutivité limitée


Le marketing Mendix est axé sur les plus grandes entreprises, de sorte que le terme «évolutivité» clignote constamment dans les documents marketing.


En 2017, Mendix a introduit le runtime sans état, c'est-à-dire que toutes les informations de session sont stockées côté client ou dans un stockage persistant.


Théoriquement, cela signifie une évolutivité horizontale illimitée. Cela semble génial, mais comme d'habitude, il y a une nuance - la base de données.


Une base de données s'avère presque toujours être un goulot d'étranglement dans une application d'entreprise. Alors, que stockent les données derrière de nombreux serveurs sans état Mendix? Pas de surprise - c'est une bonne vieille base de données relationnelle. Dans le cloud Mendix - PostgreSQL. De plus, le DDL Mendix généré, pour le moins, n'est pas entièrement optimal. Par exemple, j'ai vu une table intermédiaire couramment utilisée pour modéliser les relations N: M, créée pour une relation 1: N.


Le problème d'évolutivité pourrait être résolu par des méthodes standard: optimisation de la structure de la base de données, mise en cache ou même utilisation de solutions telles que Citus. Mais bien sûr, il n'y a pas une telle possibilité.


La seule façon de faire évoluer la base de données est de la faire évoluer à l'aide de répliques en lecture (par exemple, Amazon RDS). Mais pour mémoire, cela ne fonctionnera pas.


Pour résumer ce qui précède, Mendix a une limitation fondamentale de l'évolutivité et aucun moyen d'optimiser les performances.


Question RH


La recherche de personnel qualifié est toujours une tâche difficile. Il semblerait que dans ce Mendix soit le rêve de tout manager, car les exigences de qualification sont fortement réduites.


En fait, nous avons déjà découvert que la plupart des projets nécessitent une équipe professionnelle, quel que soit l'outil. Mais il est peu probable qu'un développeur qui se respecte accepte de travailler avec Mendix, car il s'agit d'une impasse évidente dans sa carrière.


Les prix


Dernier point mais non le moindre. Le coût d'une licence pour une application commence à 1875 $ par mois, sous réserve d'un abonnement de trois ans, la licence est limitée à 50 utilisateurs internes.


Le prix d'une licence d'entreprise avec possibilité de déploiement local commence à 7 825 $, soit près de 100 000 $ par an.


Une entreprise de taille moyenne comptant plusieurs centaines d'utilisateurs paiera annuellement des dizaines de millions de roubles.


N'oubliez pas que nous parlons d'applications relativement simples, comme vous pouvez le comprendre ci-dessus. Pour moi, c'est fou. Ce modèle de tarification rend également pratiquement impossible la réplication des applications que vous avez créées.


Alors pourquoi les LCAP sont-ils toujours populaires?


À mon avis, la raison réside dans la déception des processus existants. La gestion d'une équipe de développement dans une grande organisation - qu'il s'agisse d'une équipe interne ou d'une externalisation - est trop compliquée.


Planification budgétaire, approbations sans fin, manque de personnes prêtes à prendre des responsabilités - je pense que cela est familier à beaucoup.


Ce qui est drôle, c'est que la première chose qui vient à l'esprit lorsque les projets informatiques avancent trop lentement est d'embaucher encore plus de développeurs et, bien sûr, de managers. Il va sans dire que cela ne fait qu’aggraver la situation. Je connais quelques banques avec plus de 10 000 (!!!) développeurs, et au moins la moitié d'entre elles font un travail inutile.


En désespoir de cause, les chefs d'entreprise recherchent une solution dans des "baguettes magiques" telles que LCAP, censées être capables de résoudre tous les problèmes.


Comment sortir de ce cercle vicieux est un sujet pour un article séparé. Mais c'est une question de gestion, pas de technologie.


Sans entrer dans les détails, si vous parvenez à créer une petite équipe qualifiée de 3 à 10 personnes pleinement impliquées dans le projet, en contact direct avec le décideur, vous obtiendrez d'excellents résultats plus rapidement et moins cher que prévu.


Quelles sont les alternatives?


Maintenant, il existe une vaste sélection d'outils et de cadres pour les développeurs.


Par exemple, Spring Framework est la technologie open source la plus populaire pour créer des logiciels d'entreprise qui fonctionnent bien avec des frameworks Web comme React ou Angular. Et des outils comme Spring Initializr et JHipster ont considérablement simplifié la création de projets au cours des dernières années.


Si vous souhaitez obtenir le résultat plus rapidement, vous devriez envisager des outils RAD tels que la plate-forme CUBA .


Il est basé sur le même Spring Framework, le complète avec des outils de développement visuel et un grand nombre de composants standard. C'est peut-être l'alternative la plus proche du LCAP, offrant une flexibilité et un processus de développement confortable.


Le choix final devrait dépendre de la tâche, ainsi que des compétences de l'équipe et de vos préférences.


Conclusion


Les plates-formes low-code sont idéales pour le prototypage. Ils réduisent l'écart entre les utilisateurs professionnels et l'informatique, ce qui vous permet d'obtenir rapidement un prototype fonctionnel et de vous forger une vision du futur système.


Comme il y a très peu d'utilisateurs de prototypes, les coûts à ce stade sont également faibles. Et ça vaut le coup d'arrêter en ce moment!


Lorsque vous utilisez LCAP pour développer un système complet, la vitesse de travail diminuera inévitablement et vous dépendrez de la plateforme propriétaire coûteuse qui vous limite.

Source: https://habr.com/ru/post/fr483258/


All Articles