Comment développer des applications low-code mais de qualité
Les organisations peuvent garder de fortes exigences en matière de développement, tout en réduisant le nombre de lignes de code écrites manuellement. À condition de suivre quelques lignes directrices.
Avec trop peu de développeurs qualifiés, les organisations ont besoin d’un moyen de réduire le volume de code qu’elles doivent écrire, mais pas leur nombre d’applications.
Pour mieux répondre à la demande, l’industrie a créé des langages descriptifs, souvent appelés langages de quatrième génération, plus faciles à utiliser par les collaborateurs. Cependant, s’ils ont facilité la création de logiciels, faire de bons programmes est resté une autre paire de manches.
Le développement d’applications low-code est une forme de développement dit « model-driven » (dirigée par le modèle), dans lequel l’organisation ou l’équipe assemble des composants de haut niveau pour créer une application, plutôt que de coder des fonctions et des fonctionnalités. Ces composants permettent de travailler directement avec des unités complexes (dans le sens « évolués ») plutôt qu’avec des instructions de bases, des microservices ou des librairies.
Les méthodes low-code transposent ce processus d’abstraction aux fonctions métier, avec pour objectif de garder une certaine qualité logicielle tout en simplifiant la création des applications.
D’un côté du low-code, les développeurs peuvent construire des logiciels de manière similaire aux méthodologies qui reposent sur les services et les microservices. De l’autre côté du low-code (le no-code), les métiers – sans réelles compétences en codage – peuvent s’impliquer dans la création de leurs propres logiciels. Ces deux variations du low-code partagent, en arrière-plan, une même philosophie et une même stratégie de contrôle de la qualité.
S’assurer que les composants sont de qualité
Tout développement low-code est basé sur l’approche dite de « la boîte noire ». Dans cette approche, un composant logiciel est une sorte de boîte dont les propriétés externes sont les seules visibles. Ce que fait cette boîte est évident, mais sa manière de le faire reste opaque. Ce concept de boîte noire épargne à l’utilisateur les complexités classiques du code – et plus le modèle est général (plus la boîte fait de choses), moins il y a besoin de compétences en développement.
Tout développement low-code est basé sur l’approche dite de « la boîte noire ».
Pour garder des logiciels de qualité, utilisez des composants développés par des professionnels. Ainsi même si ce sont des « développeurs métiers » qui assemblent ces composants, leur qualité de départ se diffusera dans l’application low-code finale.
Des composants bien réalisés contribueront à assurer la qualité du logiciel, à condition bien sûr que vous vous assuriez de bien les sélectionner et de les assembler de manière judicieuse.
Développer dans un but précis
La qualité d’un logiciel dépend également du fait que l’application assemblée à partir des composants corresponde réellement à l’objectif.
Vous devez mettre en place une stratégie pour garder le projet sur les bons rails tant à la phase de sa conception qu’à celle de l’implémentation.
Lors de la conception, suivez une méthodologie précise pour traduire les exigences métier en suite d’étapes – étapes qui correspondent aux composants du toolkit de développement low-code. La programmation low-code nécessite, elle aussi, des objectifs métiers bien définis, exprimés en termes compréhensibles pour les codeurs.
Pour la mise en œuvre, systématisez des séquences de workflow. Bien que le low-code soit de plus en plus populaire, les méthodes qui permettent de répondre aux besoins de rapidité dans le déploiement sont encore peu connues. Aujourd’hui, le behavior-driven development (ou BDD) est la meilleure option.
Le BDD est une approche qui travaille en remontant des résultats attendus pour définir les séquences de processus de l’application. Cette méthode s’appuie sur les définitions des tests, les traitements attendus des données – que les tests doivent valider. Cela détermine (ou donne en tout cas une indication) sur les séquences de composants.
La qualité minimum acceptable d’une application repose sur les tests. Le BDD est donc le mécanisme le plus puissant pour intégrer de la conformité au développement low-code.
Les techniques et les outils de BDD impliquent que l’on définisse les fonctions en partant des résultats attendus. Les outils BDD conviennent bien aux organisations qui ont des développeurs capables de créer la structure des applications et d’en définir les principales fonctions. Les personnes moins qualifiées développent ensuite les applications en fonction des besoins.
L’engouement pour le low-code repose sur l’utilisation d’outils hautement architecturés, souvent appelés « plateformes de développement ».
Le problème avec ces outils est qu’ils nécessitent un développeur professionnel lors de la configuration initiale. Aujourd’hui, l’engouement pour le low-code repose sur l’utilisation d’outils hautement architecturés, souvent appelés « plateformes de développement », qui incluent des fonctionnalités BDD essentielles et systématisent l’ensemble du processus de développement. Ils résolvent deux problèmes majeurs dans la qualité logicielle : les incohérences possibles le long du processus de développement et le manque de collaboration entre participants au projet.
Importance des dépendances
Les outils low-code peuvent également aider à surmonter un autre obstacle : la résolution des dépendances.
Le logiciel peut « crasher » si les composants de l’application ne sont pas assemblés de manière logique, même s’ils sont corrects sur le plan fonctionnel et développés par des professionnels. Le glisser-déposer, l’assemblage, ou même une application construite par des fonctions reliées par des appels de service, exigent que chaque composant fonctionne avec le résultat du composant précédent. Une plateforme low-code devra générer une alerte d’incompatibilité chaque fois que ce chemin logique ne sera pas respecté.
Le changement d’une structure commune de données devra déclencher un « remapping » de tous les processus qui utilisent cette structure.
Ces mappings et remappings ainsi que les systèmes d’alerte aident à assurer une qualité du logiciel pendant le développement même des applications à low-code.
En conclusion, tant que les développeurs de métier auront la charge de résoudre les problèmes complexes de code – y compris en amont du low-code – et que les métiers utiliseront un environnement complet – avec des contrôles de qualité logicielle correctement appliqués – le mouvement vers la démocratisation de la création d’applications ne pourra apporter que du bon aux entreprises.
