Principes et fondamentaux de conception

Bienvenue dans le chapitre 3 : Principes et fondamentaux de conception. Toute architecture repose sur les mêmes quelques idées de structure. Comment diviser un système en parties, ce que ces parties doivent savoir les unes des autres, dans quel sens leurs dépendances doivent pointer, et comment garder l’ensemble aussi simple que le problème le permet. Ce chapitre enseigne ces idées.

Le chapitre 2 a décrit les qualités qu’une architecture doit fournir. La plupart d’entre elles, et la modifiabilité avant tout, dépendent moins d’une technologie particulière que de la structure. Une équipe peut choisir le framework le plus en vogue et se retrouver malgré tout avec un système où chaque changement touche dix endroits. Ces principes sont de vieilles idées. Le masquage de l’information date de mille neuf cent soixante-douze, et la loi de Conway de mille neuf cent soixante-huit. Elles ont survécu parce qu’elles décrivent quelque chose qui ne change pas : le coût d’un changement dépend de la distance qu’il doit parcourir. Ce qui a changé, c’est l’échelle. Le principe qui vous dit de garder privés les champs d’une classe vous dit aussi de garder privée la base de données d’un service. Chaque section montre donc chaque idée deux fois : dans un petit morceau de code, et à l’échelle des composants et des services.

Ce chapitre s’adresse aux développeurs qui veulent raisonner avec précision sur la conception. Il s’adresse aussi aux architectes qui ont besoin d’un vocabulaire commun pour les revues de conception. Savoir lire de courts exemples en Python est utile. Il s’appuie sur les attributs de qualité du chapitre 2, que ces principes aident à atteindre. Il est utile d’avoir lu la section zéro point trois, sur l’organisation du code, et la section deux point six, sur la conception pour le changement. Et il mène au chapitre 4, qui montre comment décrire une structure pour que d’autres puissent la comprendre et la remettre en question.

Les quatre premières sections posent les fondations. La section trois point un se demande ce qu’est un module et où doivent passer ses frontières. David Parnas a montré que diviser un système selon les étapes de traitement échoue, et que le diviser selon les changements probables réussit. La section trois point deux vous donne le vocabulaire pour juger les frontières : les niveaux classiques de couplage et de cohésion, et les formes de couplage qui n’apparaissent qu’entre services. La section trois point trois examine l’interface elle-même : le masquage de l’information, les contrats, les abstractions qui fuient, et pourquoi chaque comportement visible d’une interface populaire finit par faire l’objet d’une dépendance. La section trois point quatre s’intéresse au sens : dans quelle direction doivent pointer les dépendances, comment mesurer la stabilité, comment rompre les cycles, et comment vérifier tout cela automatiquement.

Ce schéma de la section trois point deux montre ce vocabulaire à l’œuvre, dans une vraie refactorisation. À gauche, la conception avant : un module de commandes et un module de facturation. Commandes appelle Facturation directement, en lui passant un indicateur qui choisit l’un de deux comportements. Commandes doit donc connaître cet indicateur, et ne peut pas accepter une commande si Facturation est lent ou en panne. Pire encore, les deux modules utilisent la même table des commandes. Toute modification de sa structure, de ses codes de statut ou de ses règles de TVA doit être faite dans les deux modules à la fois. À droite, la conception après. Commandes publie un événement OrderPlaced vers un courtier de messages, qui transporte exactement les faits dont Facturation a besoin. Facturation s’y abonne, et chaque service possède ses propres données. Le couplage n’a pas disparu : Facturation dépend toujours de la signification de cet événement. Mais il est désormais explicite, étroit et versionné, et c’est ce que signifie un couplage faible en pratique.

Les quatre sections suivantes s’appuient sur ces fondations. La section trois point cinq couvre les cinq principes SOLID, chacun illustré dans le code et entre services, ainsi que les critiques qu’ils suscitent lorsqu’on les applique mécaniquement. La section trois point six présente la connascence, une mesure plus fine du couplage, avec un ensemble clair de règles pour la rendre plus faible et plus locale. La section trois point sept élargit le regard à l’organisation : la loi de Conway, les données qui l’étayent, et l’arithmétique des canaux de communication. La section trois point huit conclut sur la simplicité et la mesure : la complexité qui appartient au problème et celle que nous ajoutons nous-mêmes, le prix du maintien des options ouvertes, et les limites de toutes les métriques.

Voici la loi de Conway en une seule image. À gauche, une organisation. Une équipe du paiement et une équipe du catalogue doivent passer par une équipe commune d’administrateurs de bases de données pour chaque modification de schéma. À droite, le système qu’elles construisent : un service de paiement et un service de catalogue qui lisent et écrivent tous deux dans une base de données partagée. La structure du système reproduit la structure de la communication. Ainsi, quand vous concevez un système, vous concevez aussi qui doit parler à qui, et l’inverse est tout aussi vrai.

Lues ensemble, les huit sections forment un seul argument. Le changement est le coût dominant du logiciel : une bonne structure est donc une structure dans laquelle les changements probables restent locaux. Chaque principe du chapitre est une manière d’y parvenir. C’est aussi pourquoi les principes entrent parfois en conflit, et pourquoi aucun n’est absolu. Le savoir-faire professionnel consiste à se demander, pour un changement probable dans ce système, quelle distance il devrait parcourir, et quel principe raccourcit cette distance au moindre coût.

Si la conception est nouvelle pour vous, suivez les sections dans l’ordre. Chacune commence par une courte explication tirée de la vie quotidienne. La lecture du chapitre entier prend environ trois heures. Si vous êtes un ingénieur expérimenté, vous préférerez peut-être commencer par les exemples commentés, comme la boutique en ligne de la section trois point un, ou le calcul des métriques de la section trois point quatre. Ils sont conçus pour être discutés. Chaque section se termine par quelques questions d’autoévaluation. Répondez-y de tête avant de regarder. Quand vous êtes prêt, passez le test facultatif du chapitre : vingt questions à choix multiples et deux réponses rédigées, en quarante-cinq minutes environ. La note de réussite est de quatre-vingts pour cent.

Voilà la carte du chapitre 3. Commencez par la section trois point un, sur la modularité, où nous verrons comment diviser un système pour que les changements attendus restent à l’intérieur d’une seule partie. À très vite.