Pour commencer : comment fonctionne un logiciel

Bienvenue dans Be Software Architecture Wise, et dans le chapitre zéro : Commencez ici, comment fonctionnent les logiciels. Ce chapitre est la porte d’entrée de tout le cours. Il part du principe que vous avez déjà utilisé des applications et des sites web, mais que vous n’avez jamais écrit de programme. À la fin, vous aurez le vocabulaire sur lequel s’appuie chaque chapitre suivant.

L’architecture logicielle porte sur les grandes décisions d’un système logiciel : quelles sont ses parties principales, comment elles communiquent entre elles, où vivent les données, et quelles qualités, comme la rapidité, la fiabilité et la sécurité, la conception doit atteindre. Ces décisions se prennent dans un vocabulaire : processus et threads, index et caches, interfaces et dépendances, transactions, API et conteneurs. Les architectes emploient ces mots avec précision, il vous faut donc savoir ce que chacun signifie vraiment, et ce qu’il coûte. Ce chapitre est écrit pour quelqu’un qui n’a jamais programmé. Chaque section commence par une analogie de la vie quotidienne avant d’expliquer le mécanisme réel. Si vous êtes déjà ingénieur, vous pouvez le parcourir rapidement comme un vocabulaire commun.

Ce chapitre ne s’appuie sur rien du tout. Il ne suppose aucune formation technique, ce qui en fait le bon point de départ. Il mène directement au chapitre 1, qui utilise ces briques de base pour expliquer ce qu’est l’architecture logicielle, et pourquoi les grandes décisions comptent autant. Lorsqu’un sujet mérite plus de profondeur, le chapitre renvoie à la section ultérieure qui le traite correctement.

Le chapitre compte huit sections, réparties en trois groupes. Les trois premières restent à l’intérieur d’une seule machine. La section zéro point un explique comment le code écrit par des personnes devient des instructions qu’un processeur peut exécuter, et pourquoi les données en mémoire disparaissent au redémarrage. La section zéro point deux présente les structures de données courantes, comme les listes, les dictionnaires et les files. À l’aide de la notation grand O, elle explique pourquoi une façon de retrouver un client reste rapide avec un million de clients, alors qu’une autre s’effondre. La section zéro point trois monte des fonctions aux modules, aux objets et aux interfaces. Elle explique la différence entre une bibliothèque et un framework, met en garde contre le coût caché des dépendances et donne un premier aperçu du couplage et de la cohésion.

Les trois sections suivantes quittent la machine unique. La section zéro point quatre explique comment le DNS transforme des noms en adresses, et comment fonctionnent les requêtes et les réponses HTTP. Elle montre aussi que le délai du réseau a un plancher fixé par la vitesse de la lumière. La section zéro point cinq couvre les fichiers et les bases de données : tables, requêtes SQL, index et transactions, illustrées par un virement bancaire qui ne doit jamais se faire à moitié. Elle présente aussi les principales bases de données non relationnelles, et les cas où chacune convient. La section zéro point six explique comment des systèmes distincts coopèrent grâce aux API. Une API est un contrat. Vous verrez la différence entre attendre une réponse et envoyer un message par une file, et pourquoi casser une API pénalise tous ceux qui en dépendent.

Les deux dernières sections portent sur l’endroit où s’exécutent les logiciels et sur la façon dont on les construit. La section zéro point sept montre ce qu’est vraiment un serveur, comment les machines virtuelles et les conteneurs permettent à de nombreuses charges de travail de partager une même machine physique, et ce que vendent les fournisseurs de cloud. La section zéro point huit passe de la technologie à la pratique : exigences, gestion de versions, tests, intégration et livraison continues, et méthodes de travail. Elle se termine en suivant un appui sur « Commander » dans une app de livraison de repas à travers chaque partie du chapitre.

Ce parcours mérite un premier coup d’œil dès maintenant, car il montre où mène tout le chapitre. Un client a rempli son panier et appuie sur « Commander ». Suivez les numéros. D’abord, le téléphone demande au DNS l’adresse de l’entreprise. Puis il envoie la commande en HTTPS à un équilibreur de charge situé dans la région cloud de l’entreprise, où la connexion sécurisée se termine. L’équilibreur de charge transmet la requête au service des commandes. Ce service appelle un prestataire de paiement externe par son API, puis enregistre la commande dans sa base de données au sein d’une transaction. Ensuite, il dépose un message OrderPlaced dans une file. Un service de notifications le récupère et demande au service push d’Apple ou de Google d’envoyer une notification sur le téléphone du client. Remarquez les flèches en pointillés : cette dernière partie est asynchrone. Si le service de notifications est en panne, les commandes sont quand même prises, et les messages attendent simplement dans la file. Quelqu’un a dû décider cela, et prendre des décisions de ce genre, c’est de l’architecture.

Voici l’idée à retenir de tout le chapitre. Chaque système qu’il présente est construit à partir de parties qui cachent leurs détails derrière une frontière convenue : un module derrière son interface, une base de données derrière SQL, un prestataire de paiement derrière son API. C’est aux frontières que se situent les compromis importants. Un appel de fonction est rapide et fiable, alors qu’un appel à travers le réseau est plus lent et peut échouer. Une dépendance épargne des efforts mais apporte des risques. Un cache fait gagner du temps mais peut servir des données périmées. Décider où placer ces frontières, ce qui les traverse, et quels compromis accepter, c’est cela, l’architecture logicielle. Chaque section se termine par une courte note sur l’importance de son sujet pour l’architecture, alors guettez-les.

Comment l’étudier ? Si le sujet est nouveau pour vous, lisez les sections dans l’ordre, car chacune s’appuie sur la précédente. Si vous en connaissez déjà une partie, piochez dans les sections dont vous avez besoin. La lecture du chapitre entier prend environ trois heures. Chaque section se termine par quelques questions d’autoévaluation. Répondez-y de tête avant de regarder les réponses. Elles vous montrent vite ce que vous avez retenu, et ce qui mérite d’être relu. Quand vous êtes prêt, vous pouvez passer le test facultatif du chapitre : vingt questions à choix multiples et deux réponses rédigées. Comptez environ quarante-cinq minutes. La note de réussite est de quatre-vingts pour cent. Avant de commencer le test, vérifiez que vous savez répondre aux questions d’autoévaluation de chaque section, et relisez le résumé de toute section qui vous semble encore floue.

Voilà la carte du chapitre zéro. Commencez par la section zéro point un, où nous verrons ce qu’est un logiciel, et ce qui se passe réellement quand un ordinateur exécute un programme. À très vite.