- 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
Aucun commentaire pour le moment.