Bonjour les amis. En prévision du lancement du cours , partagent traditionnellement avec vous la traduction de matériel utile.
Les logiciels résolvent de plus en plus de tâches quotidiennes, tout en devenant de plus en plus complexes. Comme Marc Andressen l'a dit un jour, cela consume le monde.
En conséquence, la façon dont les applications sont développées et livrées a radicalement changé au cours des dernières années. Ce sont des changements d'échelle tectonique qui ont abouti à un ensemble de principes. Ces principes se sont avérés utiles dans la constitution d'équipes, la conception, le développement et la livraison de votre application aux utilisateurs finaux.
Les principes peuvent être résumés comme suit : l'application doit être petite, basée sur le Web et avoir une architecture centrée sur le développeur. Avec ces trois principes à l'esprit, vous pouvez créer une application robuste de bout en bout qui peut être livrée rapidement et en toute sécurité à l'utilisateur final, et qui est facilement évolutive et extensible.
Chacun des principes proposés comporte un certain nombre d'aspects que nous aborderons pour montrer comment chaque principe contribue à l'objectif ultime, qui est la livraison rapide d'applications fiables, faciles à entretenir et à utiliser. Nous examinerons les principes par rapport à leurs contraires afin de clarifier ce que cela signifie, disons : "Assurez-vous d'utiliser principe de petitesse».
Nous espérons que cet article vous encouragera à utiliser les principes proposés pour créer des applications modernes, qui fourniront une approche unifiée de la conception dans le contexte d'une pile technologique en constante évolution.
En appliquant ces principes, vous vous retrouverez à profiter des dernières tendances en matière de développement de logiciels, y compris le au développement et à la livraison d'applications, l'utilisation de conteneurs (par exemple, ) et les frameworks d'orchestration de conteneurs (par exemple, ), l'utilisation de microservices (y compris l'architecture de microservice и pour les applications de microservices.
Qu'est-ce qu'une application moderne ?
Applications modernes ? Pile moderne ? Que signifie exactement "moderne" ?
La plupart des développeurs n'ont qu'une idée générale de ce en quoi consiste une application moderne, il est donc nécessaire de définir clairement ce concept.
Une application moderne prend en charge plusieurs clients, qu'il s'agisse d'une interface utilisateur de bibliothèque JavaScript React, d'une application mobile Android ou iOS ou d'une application qui se connecte à une autre API. Une application moderne implique un nombre indéfini de clients pour lesquels elle fournit des données ou des services.
Une application moderne fournit une API pour accéder aux données et services demandés. L'API doit être immuable et constante, et non écrite spécifiquement pour une demande spécifique d'un client spécifique. L'API est disponible via HTTP(S) et donne accès à toutes les fonctionnalités disponibles dans l'interface graphique ou la CLI.
Les données doivent être disponibles dans un format interopérable communément accepté tel que JSON. Une API expose des objets et des services de manière propre et organisée, comme l'API RESTful ou GraphQL fournit une interface décente.
Les applications modernes sont construites sur la pile moderne, et la pile moderne est la pile qui prend en charge ces applications, respectivement. Cette pile permet à un développeur de créer facilement une application avec une interface HTTP et des points de terminaison d'API clairs. L'approche choisie permettra à votre application de recevoir et d'envoyer facilement des données au format JSON. En d'autres termes, la pile moderne correspond aux éléments de l'application à douze facteurs pour .
Les versions populaires de ce type de pile sont basées sur , , , , и . Architecture de microservices représente un exemple de pile moderne implémentée dans chacun des langages mentionnés.
Veuillez noter que nous ne préconisons pas une approche exclusivement microservice. Beaucoup d'entre vous travaillent avec des monolithes qui doivent évoluer, tandis que d'autres ont affaire à des applications SOA qui se développent et évoluent pour devenir des applications de microservices. D'autres encore se tournent vers des applications sans serveur, et certains implémentent des combinaisons de ce qui précède. Les principes énoncés dans l'article s'appliquent à chacun de ces systèmes avec seulement quelques modifications mineures.
Principes
Maintenant que nous avons une compréhension commune de ce qu'est une application moderne et une pile moderne, il est temps de plonger dans l'architecture et les principes de développement qui vous seront utiles pour développer, mettre en œuvre et maintenir une application moderne.
L'un des principes ressemble à "créer de petites applications", appelons-le simplement principe de petitesse. Il existe des applications incroyablement complexes composées de nombreuses pièces mobiles. À son tour, la création d'une application à partir de petits composants discrets facilite sa conception, sa maintenance et son utilisation dans son ensemble. (Notez que nous avons dit "simplifie" et non "rend simple").
Le deuxième principe est que nous pouvons augmenter la productivité des développeurs en les aidant à se concentrer sur les fonctionnalités qu'ils développent, tout en les libérant des soucis d'infrastructure et de CI/CD lors de la mise en œuvre. Donc, en un mot, notre approche axé sur les développeurs.
Enfin, tout ce qui concerne votre application doit être connecté au réseau. Au cours des 20 dernières années, nous avons fait de grands progrès vers un avenir en réseau à mesure que les réseaux deviennent plus rapides et les applications plus complexes. Comme nous l'avons déjà vu, une application moderne doit être utilisée sur un réseau par de nombreux clients différents. L'application de la pensée réseau à l'architecture présente des avantages significatifs qui vont bien avec principe de petitesse et le concept de l'approche, orienté développeur.
Si vous gardez ces principes à l'esprit lors de la conception et de la mise en œuvre d'une application, vous aurez un avantage indéniable dans le développement et la livraison de votre produit.
Examinons ces trois principes plus en détail.
Principe de petitesse
Il est difficile pour le cerveau humain de percevoir une grande quantité d'informations en même temps. En psychologie, le terme charge cognitive fait référence à la quantité totale d'effort mental nécessaire pour conserver des informations en mémoire. Réduire la charge cognitive des développeurs est une priorité car cela leur permet de se concentrer sur la résolution du problème au lieu de garder en tête le modèle complexe actuel de l'ensemble de l'application et des fonctionnalités en cours de développement.
Les applications se décomposent pour les raisons suivantes :
- Réduction de la charge cognitive des développeurs ;
- Accélération et simplification des tests ;
- Livraison rapide des changements dans l'application.
Il existe plusieurs façons de réduire la charge cognitive des développeurs, et c'est là que le principe de petitesse entre en jeu.
Voici donc trois façons de réduire la charge cognitive :
- Réduisez le délai qu'ils doivent prendre en compte lors du développement d'une nouvelle fonctionnalité - plus le délai est court, plus la charge cognitive est faible.
- Réduisez la quantité de code sur lequel un travail ponctuel est effectué - moins de code - moins de charge.
- Simplifiez le processus de modification incrémentielle d'une application.
Réduire le temps de développement
Revenons à l'époque où la méthodologie waterfall était la norme pour le processus de développement, et des délais de six mois à deux ans pour développer ou mettre à jour une application étaient une pratique courante. En règle générale, les ingénieurs lisaient d'abord les documents pertinents tels que les exigences du produit (PRD), le document de référence du système (SRD), le plan d'architecture, et commençaient à combiner toutes ces choses ensemble dans un modèle cognitif, selon lequel ils codaient. Comme les exigences et, par conséquent, l'architecture ont changé, un sérieux effort a dû être fait pour informer toute l'équipe des mises à jour du modèle cognitif. Une telle approche, au pire, pourrait simplement paralyser le travail.
Le plus grand changement dans le processus de développement d'applications a été l'introduction de la méthodologie agile. L'une des principales caractéristiques de la méthodologie agile est un développement itératif. Cela conduit à son tour à une réduction de la charge cognitive des ingénieurs. Au lieu d'exiger de l'équipe de développement qu'elle implémente l'application en un seul long cycle, agile Cette approche vous permet de vous concentrer sur de petites quantités de code qui peuvent être rapidement testées et déployées, tout en recevant des commentaires. La charge cognitive de l'application est passée d'une période de six mois à deux ans avec une énorme quantité de spécifications pour un ajout ou un changement de fonctionnalité de deux semaines ciblant une compréhension plus floue d'une grande application.
Passer d'une application massive à de petites fonctionnalités spécifiques qui peuvent être complétées en un sprint de deux semaines, avec pas plus d'une fonctionnalité avant le sprint suivant, est un changement significatif. Cela nous a permis d'augmenter la productivité du développement tout en réduisant la charge cognitive, qui fluctuait constamment.
En méthodologie agile l'application finale devrait être une version légèrement modifiée du concept original, de sorte que le point final du développement est nécessairement ambigu. Seuls les résultats de chaque sprint spécifique peuvent être clairs et précis.
Petites bases de code
La prochaine étape dans la réduction de la charge cognitive consiste à réduire la base de code. En règle générale, les applications modernes sont massives - une application d'entreprise robuste peut être constituée de milliers de fichiers et de centaines de milliers de lignes de code. Selon la façon dont les fichiers sont organisés, les liens et les dépendances entre le code et les fichiers peuvent être évidents, ou vice versa. Même l'exécution du code de débogage lui-même peut être problématique, selon les bibliothèques utilisées et la façon dont les outils de débogage font la distinction entre les bibliothèques/packages/modules et le code personnalisé.
Construire un modèle mental fonctionnel du code d'une application peut prendre un temps impressionnant et, une fois de plus, imposer une charge cognitive importante au développeur. Cela est particulièrement vrai pour les bases de code monolithiques, où il y a une grande quantité de code, dont l'interaction entre les composants fonctionnels n'est pas clairement définie, et la séparation des objets d'attention est souvent floue car les frontières fonctionnelles ne sont pas respectées.
L'un des moyens efficaces de réduire la charge cognitive des ingénieurs est de passer à une architecture de microservices. Dans une approche de microservice, chaque service se concentre sur un ensemble de fonctionnalités ; tandis que le sens du service est généralement défini et compréhensible. Les limites d'un service sont également claires - rappelez-vous que la communication avec un service se fait via une API, de sorte que les données générées par un service peuvent facilement être transmises à un autre.
L'interaction avec d'autres services est généralement limitée à quelques services utilisateur et à quelques services fournisseurs qui utilisent des appels d'API simples et propres, comme l'utilisation de REST. Cela signifie que la charge cognitive de l'ingénieur est sérieusement réduite. Le plus grand défi reste de comprendre le modèle d'interaction de service et comment des choses comme les transactions se produisent sur plusieurs services. Par conséquent, l'utilisation de microservices réduit la charge cognitive en réduisant la quantité de code, en définissant des limites de service claires et en fournissant une compréhension de la relation entre les utilisateurs et les fournisseurs.
Petits changements progressifs
Le dernier élément du principe petitesse est la gestion du changement. C'est une tentation particulière pour les développeurs de regarder la base de code (même peut-être leur propre code plus ancien) et de dire : "C'est de la merde, nous devons tout réécrire". Parfois, c'est la bonne décision, et parfois non. Cela fait peser le fardeau du changement de modèle global sur l'équipe de développement, ce qui entraîne à son tour une charge cognitive massive. Il est préférable que les ingénieurs se concentrent sur les modifications qu'ils peuvent apporter pendant le sprint, afin de pouvoir déployer les fonctionnalités nécessaires en temps opportun, bien que progressivement. Le produit final doit ressembler à celui pré-planifié, mais avec quelques modifications et tests pour répondre aux besoins du client.
Lors de la réécriture de grandes portions de code, il n'est parfois pas possible de livrer rapidement le changement car d'autres dépendances du système entrent en jeu. Afin de contrôler le flux des modifications, vous pouvez utiliser le masquage des fonctionnalités. En principe, cela signifie que la fonctionnalité est en production, mais qu'elle n'est pas disponible à l'aide des paramètres de variable d'environnement (env-var) ou d'un autre mécanisme de configuration. Si le code a passé tous les processus de contrôle qualité, il peut se retrouver en production dans un état latent. Cependant, cette stratégie ne fonctionne que si la fonctionnalité est finalement activée. Sinon, cela ne fera qu'encombrer le code et ajouter une charge cognitive que le développeur devra gérer pour être productif. La gestion des changements et les changements incrémentiels eux-mêmes aident à maintenir la charge cognitive des développeurs à un niveau abordable.
Les ingénieurs doivent surmonter de nombreuses difficultés même avec la simple introduction de fonctionnalités supplémentaires. De la part de la direction, il serait prudent de réduire la charge inutile de l'équipe afin qu'elle puisse se concentrer sur les éléments fonctionnels clés. Il y a trois choses que vous pouvez faire pour aider votre équipe de développement :
- Utiliser la méthodologie
agilepour limiter le délai dans lequel l'équipe doit se concentrer sur les fonctionnalités clés. - Implémentez votre application en tant que plusieurs microservices. Cela limitera le nombre de fonctionnalités pouvant être implémentées et renforcera les frontières qui maintiennent la charge cognitive au travail.
- Préférez les modifications incrémentielles aux changements volumineux et encombrants, modifiez de petits morceaux de code. Utilisez le masquage des fonctionnalités pour implémenter les modifications même si elles ne seront pas visibles immédiatement après leur ajout.
Si vous appliquez le principe de petitesse dans votre travail, votre équipe sera beaucoup plus heureuse, mieux concentrée sur la mise en œuvre des fonctionnalités nécessaires et plus susceptible de déployer des changements qualitatifs plus rapidement. Mais cela ne signifie pas que le travail ne peut pas devenir plus compliqué, parfois, au contraire, l'introduction de nouvelles fonctionnalités nécessite la modification de plusieurs services, et ce processus peut être plus difficile que similaire dans une architecture monolithique. Dans tous les cas, les avantages de l'approche de la petitesse en valent la peine.
La fin de la première partie.
Bientôt, nous publierons la deuxième partie de la traduction, et maintenant nous attendons vos commentaires et vous invitons à , qui aura lieu aujourd'hui à 20.00hXNUMX.
Source: habr.com