Pourquoi Low-Code n’est pas forcément horrible

Les développeurs de codes bas ont tendance à avoir une connotation négative, mais ce n'est pas nécessairement le cas. Il y a une bonne façon de faire du code bas.

Avant de travailler chez Progress, j'avais une application de création d'emplois pour neuf à cinq personnes dans une assez grande compagnie d'assurance aux États-Unis. J'aimais travailler là-bas, mais à un moment donné, notre équipe de direction a décidé que l'équipe de développement ne créait pas assez rapidement d'applications. Pour remédier à ce manque de rythme, ils ont acheté un outil «code bas» qui, aux fins de cet article, sera appelé AppMaker 2000.

AppMaker2000 avait une superbe page d’accueil qui promettait tout ce que vous pouvez imaginer et plus encore. Créez des applications rapidement! Aucune compétence de développement nécessaire! Cependant, malgré son attrait, AppMaker2000 est rapidement devenu une insulte péjorative des développeurs de la société. Nous avions besoin de renoncer aux compétences que nous possédions déjà et de créer des applications générées que nous savions pouvoir construire mieux et plus rapidement à la main.

Mon histoire n’est pas unique, car presque tous les développeurs ont utilisé (et détesté) un outil similaire. dans leur carrière.

Définition du code faible

Bien que “code faible” soit désormais synonyme de logiciel hostile aux développeurs, le terme lui-même ne devrait pas être négatif. connotations. Code faible signifie simplement créer un logiciel avec un minimum de code, ce qui n’est pas une mauvaise chose. Après tout, l’un des principaux objectifs du développement logiciel est d’automatiser les tâches répétitives, et écrire du code peut absolument être répétitif et sujet aux erreurs.

En fait, de nombreux outils de code bas sont déjà populaires dans la communauté du développement, même si n'utilisez pas d'étiquette «code bas». Par exemple, Xcode, la plate-forme de développement iOS, recommande d'utiliser Visual Storyboards comme principal moyen de créer des vues iOS. Lors du développement de Storyboards, Xcode vous permet de voir le canevas que vous êtes en train de construire et de faire glisser directement les composants d'interface utilisateur dont vous avez besoin.

Unity, le jeu populaire plate-forme de développement, vous permet également d'ajouter visuellement des composants à votre scène et fournit également des interfaces utilisateur graphiques pour la configuration de fonctionnalités telles que l'éclairage, le son et les actifs d'application.

Pour la plupart des développeurs. Je parle pour avoir une haute opinion de l'outillage visuel à la fois dans Xcode et Unity 3D. Et l'enquête sur les développeurs Stack Overflow 2019 le confirme, car la plate-forme iOS et l'outil Unity 3D apparaissent tous deux vers le milieu des listes «Les plus aimés» de Stack Overflow.

Il n'est pas difficile de voir en quoi les outils de développement visuel sont si attrayants. Par exemple, supposons que vous deviez créer un jeu et que vous vouliez commencer par placer une poignée de modèles 3D sur une toile. Si vous essayez d’accomplir cette tâche dans le code seul, vous devrez peut-être apprendre un nouveau langage, de nouvelles API pour utiliser le modèle, et vous devrez déterminer comment tester le code que vous écrivez. En revanche, avec l'éditeur 3D de Unity, vous pouvez afficher une collection de modèles 3D directement dans l'outil et faire glisser ces modèles à leur emplacement approprié sur votre toile en quelques minutes.

Si c'est le cas, ainsi que les outils à code réduit

Même si un outil visuel peu codé peut être un gain de temps considérable, ce même outil peut souvent créer des applications lentes ou boguées, ou applications que vous ne pouvez pas étendre au-delà de ce que l'outillage visuel offre. Voyons quelques-uns des inconvénients du code bas en général.

Raison n ° 1: sortie incorrecte

Le temps qu'un outil vous fait gagner n'a pas d'importance si le résultat final est inacceptable. Les outils à faible code, par nature, aident à résoudre les problèmes de développement génériques. Et pour cette raison, le code généré par ces outils n'est pas aussi optimisé que le code que vous écrivez à la main.

Dans de nombreux cas, ce compromis est acceptable: c'est-à-dire que, tant que l'application fonctionne correctement, les économies de coûts de développement sont généralement réalisées. l'emporte sur la performance atteinte. Cependant, de nombreux outils à code réduit génèrent un code qui ne respecte pas la norme standard, ce qui rend les économies de coûts de développement inutiles.

L'exemple le plus notoire d'un outil générant du code épouvantable est le vénérable Microsoft FrontPage. Bien que FrontPage ait légitimement aidé de nombreuses personnes à créer des sites Web à ses débuts (y compris moi!), Son code généré peu performant a empêché l'utilisation de l'outil dans des applications Web sérieuses.

J'ai personnellement frappé plusieurs fois au cours de ma carrière cette limitation des outils à code réduit, notamment avec l'outil mentionné précédemment, AppMaker2000. AppMaker2000 a généré des applications Web, mais des applications Web qui ne fonctionnaient que dans Internet Explorer. Au moment où nous avons acheté AppMaker2000, tout allait bien (c'était le seul navigateur utilisé par nos utilisateurs), mais quelques années plus tard, les exigences ont changé et, lorsque nos utilisateurs ont demandé l'assistance de Firefox, nous avons dû refuser, car le code généré ne fonctionnait pas. dans Firefox, nous ne pouvions rien y faire.

Raison n ° 2: non extensible

Un outil de code bas, aussi complet soit-il, ne peut jamais résoudre 100% des problèmes de développement. Par conséquent, il est important que les outils à code réduit offrent une variété de moyens pour étendre les applications que vous construisez au-delà de ce que l'outil lui-même peut automatiser. Malheureusement, ce n'est pas toujours le cas.

Par exemple, lorsque j'ai mis la main sur AppMaker2000, la première tâche que j'ai tentée était d'utiliser CSS pour modifier l'aspect visuel des applications générées par l'outil. Ces mises à jour CSS ont fonctionné … jusqu'à ce que je modifie AppMaker2000, puis AppMaker2000 supprimait toutes les modifications personnalisées apportées par son processus de génération.

Frustrés mais déterminés, certains d'entre nous ont écrit un code de déploiement qui modifiait la CSS générée auparavant. il est allé à nos serveurs de développement et de production. C'est en même temps le code dont je suis le plus fier et le plus honteux, mais c'est exactement le type de raison pour lequel code bas a une mauvaise réputation – les développeurs détestent devoir aller si loin pour implémenter des fonctionnalités triviales.

Et cela peut s'aggraver, parce que si vous rencontrez une exigence de projet que vous n'avez aucun moyen d'accomplir, vous ne pouvez souvent pas vous éloigner de l'outil que vous utilisez.

Raison n ° 3: Verrouillage

Parce que le code de l'outil à code faible est généralement générés, ce code est souvent inutile en dehors de l'outil de code bas lui-même. Par exemple, les story-boards générés par Xcode ne sont utiles que dans Xcode, et les toiles générées par Unity ne sont utiles que dans Unity 3D.

Cette exclusivité n’est pas nécessairement une mauvaise chose, mais elle le peut souvent lorsque de l’argent est mis à contribution. Les outils à code faible sont souvent proposés sous forme de services par abonnement, ce qui signifie que vous devez continuer à payer si vous souhaitez continuer à utiliser l'outil, ce qui peut vous empêcher de payer pour conserver les applications que vous avez déjà déployées, même si vous le souhaitez. êtes prêt à vous éloigner de l'outil lui-même

Par exemple, après environ deux ans d'utilisation d'AppMaker2000, nous avons réalisé que la plupart de nos applications ne convenaient pas à l'outil et nous voulions abandonner le produit. Cependant, à ce stade, de nombreuses applications construites avec AppMaker2000 étaient en production avec de vrais utilisateurs et nous ne pouvions donc pas nous écarter instantanément de cet outil. Donc … nous avons continué à payer pour prendre en charge ces applications, et je sais que mon ex-société paie toujours pour utiliser AppMaker2000 à ce jour.

Faire du code bas de la bonne manière

Bien que les outils de code faible Certains de leurs outils sont que tous les outils de code bas ne sont pas créés de la même manière et que certains parviennent bien à atténuer les inconvénients du code bas.

Par exemple, considérons les exemples Xcode et Unity 3D que j'ai donnés précédemment. Une des raisons pour lesquelles les développeurs aiment généralement ces outils est qu’ils ont tendance à éviter certains des inconvénients des outils à faible code. Tous deux génèrent un code de haute qualité pouvant être utilisé dans des applications de production et offrent de nombreuses options d'extensibilité. Avec les storyboards dans Xcode, par exemple, votre code vit à côté de votre éditeur visuel, ce qui vous permet d'étendre facilement ce que propose l'outil visuel seul. Et Xcode vous permet également de coder des interfaces utilisateur à partir de rien (sans storyboard) pour des scénarios avancés.

L'unité est également performante en termes d'extensibilité, car elle offre de nombreux points d'ancrage en C # que vous pouvez contrôler. comment vous voulez que votre application fonctionne.

Chez Progress, nous avons essayé de tirer des leçons des erreurs que d'autres outils ont commises, ainsi que des outils d'approche conviviaux pour les développeurs, tels que Xcode et Offre à l'unité pour construire Kinvey Studio.

Kinvey Studio

Kinvey Studio est un outil de code réduit qui permet aux développeurs de créer rapidement de puissantes applications Web et mobiles.

Nous avons construit Kinvey Studio en tenant compte des limitations de ce type d'outils. Par exemple, Kinvey Studio génère du code propre conçu pour fonctionner rapidement sur le Web, sur iOS et sur Android.

Nous avons également conçu l'extensibilité, toutes les applications de Kinvey Studio s'appuyant sur des technologies open source, telles que Angular, TypeScript et la technologie propre de Progress NativeScript . Le code source brut est toujours disponible dans Studio et nous indiquons clairement quels fichiers sont modifiables par les développeurs.

Enfin, avec Kinvey Studio, vos applications ne sont jamais verrouillées. vos applications reposant sur des technologies à code source ouvert, vous pouvez extraire vos applications de Studio et continuer à les développer avec les outils sur lesquels elles ont été créées (CLI angulaire et NativeScript).

Wraping Up

Low le code a une mauvaise réputation parmi les développeurs, car les outils à faible code sont réputés pour générer de mauvaises applications qui ne sont pas extensibles et vous enfermer.

Mais tous les outils de code faible ne sont pas terribles et les outils qui peuvent éviter ces inconvénients peuvent offre de réels avantages en termes de productivité pour les développeurs. Si vous souhaitez essayer notre approche à ce sujet ici à Progress, téléchargez Kinvey Studio gratuitement pour commencer à créer des applications dès aujourd'hui.

Essayez Kinvey Studio