Votre architecture est elle SOLID ?

Non il ne s’agit pas d’une publicité pour vous vendre un audit sur l’architecture de vos concurrent 😉 mais bien de patterns d’architecture définis par Robert C. Martin.

Comme on peut le lire dans wikipedia, SOLID est un acronyme pour définir les 5 principes :

  • Single Responsability
    • Un objet n’est responsable que d’une chose
  • Open/Close
    • L’objet doit être ouvert au extension de comportement sans modification du code
  • Liscov Substitution
    • On doit pouvoir substituer un objet par un autre de classe dérivée
  • Interface segregation
    • Multiplier les interfaces plutôt que d’avoir une interface à tout faire
  • Dependency inversion.
    • Les objets doivent dépendre d’interfaces pas de classes concrètes

On trouve un document de Robert C. Martin très complet sur le sujet ici.  Sa lecture donne envie de se procurer le livre du même auteur Clean Code.

L’article fournit quelques indicateurs pour mesurer la SOLIDité de l’architecture. Certains sont facile à mettre en œuvre :

  • Sur un objet compter le nombre de responsabilité (facile)
  • L’utilisation de if / switch sur les types d’objets peuvent indiquer une violation du principe Open/Close
  • Compter le nombre d’interfaces d’un objet et visualiser les dépendances vers les classes concrètes

D’autres plus compliqués sans outils adéquat :

  • Rapport des dépendances entrantes vs dépendances sortantes d’un package
  • Détecter les violations du principe de Liscov

En analysant ces critères sur son code, on ne trouve pas son architecture toujours aussi SOLID. Etonnamment on n’aime pas avoir à intervenir sur du code FRAGILE 😉

Planning poker : régulateur de discussion

Dernièrement en réunion de planning nous avons eu un bel exemple de l’utilisation du planning poker comme régulateur de discussion. Nous devions estimer une user story qui consistait à réaliser un prototype pour un client. Après avoir négocié le périmètre fonctionnel avec le product owner, le débat s’est vite orienté sur la pertinence de telle architecture par rapport à telle autre. Au bout de quelques minutes de discussion, nous avons arrêté le débat pour estimer une des deux propositions. Comme souvent après deux “plis” de planning poker les estimations ont convergé. Nous avons décidés de ne pas aller plus loin en estimant l’autre architecture car nous avons convenu qu’elle n’allait pas diverger suffisamment. Le débat sur l’architecture a été reporté à plus tard, c’est à dire au moment où la user story sera réalisée.

Souvent nous avons tendance à alimenter le débat avant les premières estimations. On voit ici que cela n’est pas toujours pertinent. Je pense cependant qu’il faut faire attention et vérifier que chaque personne ait pu exprimer son point de vue avant de conclure avec des estimations convergentes. En tous cas c’est une idée pour faire avancer les choses lorsque le débat tourne un peu en rond.