- Just Enough Software Architecture de George Fairbanks part du constat qu’il est difficile de concevoir de bons systèmes orientés objet et de bonnes architectures avec la seule connaissance de la syntaxe d’un langage ou d’UML
- Son idée centrale est l’architecture pilotée par les risques : éviter la surconception quand le risque est faible, et appliquer des techniques plus rigoureuses face aux risques qui menacent la réussite
- L’architecture y est traitée non comme le domaine réservé de quelques spécialistes, mais comme une compétence que tous les développeurs doivent comprendre, en expliquant l’effet des contraintes et des petits changements sur les propriétés du système
- Plutôt que les processus de développement ou le fonctionnement des organisations, le livre se concentre sur les techniques d’ingénierie, afin de traiter les compromis de conception des problèmes moyens à grands au moyen de la modélisation et de l’analyse d’architecture
- L’ouvrage est structuré en deux parties, l’architecture logicielle pilotée par les risques et la modélisation d’architecture, et traite d’abstractions comme les modèles de domaine, de conception et de code, l’encapsulation, les composants et les connecteurs
Des compétences de conception qui ne se limitent pas aux langages et à UML
- L’auteur part de l’idée de créer le livre dont il aurait eu besoin lorsqu’il a commencé le développement logiciel
- À l’époque, il existait des livres sur les langages de programmation ou la programmation orientée objet, mais peu d’ouvrages traitaient de conception
- Connaître les fonctionnalités du langage C++ ne suffit pas à concevoir de bons systèmes orientés objet, et connaître UML ne suffit pas non plus à concevoir une bonne architecture de système
Adapter l’architecture aux risques
- Le cœur du livre est le risk-driven architecting
- Quand le risque est faible, une conception détaillée n’est pas nécessaire ; quand un risque menace la réussite, une conception approximative ne suffit pas
- Plusieurs défenseurs d’Agile considèrent qu’un peu de conception en amont peut être utile, et ce livre explique comment réaliser une « architecture juste suffisante »
- Il invite à éviter les processus « one size fits all » et à ajuster les efforts d’architecture et de conception en fonction des risques rencontrés
- La plupart des techniques peuvent être modulées, d’un niveau quick-and-dirty jusqu’à un niveau très rigoureux
Faire de l’architecture un langage commun à tous les développeurs
- Le livre a pour objectif de démocratiser l’architecture
- Une organisation peut compter des architectes logiciels, et le lecteur peut lui-même être architecte
- Beaucoup d’architectes souhaitent que tous les développeurs comprennent l’architecture
- Si les développeurs ne comprennent pas les raisons des contraintes ni l’effet de petits changements sur les propriétés du système, leurs jugements de conception peuvent vaciller
- L’architecture n’est pas un sujet réservé aux architectes : elle concerne tous les développeurs logiciels
Connaissances procédurales et connaissances déclaratives
- Le livre vise à développer les connaissances déclaratives
- Être capable de frapper une balle de tennis et savoir pourquoi on y parvient sont deux choses différentes ; cela correspond à la différence entre connaissances procédurales et connaissances déclaratives
- Si vous êtes déjà un expert qui conçoit et construit des systèmes, vous avez peut-être déjà utilisé plusieurs des techniques du livre
- Le livre aide à mieux reconnaître ce que vous faisiez déjà et donne des noms aux concepts
- Ce type de connaissance déclarative aide à mieux accompagner les développeurs débutants
Se concentrer sur l’ingénierie plutôt que sur le processus
- Les personnes qui conçoivent et construisent des systèmes logiciels doivent gérer en même temps de nombreux sujets : planning, engagement de ressources, besoins des parties prenantes, etc.
- De nombreux livres sur l’architecture logicielle traitent déjà des processus de développement et des structures organisationnelles
- Celui-ci se concentre au contraire sur la partie technique du développement logiciel et sur l’ingénierie nécessaire pour faire fonctionner les systèmes
- Il permet de créer des modèles et d’analyser l’architecture afin de faire des compromis de conception fondés sur des principes
- Il explique des techniques utilisées pour raisonner sur des problèmes moyens à grands, et indique aussi où approfondir des techniques spécialisées
Une conception pratique qui circule entre plusieurs niveaux d’abstraction
- Le livre traite l’architecture comme une activité de conception pratique
- L’architecture logicielle est une forme de conception logicielle ; les décisions de conception influencent l’architecture, et l’architecture influence aussi la conception
- Les excellents développeurs explorent en détail les obstacles pour les comprendre, puis relient leur nature à l’architecture globale
- Pour refléter ce comportement de drill-down/pop-up, le livre traite des modèles à plusieurs niveaux d’abstraction, de l’architecture jusqu’à la conception des structures de données
Structure et formats proposés
- Le livre est composé de deux parties
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- Certains chapitres d’exemple peuvent être téléchargés dans un seul PDF
- L’e-book est vendu sur Google Play ; il inclut trois formats sans DRM, ePub, Mobi et PDF, et coûte 9,99 $
- L’édition reliée est disponible sur Amazon
- Google Books et Amazon Search Inside proposent des versions interrogeables en texte intégral
Périmètre traité et périmètre exclu
- Le livre se concentre sur l’architecture logicielle liée à la construction de logiciels
- Il explique des techniques permettant de faire en sorte qu’un logiciel satisfasse les exigences d’ingénierie
- Comme les techniques d’ingénierie elles-mêmes sont généralement indépendantes des processus, le livre est lui aussi en grande partie indépendant de tout processus
- Il ne traite pas les conseils de gestion suivants
- Les responsabilités politiques de l’architecte
- Le moment où organiser certains types de réunions
- La manière de recueillir les exigences auprès des parties prenantes
Part I: Architecture logicielle pilotée par les risques
- Il est difficile de définir précisément l’architecture logicielle, mais certaines de ses caractéristiques sont claires
- Les développeurs logiciels, comme les ingénieurs d’autres disciplines, utilisent des abstractions et des modèles pour résoudre des problèmes vastes et complexes
- L’architecture logicielle agit comme le squelette d’un système et influence les attributs de qualité ; elle est orthogonale aux fonctionnalités et influence les propriétés du système au moyen de contraintes
- L’architecture est particulièrement importante dans les situations suivantes
- Quand l’espace des solutions est réduit
- Quand le risque d’échec est élevé
- Quand il faut répondre à des exigences difficiles en matière d’attributs de qualité
- Il est possible de choisir entre plusieurs approches de conception : architecture-indifferent design, architecture-focused design et architecture hoisting
- La procédure centrale du modèle piloté par les risques est simple
- Identifier et prioriser les risques
- Choisir et appliquer un ensemble de techniques
- Évaluer la réduction des risques
- Le chapitre 4 montre l’application du modèle piloté par les risques à travers l’exemple d’un système Home Media Player
- Communication au sein de l’équipe
- Intégration de composants COTS
- Garantie de cohérence des métadonnées
- La Part I se conclut par des conseils sur l’utilisation des modèles et de l’architecture logicielle
- Utiliser des modèles pour résoudre les problèmes
- Ajouter les contraintes avec discernement
- Se concentrer sur les risques
- Répartir la compétence d’architecture dans toute l’équipe
Part II: Modélisation d’architecture
- La Part II vise à aider à former un modèle conceptuel de l’architecture logicielle
- La structure de modèle de base comprend trois types
- Modèle de domaine : correspond aux objets du monde réel
- Modèle de conception : représente la conception du logiciel en cours de construction
- Modèle de code : correspond au code source
- Il est possible de créer des vues (views), des modèles supplémentaires qui montrent certains détails choisis, et ces vues peuvent être regroupées par viewtype
- La création de frontières d’encapsulation est une technique importante en architecture logicielle
- Les utilisateurs d’un composant ou d’un module peuvent ignorer son fonctionnement interne et se concentrer sur d’autres problèmes difficiles
- Les auteurs d’un composant ou d’un module encapsulé gagnent la liberté de modifier l’implémentation sans perturber les utilisateurs
- Cette liberté n’est possible que lorsque l’encapsulation est efficace ; le livre traite donc des techniques permettant de la garantir
- Le livre intègre des techniques d’architecture logicielle issues de plusieurs sources
- Techniques mettant l’accent sur les attributs de qualité
- Techniques mettant l’accent sur les fonctionnalités
- Méthodes pratiques pour créer des modèles efficaces
- Méthodes pour déboguer les modèles
- La Part II donne des conseils pour utiliser efficacement les modèles et traite également des pièges que l’on peut rencontrer avec cette technique
- L’objectif final est de disposer d’un modèle conceptuel riche des abstractions et des relations, et de pouvoir regarder un système logiciel comme un entraîneur regarde un match
1 commentaires
Avis de Hacker News
On dit parfois qu’il faut distinguer le risque de gestion de projet — « un développeur clé se fait renverser par un bus » — du risque d’ingénierie logicielle — « le serveur pourrait ne pas passer à l’échelle jusqu’à 1 000 utilisateurs » —, mais d’après mon expérience, ils ne sont pas si rarement séparés
La qualité et la structure du code, les tests et la documentation, ainsi que l’utilisation d’outils standard et bien connus, aident dans les deux cas
J’ai donc plusieurs fois évoqué auprès de collègues ou de responsables l’hypothèse « et si tu te faisais renverser par un bus ? », ce qui devient un moyen de pression pour produire un logiciel reproductible et compréhensible
Pour éviter la connotation négative de blessure ou de mort, il vaut mieux dire « et si tu gagnais au loto ? »
Le cœur de « se faire renverser par un bus », c’est qu’il n’y a absolument aucun temps pour se préparer, indépendamment de la personnalité de la personne, et cela crée donc une pression pour partager l’information dès aujourd’hui
Malheureusement, je n’ai pas encore trouvé d’expression positive ayant la même implication
Les deux sont revenus environ une semaine plus tard, donc il faut un autre exemple standard de catastrophe
Pour faire passer l’idée, j’emploie plus souvent l’expression « la personne suivante »
Le pire scénario, c’est le burnout : l’effectif reste le même, mais mentalement, la personne est déjà partie
J’ai vu beaucoup d’entreprises incapables de tenir même ce délai, sans qu’il soit question d’un départ définitif
On peut aussi employer une formulation comme « augmenter le facteur bus », qui met l’accent sur la motivation à éliminer les points de défaillance uniques
Si l’on fait une analyse des causes racines, il ne faut pas s’arrêter à « Larry s’est fait renverser par un bus / a gagné au loto » : ce n’est pas le vrai problème
L’architecture pour l’architecture est ce qu’il y a de pire, car elle augmente inutilement la complexité
L’objectif ultime d’une bonne architecture est de réduire les coûts
Si l’architecture fait qu’il faut plus de temps pour développer et maintenir le code, alors cette architecture est un échec
C’est toujours une question de compromis
Il n’existe donc pas une architecture correcte unique : le choix dépend du contexte et doit parfois être réévalué
La flexibilité est particulièrement utile, car elle permet d’ajuster l’architecture dans une certaine mesure et de conserver l’efficacité même lorsque le contexte change
La réduction des coûts peut en faire partie
« Le modèle piloté par les risques amène les développeurs à appliquer le minimum de techniques d’architecture nécessaire pour réduire les risques les plus urgents. C’est un processus qui consiste à demander sans relâche : “Quels sont mes risques ? Quelle est la meilleure technique pour les réduire ? Les risques ont-ils été atténués, et puis-je maintenant commencer ou reprendre le codage ?” Le modèle piloté par les risques peut se résumer en trois étapes : 1. identifier les risques et les prioriser 2. choisir et appliquer un ensemble de techniques 3. évaluer la réduction des risques »
On ne veut ni perdre du temps avec des techniques à faible impact, ni ignorer des risques qui menacent le projet
Pour construire un système réussi, il faut choisir la voie qui utilise le temps le plus efficacement, ce qui signifie n’appliquer des techniques d’architecture et de conception pour traiter les risques que lorsque ces risques en sont la motivation
Par exemple, « l’architecture » inclut aussi l’utilisation d’un style client-serveur où le serveur ne prend pas l’initiative et se contente de répondre aux requêtes du client
Cette approche peut être bien adaptée au problème, ou non
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
Des architectes techniques très bien payés finissent par imposer, sans faire grand-chose eux-mêmes, des patterns horribles que les ingénieurs logiciel doivent résoudre sous des contraintes déraisonnables comme les délais
Une bonne architecture permet à davantage de personnes de contribuer au produit
S’il a été publié en 2010, je me demande à quel point il a survécu depuis
J’aime bien Design It parce qu’il propose de bons ateliers et activités pour les techniciens qui doivent interagir avec des parties prenantes ou des clients
C’est d’autant plus pertinent pour un rôle de conseil, et j’apprécie aussi le fait qu’il ne s’appuie pas trop sur des styles d’architecture liés à des technologies particulières qui changent souvent
Je parle en termes de vrais principes, pas de modes
L’auteur consacre beaucoup de temps à des essais sur l’état d’esprit et traite légèrement les techniques concrètes, mais il fournit des pistes pour aller plus loin
Il amène l’équipe à manipuler des idées d’architecture à travers des activités concrètes, et finit par faire apparaître ce qui compte vraiment
Mon livre essayait d’aborder frontalement ces grandes idées, mais il s’est avéré que le sujet est si abstrait qu’il est difficile sur le plan pédagogique
Quelles idées ont survécu depuis 2010 ? Certains systèmes d’exploitation sont à micro-noyau, d’autres sont monolithiques
Certaines bases de données sont relationnelles, d’autres centrées sur les documents
Certaines applications sont client-serveur, d’autres pair à pair
Ces distinctions sont probablement durables, et si l’on revenait dans 100 ans, même si des exemples comme Windows, Oracle ou Salesforce avaient disparu, on verrait encore des systèmes conçus ainsi
Et nous parlerions encore de qualités comme la facilité de modification ou la latence
Le domaine de l’architecture logicielle consiste à identifier ces abstractions durables
On en trouve une description concise en [2]
« Résumé : l’architecture logicielle est un ensemble d’abstractions qui aident à raisonner sur un logiciel que l’on prévoit de construire ou que l’on a déjà construit. Notre discipline dispose depuis longtemps de petites abstractions, mais il a fallu des décennies pour accumuler des abstractions plus larges comme les attributs de qualité, l’encapsulation de l’information, les composants et connecteurs, les points de vue multiples, et les styles architecturaux. Lorsque nous concevons un système, nous tissons ces abstractions entre elles pour préserver la chaîne d’intentionnalité et faire en sorte que le système conçu fasse ce que nous voulons. Il y a 20 ans, Martin Fowler publiait dans ce magazine l’article influent “Who Needs an Architect?”. Il est temps que les développeurs regardent à nouveau l’architecture logicielle et la voient comme un ensemble d’abstractions permettant de raisonner sur le logiciel »
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
A Philosophy of Software Design de John Ousterhout m’a été utile
Il contient beaucoup de conseils solides, faciles à comprendre, et de nombreux exemples
Je ne connais pas ce livre lui-même, mais je connais les articles de l’auteur sur l’Intellectual Control, et ils sont très éclairants
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
Dans mon ancienne entreprise, on se passait le livre Software Architecture for Developers de Simon Brown : https://leanpub.com/b/software-architecture
Il est encore seulement dans ma liste de lecture et j’ai quitté cette entreprise, mais on me l’avait vivement recommandé
Cette entreprise documentait aussi son architecture avec le modèle C4
Je me demande si quelqu’un ici l’a lu
Ses conférences sur l’architecture [1] et ses ateliers sont particulièrement efficaces, et le langage de modélisation d’architecture C4 [2] gagne réellement en traction
J’ai aussi des vidéos YouTube [3], mais elles ne sont pas aussi efficaces
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
Je pense que « dépendante du risque » aurait été un bien meilleur nom pour cette méthodologie
Pourquoi les programmeurs aiment-ils autant les expressions du type « piloté par [X] » ?
Cet axe entraîne cet engrenage, qui entraîne cette roue, et ainsi de suite
C’est une façon abrégée de dire « quel est le mécanisme le plus puissant dans cette machine de pensée complexe »
Il y a quelques années, nous avions fait un club de lecture sur ce livre dans mon entreprise, et je l’avais trouvé très répétitif
Je me demande si ce livre est une bonne ressource pour quelqu’un qui démarre un projet open source non trivial
Ou s’il a de la valeur pour un fondateur solo ; j’aimerais qu’on me recommande des livres ou d’autres ressources utiles pour un développeur solo
L’architecture logicielle ressemble à l’architecture au sens bâtiment, mais comme le logiciel n’a pas encore eu de figure à la Isaac Newton, c’est comme si le génie civil n’existait pas encore.
Jusqu’ici, la figure qui s’en rapproche le plus est, à mon avis, Claude Shannon.
Parce qu’on n’a même pas d’unité de mesure.
En génie logiciel, nous en sommes encore au stade où l’on « espère que ça ne s’effondrera pas ».
Cela a un effet profond sur la productivité auto-déclarée.
Par exemple, le vélo peut paraître plus rapide que de conduire à 30 miles/h, vitres relevées, sur de petites routes de banlieue avec beaucoup de panneaux stop.
Mais, en général, l’automobiliste arrivera bien plus vite à un endroit situé à 20 pâtés de maisons.
Sans unité de mesure, tout le monde serait en train de se disputer pour savoir si le vélo est plus rapide.
C’est l’état actuel du génie logiciel.
Créer du logiciel ne ressemble pas du tout à la construction d’un pont ou d’un gratte-ciel ; cela se rapproche plutôt de leur conception.
Dans un grand projet de construction, on conçoit d’abord, puis on construit ensuite, et cette conception représente un travail énorme.
Il faut penser à tout, lancer des simulations, échanger avec les parties prenantes, comprendre les exigences et les contraintes, tenir compte du coût et du poids des matériaux, etc.
Dans les grands projets de construction, des mois, voire des années, peuvent être consacrés uniquement à produire la conception, et le résultat est un plan extrêmement détaillé couvrant presque tous les aspects de la construction.
En réalité, cela ressemble beaucoup au fait de créer du logiciel.
Ces projets de conception comportent une forte incertitude et beaucoup de risques.
Mais il vaut mieux découvrir que tout est faux avant de commencer à mobiliser des ressources coûteuses comme de nombreuses personnes, du béton ou de l’acier.
Avez-vous déjà entendu un architecte dire qu’il va faire une conception de la conception pour atténuer ce risque ? Cela n’existe pas.
Tout au plus y a-t-il pu avoir, à un moment, un croquis ou un dessin sur une serviette.
SpaceX a introduit certains éléments agiles dans l’ingénierie, appris du développement logiciel.
Dans le logiciel, le plan final est exécutable.
Le processus de création du plan est manuel, mais la transformation de ce plan en logiciel est généralement automatisée par des compilateurs et d’autres outils, et elle est très peu coûteuse ; c’est pourquoi les développeurs la font en permanence.
Bien sûr, cela n’a pas toujours été le cas par le passé.
Le processus de création d’un plan exécutable comporte naturellement beaucoup de risques, et il peut y avoir ici ou là des conceptions sur serviette ou sur tableau blanc.
Mais l’idée de faire d’abord une conception complète puis une implémentation complète — autrement dit le modèle en cascade — n’a jamais vraiment fonctionné non plus dans le logiciel.
À quelques exceptions près, il n’y a généralement pas de plan pour le plan.
Si l’on lit l’article original de Royce sur le modèle en cascade, le mot « cascade » n’y apparaît en fait jamais, et il suggère vaguement que l’itération pourrait être une bonne idée.
Au moins, en quelque sorte, de le faire plus d’une fois.
Il avait parfaitement compris que la première conception avait de fortes chances d’être mauvaise.
L’agile a optimisé jusqu’à éliminer cette étape de faible valeur consistant à concevoir le plan, ce qui devient évident quand on itère beaucoup.
Simplement, en dehors de certains domaines précis, nous les ignorons généralement.
Par exemple, à parcourir rapidement ce résumé et la table des matières, il semble y avoir peu, voire aucune mention des métriques de performance.
À quoi sert une architecture si l’on ne tient pas compte de ce que fait réellement l’ordinateur ?
Même du point de vue de la productivité des développeurs ou de l’interface utilisateur, pourquoi n’avons-nous pas de modèle mathématique décrivant la pile mentale nécessaire pour développer, modifier, étendre et, plus important encore, utiliser un logiciel ?
Les ressources de calcul, qu’elles soient humaines ou machines, ont un impact réel et mesurable sur l’interaction avec le logiciel, en tant que développeur ou utilisateur ; alors pourquoi ne les prend-on que rarement en compte ?
Par exemple, le palais de Westminster comporte évidemment des aspects de génie civil, mais ses caractéristiques déterminantes — les textures ornées, la tour horloge emblématique, l’agencement intérieur — relèvent surtout de choix fonctionnels et esthétiques.
Il en va de même pour une grande partie du logiciel.