Fermer

février 28, 2019

Les développeurs ont-ils le droit de se méfier des solutions à code réduit? Partie 2


La partie 1 de cette série explorait la manière dont la solution pour accroître la productivité des développeurs ne devrait pas être l'extrême des boîtes noires, mais une solution à code réduit qui constitue une «boîte ouverte», basée sur des standards ouverts et une solution complète. vue de la source. Dans la deuxième partie, nous examinerons l’architecture de développement dans le contexte des solutions à code faible.

Les solutions à code faible ne souffrent pas seulement de la perception de la «boîte noire» d’une personnalisation difficile ou impossible, mais également de la part des développeurs. leurs architectures – obsolètes, monolithiques et hostiles au déploiement d'applications.

Monoliths: le bon et le plus souvent mauvais

Du point de vue du développement, les avantages des architectures monolithiques, où toute la logique et le code de l'application reposent sur des composants importants et interdépendants , comprennent être simple à développer et à déployer, du moins au début. Cependant, à long terme, ces inconvénients sont contrebalancés par ces avantages. Les services d'applications monolithiques ont tendance à être «étroitement couplés», ce qui rend difficile l'isolation des services à des fins telles que la mise à l'échelle indépendante ou la maintenance du code. Si un composant du programme doit être mis à jour, cela nécessite souvent de réécrire de grandes parties de l'application.

Cela soulève à son tour le spectre du refactoring pour améliorer les performances, la lisibilité, la portabilité ou le respect du code. Une approche monolithique vous met immédiatement dans un cours de refactorisation ou dans le traitement de solutions alternatives proposées souvent par le développeur de logiciel qui tente d'ajouter des fonctionnalités modernes à une architecture obsolète, mais finit par créer un second niveau d'applications.

Monoliths + Low Solutions de code = travail supplémentaire

Les architectures monolithiques communes à de nombreuses solutions à code réduit sont beaucoup plus difficiles à comprendre car il peut exister des dépendances peu apparentes lorsqu’on regarde un service ou un contrôleur individuel, car elles sont intégrées à la solution. Avec de nombreuses solutions à code réduit, vous devez essayer de gérer les travaux de développement, de test et de production d’un monolithe, sans la possibilité de développer, de tester, de déployer et de mettre à l’échelle des composants individuellement. La mise à l'échelle est un défi, car il est impossible d'identifier et de décomposer des pièces spécifiques peu performantes pour les optimiser. La maintenance est une corvée. En effet, même si un monolithe a moins de «pièces en mouvement», il est difficile de les maintenir car ces pièces sont toutes étroitement couplées.

Les développeurs sont conscients de ces limitations et tentent de les éviter.

Alors, quelle est la réponse?

L'idéal serait de disposer des fonctionnalités infonuagiques fournies par AWS ou Azure, associées à la facilité de déploiement en code réduit.

Le développement sur une plate-forme en nuage sans serveur permet à la plate-forme de gérer et mettre à l'échelle automatiquement les microservices et les fonctions. Si vous combinez cela avec un backend Node.js et une interface JavaScript pour Web et mobile, vous disposez d'une option Full-stack. Les avantages sont multiples:

  • La combinaison d’une plate-forme sans serveur et à code réduit construite sur JavaScript permet aux organisations de répondre à la demande en matière d’expériences multicanaux grand public en utilisant les compétences existantes des développeurs
  • Différents développeurs, voire différentes équipes, peuvent travailler sur leur part du marché. application indépendamment sans entrer en conflit avec les modifications apportées par d'autres équipes
  • Les mises à jour peuvent être effectuées sans réécriture ni redéploiement du code de l'application
  • Le code est réutilisable dans toutes les applications et plus facile à gérer car la fonctionnalité est isolée

Les développeurs sont ainsi libérés concentrez-vous sur les fonctionnalités des applications et l'expérience utilisateur, tandis que la plate-forme gère le reste .

Des plates-formes perturbatrices sont arrivées et c'est bon pour le développement

Des fournisseurs traditionnels de codes bas offrant des plates-formes monolithiques sont en cours perturbé par des plateformes à haute productivité conçues pour être basées sur le cloud et basées sur des normes avec la prise en charge d'un serveur dorsal sans serveur d microservices.

Une de ces plateformes perturbatrices à haute productivité est Progress Kinvey .

Kinvey et NativeScript permettent aux développeurs d'utiliser JavaScript, TypeScript, Angular ou Vue.js Une fois pour les applications natives sur plusieurs plates-formes, vous disposez également d'une riche collection de composants d'interface utilisateur. Pendant ce temps, le serveur Kinvey sans serveur backend s'adapte aux niveaux les plus élevés, dispose de la souplesse nécessaire pour prendre en charge les modifications fréquentes et s'intègre facilement aux systèmes d'enregistrement et d'authentification à l'aide d'une approche à code faible basée sur la configuration. L’architecture modulaire d’une application Kinvey exige toujours que les mises à jour de l’application soient testées par régression afin de s’assurer que les modifications ne cassent aucun code dépendant. Cependant, contrairement à un monolithe, cela ne nécessite pas de réécriture importante dans le code de l'application ni le redéploiement de l'application complète.

Une architecture moderne sans serveur assortie des plus hauts niveaux de contrôle des développeurs: voilà la solution pour répondre à la demande sans fin de applications multicanaux grand public.




Source link