- Seuls les ingénieurs qui manipulent directement le code peuvent réellement participer à la conception d’un système de grande ampleur, et les conseils abstraits sont le plus souvent inutiles
- Les conseils généraux de conception (
generic design) sont souvent formulés en comprenant le domaine mais sans connaître la base de code - Dans le travail réel, les contraintes concrètes et le maintien de la cohérence comptent bien plus que les principes de conception, et la clé est de comprendre l’état actuel du code
- Lors de la conception d’un nouveau système ou de la définition de l’orientation technique à l’échelle de l’entreprise, les principes généraux de conception peuvent être utiles dans une certaine mesure
- Cependant, les structures de conception centrées sur des architectes déconnectés du terrain échouent facilement, et la personne qui propose la conception doit en assumer les conséquences
Les limites de la conception logicielle générique
- La conception de systèmes de grande ampleur exige une compréhension approfondie des détails concrets du code
- Les conseils abstraits n’aident presque pas à résoudre les problèmes réels
- En pratique, la cohérence (
consistency) est plus importante qu’une « bonne conception »
- Comme les bases de code réelles sont complexes et produisent des effets imprévisibles, les options d’implémentation permettant des changements sûrs sont limitées
- Une grande base de code partagée se trouve toujours dans un état intermédiaire où plusieurs conceptions se mélangent, et l’état actuel des couplages dans le code importe davantage que l’objectif idéal
- Comme il est impossible de réécrire entièrement (
rewrite) la plupart des systèmes, il faut s’appuyer sur la cohérence interne et la rigueur des ingénieurs
Les caractéristiques de la conception logicielle concrète
- Les discussions de conception efficaces ont lieu dans les échanges entre quelques ingénieurs qui travaillent sur le système au quotidien
- Les sujets abordés ne portent pas sur des principes généraux, mais sur le contexte concret du système, comme sa structure détaillée ou ses flux de données
- Par exemple, au lieu de se demander « DRY est-il une bonne idée ? », on mène des discussions techniques fines du type : « peut-on placer cette fonctionnalité dans le sous-système A ? », « l’information B est-elle accessible dans le contexte C ? »
- Les contributions importantes viennent du fait de corriger de petits malentendus ou les effets détaillés d’une modification du code
Quand les conseils généraux de conception sont utiles
- Lorsqu’on conçoit un nouveau projet pour la première fois, les principes généraux sont utiles puisqu’il n’existe pas encore de contraintes concrètes
- Lorsqu’il est difficile de choisir entre plusieurs implémentations, les principes généraux peuvent servir de critère de départage (
tie-breaker) - Ils aident aussi à maintenir la cohérence à l’échelle de l’entreprise, ce qui fait partie du rôle officiel d’un architecte logiciel
- Même dans des choix technologiques larges comme cloud vs on-premise, AWS vs Azure, les principes généraux peuvent servir de repère, sans pour autant permettre d’ignorer les contraintes concrètes
Les architectes et le problème du « minimum local »
- Beaucoup d’entreprises tombent dans une organisation de conception abstraite centrée sur des architectes sans expérience de terrain
- En apparence, cette approche semble efficace, mais en réalité elle produit des conceptions impossibles à implémenter pour les ingénieurs sur le terrain
- Comme les architectes n’implémentent pas eux-mêmes, ils manquent souvent de responsabilité directe (
skin in the game) vis-à-vis des résultats- Si la conception réussit, ils s’en attribuent le mérite ; si elle échoue, la faute retombe sur l’équipe d’exécution
- Ce type de structure tend à renforcer des activités de conception formelles plutôt qu’une valeur réelle
Conclusion et proposition
- Les discussions de conception utiles se déroulent dans des échanges concrets au niveau du code, et le concepteur doit impérativement bien connaître la base de code
- Les principes architecturaux généraux doivent se limiter à la conception de nouveaux systèmes, à l’aide à la décision sur des choix détaillés dans des systèmes existants, et à la définition d’une orientation technique à l’échelle de l’entreprise
- La personne qui propose la conception d’un projet doit être responsable de sa réussite comme de son échec, et ce sont les ingénieurs qui manipulent réellement le code qui doivent être les acteurs centraux de la conception
- C’est ainsi que les personnes capables de comprendre un système réel et de le déployer peuvent être reconnues comme les véritables concepteurs
4 commentaires
C’est donc pour ça que, ces temps-ci, les gourous disent plutôt que les juniors utilisent bien mieux les agents. Comme c’est ce qui leur a permis de gagner de l’argent pendant longtemps, ils ne font pas le travail de désapprentissage.
C’est exactement ce que je pense d’habitude, alors ça me réchauffe le cœur.
Ne pourrait-on pas résoudre une bonne partie des problèmes soulevés en améliorant le processus qui permet d’aboutir à l’architecture ?
Avis sur Hacker News
Décrit une situation où, en réunion d’équipe, au lieu de discuter de choses comme « DRY ou WET, qu’est-ce qui vaut mieux ? », on enchaîne les discussions de dépendances complexes du type : « On pourrait mettre cette fonctionnalité dans le sous-système A ? Non, il n’a pas l’info B, et pour l’exposer il faudrait réécrire D… »
En disant que c’est un paysage familier, l’auteur énumère pour plaisanter plusieurs noms de systèmes fictifs, puis ajoute à la fin un lien YouTube
Cela fait 30 ans que je développe, mais j’ai rarement vu des cas où l’on investissait réellement un effort constant dans la conception et l’architecture
La plupart des « architectes » ne conçoivent rien ; ce sont les développeurs seniors qui conçoivent, puis reçoivent simplement du feedback
Avec une ancienneté moyenne de 2 ans, on finit par concevoir en ne comprenant qu’une partie du système, et l’architecte se contente souvent d’approuver
Le « Generic Software Design » est utile pour orienter l’implémentation. Il fournit un langage commun et un cadre qui facilitent la résolution des problèmes
Mais l’implémentation réelle peut diverger du plan. Comme dans la théorie de la programmation de Naur, la véritable connaissance du système est dans la tête des développeurs
Dire que, « dans une grande base de code, la cohérence est plus importante qu’une bonne conception », c’est précisément le piège de ce genre de conseil généralisé
Si l’on insiste uniquement sur la cohérence, on perpétue de mauvaises habitudes
D’un côté, il y a les « architectes » déconnectés du réel ; de l’autre, les Real Programmers obsédés par l’optimisation de détail
Les deux extrêmes posent problème, et les décideurs doivent comprendre à la fois les détails et le contexte
En lien avec cela, quelqu’un mentionne The Story of Mel
Je suis d’accord avec l’idée que « la personne qui a conçu le système doit aussi répondre de la réussite ou de l’échec du projet »
Cela devrait aussi s’appliquer à la personne qui a choisi la méthodologie de développement. Un Scrum master n’assume pas le même niveau de responsabilité qu’un lead engineer
Les meilleures applications auxquelles j’ai participé avaient les trois caractéristiques suivantes
Cette liberté augmentait à la fois la satisfaction des développeurs et la qualité du produit
D’après mon expérience, dans les grandes bases de code, l’obsession de la cohérence est plutôt une erreur
Chaque module ayant des exigences différentes, la stratégie de test comme le naming doivent aussi varier
Dans le cas idéal, les développeurs devraient aussi être les utilisateurs réels du logiciel qu’ils créent
Ils peuvent ainsi ressentir directement les erreurs ou les frictions, ce qui crée une motivation pour améliorer le produit
Un architecte logiciel séparé qui ne participe pas à la maintenance n’est pas réaliste
Un projet évolue en permanence, donc un rôle consistant à donner des directives à distance n’aide pas vraiment