Impact des méthodes agiles sur l'architecture

La question de l’impact des méthodes agiles sur l’architecture est une question qui revient souvent. Cet article n’a pas pour but de traiter tout le sujet mais d’aborder  les principaux changements qui sont venu avec ma pratique de l’agilité.

La démarche itérative induit deux nouvelles exigences : la testabilité et la robustesse au changement.

Architectures testables
La démarche itérative fait grandir l’effort de test de façon exponentielle. Pour ne pas tomber dans le travers qui consiste à ne plus tester et donc à diminuer la qualité du produit, le succès des méthodes agiles est fortement lié à une politique de tests automatiques.

L’impact sur l’architecture est le suivant :

  • Utilisation d’interfaces pour la communication entre les objets
  • Bien définir les rôles de chaque composant et les faire le plus petit possible
  • L’utilisation du Test Driven Developpement influe directement sur la testabilité de l’architecture tout en restant centrée sur le service qu’elle doit remplir. Vraiment une expérience intéressante qui nous fait poser les questions de manière différente.

Architectures robustes au changement

Une des valeurs du manifeste agile est « Responding to change over folowing a plan ». Il faut donc des architectures qui permettent de réagir favorablement à ces changements.

Voici quelques principes qui renforcent la réactivité au changement :

  • Utilisation des design pattern
  • Utilisation d’interfaces
  • Limiter  l’interdépendance des composants
  • Écrire des classes petites avec des rôles bien définis
  • J’enfonce peut être une porte ouverte mais : abolir le copier/coller (il n’y à pas pire que du code dupliqué quand on doit réagir au changement)
  • Faire du Refactoring dès que possible. Cette pratique est largement facilitée si elle est accompagnée d’une politique de test automatique.

Conclusion

Le sujet est vraiment vaste et je ferais certainement d’autres articles sur le sujet. Pour n’en retenir que deux points :

  • Choisir les architectures qui permettent d’aller vers la plus grande couverture de test (quand les contraintes de performances le permettent)
  • Vraiment séparer les rôles. Souvent on veut développer vite et on mélange tout (par exemple la manipulation des données avec le code de l’IHM)