Les logiciels petits sont les plus jolis

Cinquième billet et dernier billet de cette série sur la conception de logiciels[1]
Que se passe-t-il lorsqu'un logiciel grossit ?
Est-on en mesure d'introduire indéfiniment de nouveaux concepts et de conserver un ensemble toujours aussi évolutif ?

Je ne crois pas que cela soit possible car

  • cela nécessiterait une équipe de plus en plus grosse pour gérer la base de code
  • et cela demanderait un effort monumental pour garantir la cohérence fonctionnelle de l'ensemble

Je sais que, dans certains endroits, plusieurs équipes travaillent simultanément sur la même base de code, chaque équipe étant en charge de fonctionnalités bien définies. On parle alors d'"équipe feature"[2]. Je n'ai jamais expérimenté cela et je reste dubitatif sur l'efficacité de la chose.
Il m'est arrivé de travailler sur de gros logiciels mais le développement de ceux-ci était toujours organisé en composants, chaque composant ayant sa base de code propre et son équipe dédiée, y compris au niveau fonctionnel : un chef de produit et un backlog produit par composant.

La plus grande qualité que je trouve aux composants logiciels, c'est qu'ils permettent à la base de code d'un logiciel de rester dans une taille raisonnable. Cela se réalise en considérant chaque composant comme un logiciel à part entière avec ses propres exigences et ses propres concepts.
A mon avis, le seul risque de cette approche est de définir des composants trop en amont dans le développement d'un logiciel, ce qui pourrait amener à des choix qui se marient mal avec les concepts du logiciel décomposé.
Mais si on laisse faire les choses et que l'on découpe au moment opportun, le risque disparait.

Exemple :

  • 1- Le code d'un logiciel a été simplifié grace à un concept d'implémentation
  • 2- Après quelques évolution du logiciel, le concept sous-jacent commence à grossir
  • 3- Il grossit tellement qu'il commence lui-même à être organisé avec des abstractions et des détails
  • 4- Il devient alors un produit logiciel à part entière où une partie de ses concepts d'architecture sont l'API qui permet de l'utiliser
  • 5- Notre logiciel est revenu à sa taille initiale (voire à une taille plus petite) car il utilise un produit tiers qui a son propre cycle de vie

5x01.png

Autre exemple :

  • 1- Un gros logiciel est défini par ses concepts d'architecture et ses détails d'implémentation
  • 2- Une partie de ce logiciel est fortement découplée du reste (le lien ne se fait que par quelques abstractions) : elle est naturellement organisée comme si elle était un produit à part entière, les quelques abstraction formant le lien étant l'API du produit distinct
  • 3- On donne sa liberté à ce produit et le logiciel initial retourne une taille raisonnable tout en ayant limité le lien avec le nouveau produit tiers à un seul de ses détails d'implémentation

5x02.png

On voit donc que l'émergence de produits tiers à partir de morceaux d'un logiciel existant peut être intéressante si elle respecte le découpage naturel du logiciel, c'est à dire si elle se base sur des concepts qui ont déjà émergé. Par ailleurs, comme nos jeux de tests se basent sur les concepts, qu'ils soient d'architecture ou d'implémentation, les nouveaux produits débutent leur existence avec des jeux de tests qui expriment clairement leur comportement.

Il existe toutefois des cas où les choses ne sont pas aussi simples.

  • 1- Prenons un logiciel qui, à travers ses concepts d'architecture, propose une API et la possibilité d'être étendu par divers détails présentés comme des "plugins"
  • 2- Si ces plugins venaient à grossir, on ne pourrait pas les considérer comme des produits tiers dont dépend le logiciel car l'API fait partie du logiciel et les plugins en dépendent. Une solution est alors de considérer notre le logiciel initial comme un produit tiers.
  • 3- En faisant cela, les plugins deviennent notre logiciel principal qui va pouvoir grossir en dépendant du produit tiers nouvellement créé. Cette opération est toutefois délicate car l'API qui sert désormais de point d'entrée au produit tiers n'est pas forcément adaptée à cela et, du fait de l'orientation "plugins", elle ne possède peut être pas les jeux de tests adéquats.

5x03.png

Cela reste une exemple. On pourrait avoir un plugin qui grossirait par introduction d'un concept d'implémentation lequel deviendrait à son tour un produit à part entière (cf 1er exemple du billet).
On retiendra que le concept d'architecture de type "API qui permet d'étendre un logiciel", ça peut être sympa sur le moment mais ça peut engendrer des inconvénients à plus long terme en fonction de la façon dont on appréhende le développement des plugins.

Voilà...
Ainsi s'achève cette série sur la conception de logiciels, ou devrais-je plutôt dire sur ma vision, en ce début d'année 2012, de ce qui me semble primordial dans la réalisation d'un logiciel. J'espère que cela aura intéressé quelques personnes. J'espère aussi avoir quelques retours qu'ils soient positifs ou négatifs. En tout cas, cela aura bien occupé mon temps libre de la semaine !

Notes

[1] Les quatre premiers billets sont là : Conception logicielle ; Le logiciel, un organisme multicellulaire ? ; Chacun cherche son TDD ; Le logiciel d'un développeur est son château.

[2] L'article "Feature Team Primer" dont une traduction par Fabrice Aimetti est disponible ici : http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/06/13/Equipe-feature présente ce genre d'organisation mais, pour moi, les auteurs avancent des arguments qui reposent entièrement sur une définition que je ne partage pas de ce qu'est une "architecture". Il faudrait un billet complet pour détailler ce sujet...

Clément HELIOU

Bonjour,

Série de billets très intéressante, avec des idées bien exprimées et illustrées.
Vraiment, c'est un point de vue rarement exprimé (selon moi). Toutes mes félicitations.

En revanche, je pense que l'ensemble gagnerait à être illustré par des cas concrets et notamment concernant les différences entre concepts d'architecture, concepts d'implémentation et détails d'implémentation.

Cordialement,

Oaz

Merci !

Je suis d'accord : les billets manquent d'exemples plus concrets et de code dans plusieurs langages pour illustrer les propos. Mais cela demanderait beaucoup plus de temps et de travail...

Oaz 9 mars 2012 - 12:25

Fil des commentaires de ce billet

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.