Simplicité, réversibilité et mesure de la structure

Deux types de complexité

Dans « No Silver Bullet: Essence and Accidents of Software Engineering » (présenté au congrès mondial de l’informatique de l’IFIP en 1986 et publié dans IEEE Computer en 1987), Fred Brooks a séparé les difficultés de la construction du logiciel en deux types. La complexité essentielle appartient au problème : les vraies règles de la TVA, la vraie diversité des produits d’assurance, les vraies façons dont une livraison peut échouer. Aucune conception ne peut l’éliminer sans changer ce que fait le système. La complexité accidentelle vient de la manière dont nous construisons la solution : langages, outils, frameworks, mécanismes de déploiement, contournements, et une structure plus compliquée que ne l’exige le problème. Brooks soutenait que les langages de haut niveau et d’autres progrès avaient déjà éliminé une grande partie de la difficulté accidentelle, si bien qu’aucune nouvelle technique isolée n’apporterait un gain d’un facteur dix en une décennie.

Pour les architectes, cette distinction est un outil quotidien. La complexité essentielle doit être placée : mettez-la là où les personnes qui la comprennent peuvent y travailler, derrière une frontière qui l’empêche de se répandre partout ailleurs (un module de tarification, un service fiscal). La complexité accidentelle doit être éliminée ou évitée : chaque service, file d’attente, cache, couche d’abstraction et option de configuration supplémentaire en ajoute, et chacun doit mériter sa place en résolvant un vrai problème. L’essai de Ben Moseley et Peter Marks « Out of the Tar Pit » (2006) a poussé l’idée plus loin en désignant l’état mutable et le flux de contrôle comme des sources majeures de complexité accidentelle, ce qui explique en partie la popularité des conceptions fonctionnelles et pilotées par les événements qui limitent l’état partagé.

Le reste de cette section présente les principes qui contiennent la complexité accidentelle (KISS, YAGNI, DRY bien compris, réversibilité) et les mesures qui vous aident à voir la structure de façon objective, avec leurs limites.

KISS et YAGNI

KISS, généralement développé en « keep it simple, stupid » (« reste simple, idiot »), est une maxime de conception attestée dans l’US Navy en 1960 et associée à Kelly Johnson, l’ingénieur en chef des Skunk Works de Lockheed, qui aurait exigé que les avions à réaction puissent être réparés sur le terrain par un mécanicien moyen muni d’une poignée d’outils. La lecture logicielle est la même : une conception est bonne si les personnes qui doivent l’exploiter et la réparer, souvent à 3 h du matin et sous pression, peuvent la comprendre. Simple ne veut pas dire facile ni naïf. Cela signifie peu de concepts, peu de pièces mobiles et peu de cas particuliers pour le problème à résoudre.

YAGNI (« you aren’t gonna need it », « vous n’en aurez pas besoin ») vient de l’Extreme Programming, à la fin des années 1990 : ne construisez pas de capacités pour des besoins seulement présumés. L’analyse de Martin Fowler est utile, car elle nomme les coûts liés au non-respect de ce principe. Il y a le coût de construction de la fonctionnalité présumée ; le coût du retard, parce qu’une chose utile n’a pas été construite à la place ; le coût de maintien, parce que chaque modification ultérieure doit composer avec le code supplémentaire ; et, si l’hypothèse était fausse, le coût de réparation. Même quand l’hypothèse s’avère juste, la fonctionnalité a été construite avec moins de connaissances que vous n’en auriez eu plus tard.

Deux nuances empêchent YAGNI de devenir une excuse. D’abord, il s’applique aux fonctionnalités et à la flexibilité spéculative, pas aux pratiques qui rendent le changement peu coûteux. Les tests automatisés, la refactorisation, la livraison continue et des frontières de modules claires sont ce qui permet de reporter des fonctionnalités en toute sécurité ; les abandonner au nom de YAGNI transforme le report en dette. Ensuite, certaines décisions sont des portes à sens unique (section 1.6). Choisir un modèle de données, la forme d’une API publique, un modèle de multilocation ou une frontière de sécurité n’est pas une fonctionnalité que l’on peut ajouter plus tard au même coût. Pour ces décisions, anticiper n’est pas de la spéculation : c’est le travail de l’architecte.

DRY porte sur la connaissance, pas sur le texte

Andy Hunt et Dave Thomas ont introduit DRY dans The Pragmatic Programmer (1999 ; édition du 20e anniversaire en 2019) avec cette définition : Chaque élément de connaissance doit avoir une représentation unique, non ambiguë et faisant autorité au sein d’un système. Le mot clé est connaissance. Si le taux de TVA, la règle de validité d’un code postal ou la signification d’un statut de commande est écrit à plusieurs endroits, le modifier exige de retrouver chaque copie, et les copies divergeront. L’édition de 2019 souligne que DRY porte sur la duplication de la connaissance et de l’intention, pas sur des lignes de code qui se trouvent se ressembler.

Le mauvais usage courant va dans l’autre sens. Deux fonctions qui se ressemblent sont fusionnées parce qu’elles se ressemblent, alors qu’elles représentent des connaissances différentes qui changeront pour des raisons différentes : la règle des frais de livraison et la règle de commission des restaurants multiplient toutes deux un total par un pourcentage aujourd’hui, mais elles relèvent d’acteurs différents (la finance et les partenariats) et divergeront. Les fusionner couple deux concepts que le domaine sépare : les deux dépendent désormais d’une seule fonction partagée, si bien qu’une modification demandée pour l’une change l’autre en silence. Dans les termes de la section 3.6, cela crée une connascence là où le problème n’en a aucune (partager une fonction n’est le bon remède que si les deux côtés doivent réellement calculer la même chose) ; c’est aussi une violation de la responsabilité unique (section 3.5). Le conseil bien connu de Sandi Metz est de préférer la duplication à la mauvaise abstraction, car une mauvaise abstraction partagée accumule paramètres et conditions jusqu’à ce que personne n’ose plus la modifier. Beaucoup d’équipes appliquent la règle de trois : tolérer une deuxième copie, et extraire une abstraction quand la troisième apparaît et que la connaissance commune est claire.

À l’échelle de l’architecture, le compromis devient explicite. Une bibliothèque partagée que chaque service doit utiliser supprime le code dupliqué, mais couple les cycles de mise en production des services. Beaucoup d’organisations à microservices acceptent délibérément du code dupliqué (de petits utilitaires copiés dans chaque service) tout en exigeant un responsable unique pour la connaissance dupliquée (la fiche client de référence, les règles fiscales). Posez la question pour toute duplication : si cette règle change, toutes les copies doivent-elles changer ensemble ? Si oui, c’est de la connaissance dupliquée, qui doit avoir un seul responsable. Si non, c’est une ressemblance fortuite, qui peut rester.

La réversibilité et le coût des options

La simplicité a une dimension temporelle. Une conception simple aujourd’hui mais impossible à modifier n’est pas bon marché ; une conception pleine d’une flexibilité que personne n’utilise ne l’est pas non plus. Le concept utile est la réversibilité : combien coûterait-il d’annuler ou de modifier cette décision plus tard ? La section 1.6 a présenté les portes à sens unique et à double sens. Ici, l’idée est que la flexibilité se comporte comme une option financière : elle a un prix maintenant (code supplémentaire, abstraction supplémentaire, coût d’exploitation supplémentaire) et une valeur qui dépend de la probabilité et du coût du changement contre lequel elle protège.

Cela donne une règle empirique qui concilie YAGNI et anticipation. Ne payez une option que si le changement est raisonnablement probable, ou s’il serait très coûteux sans l’option, et si l’option elle-même est bon marché. Envelopper un prestataire de paiement derrière une interface qui vous appartient coûte une journée et protège contre un changement à la fois plausible et coûteux : c’est une bonne option. Construire une couche d’abstraction multicloud pour une start-up qui n’a qu’un client est une option coûteuse contre un changement improbable. Souvent, l’option la moins chère est simplement une bonne modularité : des frontières bien placées gardent de nombreux changements futurs locaux sans que personne ait à les prédire, ce qui est l’argument originel de Parnas en faveur du masquage de l’information (section 3.1).

Mesurer la structure : la complexité cyclomatique

Le jugement sur la simplicité s’améliore quand il s’appuie sur la mesure. La plus ancienne métrique de code largement utilisée est la complexité cyclomatique, introduite par Thomas McCabe dans « A Complexity Measure » (IEEE Transactions on Software Engineering, 1976). Elle traite une fonction comme un graphe de flot de contrôle, avec des nœuds pour les blocs de code et des arêtes pour les transferts de contrôle possibles, et compte les chemins linéairement indépendants qui le traversent : M = E − N + 2P, où E est le nombre d’arêtes, N le nombre de nœuds et P le nombre de composantes connexes (1 pour une seule fonction). Pour du code structuré avec un seul point d’entrée, cela équivaut au nombre de points de décision plus un.

McCabe suggérait 10 comme limite supérieure raisonnable pour un module. Le rapport ultérieur du NIST sur le test structuré, d’Arthur Watson et McCabe (1996), note que des limites allant jusqu’à 15 ont été utilisées avec succès par des équipes expérimentées, et recommande une explication écrite chaque fois qu’un module dépasse la limite choisie. Des outils d’analyse statique comme radon ou le plugin mccabe pour flake8 en Python, la règle complexity d’ESLint en JavaScript et SonarQube la calculent automatiquement. Les outils diffèrent sur des détails, par exemple selon que chaque and ou or d’une condition compte ou non comme une décision supplémentaire : comparez donc des chiffres issus du même outil.

def delivery_fee(total: int, distance_km: float, priority: bool) -> int:
    if total >= 2500:          # decision 1: free delivery over 25 pounds
        return 0
    fee = 299
    if distance_km > 5:        # decision 2
        fee += 100
    if priority:               # decision 3
        fee += 200
    return fee

Mesurer la structure au-delà des fonctions

La complexité cyclomatique ne voit qu’une fonction à la fois. Les architectes ont besoin de mesures des relations entre modules.

Métriques de couplage et de stabilité. La section 3.4 (gérer les dépendances) a présenté le couplage afférent et efférent, l’instabilité I = Ce / (Ca + Ce), le degré d’abstraction et la distance à la séquence principale. Ces métriques se calculent à peu de frais à partir des graphes d’imports ; elles révèlent bien les composants dont beaucoup d’autres dépendent mais qui dépendent eux-mêmes de code volatil, et détectent les cycles de dépendances.

Métriques de cohésion. La famille LCOM (manque de cohésion des méthodes) estime si une classe porte une seule responsabilité ou plusieurs. La version originale de Shyam Chidamber et Chris Kemerer (1994) compare des paires de méthodes selon qu’elles utilisent ou non des champs communs. Une variante ultérieure très répandue, LCOM4, de Martin Hitz et Behzad Montazeri, construit un graphe dans lequel les méthodes sont reliées si elles partagent un champ ou si l’une appelle l’autre, puis compte les groupes connexes. Une classe avec LCOM4 = 1 est cohérente ; une classe avec LCOM4 = 3 est en réalité trois classes qui partagent un fichier. Par exemple, une classe Customer dont update_address et format_address utilisent les champs d’adresse, dont add_points et points_balance utilisent les champs de fidélité, et dont send_newsletter n’utilise que le champ e-mail a un LCOM4 = 3, ce qui suggère des responsabilités d’adresse, de fidélité et de marketing.

Métriques fondées sur l’historique. Le contrôle de version enregistre la façon dont le système change réellement, ce que l’analyse statique ne peut pas voir. Le couplage de changement repère les fichiers ou les services qui sont régulièrement commités ensemble : si pricing.py et invoice_template.html changent ensemble dans 70 % des commits, ils sont couplés, que l’un importe l’autre ou non, et ce couplage peut franchir une frontière de service censée les séparer. Les hotspots (points chauds) combinent la fréquence des changements et la complexité pour repérer le code à la fois difficile à manipuler et fréquemment modifié ; Your Code as a Crime Scene d’Adam Tornhill (2015 ; deuxième édition en 2024) a popularisé cette technique. La section 1.7, consacrée à la dette technique, a montré comment les hotspots orientent le remboursement vers la dette qui coûte le plus d’intérêts.

La loi de Goodhart et les limites des métriques

Chacune des métriques ci-dessus est un indicateur indirect de quelque chose qui nous importe mais que nous ne pouvons pas mesurer directement : la facilité à comprendre et à modifier le système. La loi de Goodhart, nommée d’après l’économiste Charles Goodhart (1975) et surtout connue dans la formulation de l’anthropologue Marilyn Strathern en 1997, avertit que lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure. Les gens optimisent le chiffre, pas la propriété.

Les équipes logicielles le constatent sans cesse. Une limite stricte de complexité cyclomatique à 10 produit des fonctions découpées à des endroits arbitraires, qui passent chacune la vérification tandis que la logique devient plus difficile à suivre. Un objectif de couverture de 80 % produit des tests qui exécutent du code sans rien vérifier. Une règle interdisant à toute classe de dépasser 200 lignes produit des classes scindées en OrderHelper et OrderHelper2. Un objectif « zéro cycle » peut être atteint en déplaçant du code dans un paquet fourre-tout common dont tout dépend.

Les professionnels utilisent les métriques de trois manières qui résistent à la manipulation. Ils regardent les tendances plutôt que des seuils absolus (la complexité du module de paiements a doublé en six mois : pourquoi ?). Ils utilisent les métriques pour lancer des discussions et prioriser les revues, pas pour noter les personnes. Et ils combinent des métriques qui tirent dans des directions différentes, comme la complexité avec la fréquence des changements, ou le couplage avec la responsabilité des équipes, afin qu’aucun chiffre isolé ne puisse être optimisé au détriment des autres.

Fonctions d’aptitude : rendre la structure vérifiable

Certaines règles structurelles sont assez claires pour être automatisées, et elles cessent alors de dépendre de la vigilance. Building Evolutionary Architectures de Neal Ford, Rebecca Parsons et Patrick Kua (2017 ; deuxième édition en 2022 avec Pramod Sadalage) appelle ces vérifications des fonctions d’aptitude (fitness functions) : des tests objectifs et automatisés d’une caractéristique architecturale, exécutés dans le pipeline de build ou sur le système en fonctionnement. Exemples pour la structure : aucun cycle de dépendances entre les paquets de premier niveau ; le paquet du domaine n’importe rien des paquets web ou base de données ; aucune fonction au-dessus d’une complexité de 15 sans dérogation explicite ; aucun service ne lit les tables de base de données d’un autre service.

Des outils comme ArchUnit (Java), import-linter (Python) et dependency-cruiser (JavaScript et TypeScript) expriment ces règles sous forme de code ; la section 3.4 en a donné des exemples. La différence avec une métrique de tableau de bord est qu’une fonction d’aptitude encode une décision que l’équipe a déjà prise : l’enfreindre fait échouer le build et impose un choix conscient, corriger le code ou modifier la règle en consignant pourquoi. Le traitement complet, y compris les fonctions d’aptitude pour les performances, la sécurité et d’autres qualités, se trouve dans Fonctions d’aptitude et architecture évolutive.

[importlinter]
root_package = shop

[importlinter:contract:domain-is-pure]
name = Domain must not depend on infrastructure
type = forbidden
source_modules =
    shop.domain
forbidden_modules =
    shop.infrastructure
    shop.web