L'architecture et l'agilité sont souvent vues comme opposées : l'architecture encourage l'abstraction, la structuration pour le futur, alors que l'agilité met l'accent sur le réalisme et la simplicité. Cette conférence tente de jeter un éclairage sur cette apparente incompatibilité, en commençant par détruire quelques mythes sur l'architecture. Ensuite, elle donne des critères pour positionner correctement le curseur entre abstraction et pragmatisme. Enfin, elle montre l'apport essentiel des techniques de refactoring dans une approche agile de l'architecture logicielle, avec une démonstration sur du code.

1. Architecture & AgilitéRéconcilier les frères ennemis Jean-Philippe Gouigoux 13 Octobre 2011

2. search://gouigoux www.agiletour.com 13/10/2011 pôle Architecture / Formation / Innovation

3. Architecture = Abstraire Structurer Prévoir Pourquoi « frères ennemis » ? www.agiletour.com 13/10/2011 Agilité = Simplicité (XP, Lean) Prééminence des tests (TDD) Besoins immédiats (YAGNI) ≠

4. Buts de la session Détruire des mythes Donner des pistes Principes SOLID Remaniement (refactoring) www.agiletour.com 13/10/2011

5. L’architecture est partout ! www.agiletour.com 13/10/2011 Pur codage Système Application Conception Code Tests unitaires Compilation

6. « Architecture logicielle » www.agiletour.com 13/10/2011 Mythe !

7. Architecture de construction www.agiletour.com 13/10/2011

8. « Architecture » logicielle ? www.agiletour.com 13/10/2011

9. Pourquoi ? www.agiletour.com 13/10/2011

10. Abstraction www.agiletour.com 13/10/2011

11. Pareil en info ? www.agiletour.com 13/10/2011

12. Oui, mais… www.agiletour.com 13/10/2011 Trois occasions de se planter !

13. Le vrai métier d’architecte logiciel ? Reconnaître ses erreurs : SOAP utilisé pour SaaS Flash pour applis LOB S’adapter… vite => Agilité www.agiletour.com 13/10/2011

14. ≠ Pas si incompatibles ? www.agiletour.com 13/10/2011 Architecture = Abstraire Structurer Prévoir S’adapter Agilité = Simplicité (XP, Lean) Prééminence des tests (TDD) Besoins immédiats (YAGNI) ≠

15. Exemple : TP de formation .NET www.agiletour.com 13/10/2011

16. Approche Agile www.agiletour.com 13/10/2011

17. Deux retours immédiats « On va commencer par une classe Outils avec toutes les fonctions dont on a besoin » Non ! (YAGNI) « C’est lequel le post-it avec la structure du projet? » Solution et projets Visual Studio Création de la fenêtre, du service, de la structure BD www.agiletour.com 13/10/2011

18. Un post-it pour la structure initiale ? www.agiletour.com 13/10/2011 Architecture ?Structuration ? 4h p1

19. YAGNI encore une fois www.agiletour.com 13/10/2011 Conséquences Pas de BD Pas de service Pas de persistance ! 1 solution avec 1 projet

20. ≈ Vraiment peu incompatibles… www.agiletour.com 13/10/2011 Architecture = Abstraire Structurer S’adapter Agilité = Simplicité (XP, Lean) Prééminence des tests (TDD) Besoins immédiats (YAGNI) ≠

21. Prévalence Objet Persistance transparente sur le modèle POO du métier (logs et snapshots, mais pas de BD) Performance par la simplicité Exécution : tout en RAM (« limite » de 192 Go) Maintenance : modification sur métier, plus d’O/RM Concurrence et CQRS simples ADO.NET pour Bamboo, benchmarks, etc. sur http://gouigoux.com www.agiletour.com 13/10/2011 DIGRESSION

22. « Si on n’inclut pas cette fonctionnalité tout de suite, on aura du mal à la rajouter » Faux, car plus tard, la fonctionnalité voulue sera mieux comprise Faux, car plus tard, on aura acquis plus de maîtrise du code existant Faux, car si l’architecture ne permet pas cette modification, elle était de toute façon trop rigide www.agiletour.com 13/10/2011 Mythe !

23. Concept d’ « architecture émergente » www.agiletour.com 13/10/2011 Cycle en V Architecture Développement t Architecture Agilité Développement

24. « Le coût d’une modification augmente exponentiellement avec la progression dans le projet » Faux en mode agile : l’intégration continue garantit une livraison rapide (même si coût en amont) Faux en mode agile : le remaniement constant de l’application (XP) fait qu’un changement d’architecture ne prendra pas plus de temps sur un sprint que sur un autre www.agiletour.com 13/10/2011 Mythe ! (*)

25. Corollaire sur le temps total d’un projet www.agiletour.com 13/10/2011 Complétion Mode agile : les changements d’architecture sont plus nombreux mais rapidement absorbés Cycle en V : un oubli sur l’architecture peut nécessiter de repartir quasiment du début du cycle. Temps

26. Le résultat en code : Fibonacci www.agiletour.com 13/10/2011

27. Facile ≠ simple www.agiletour.com 13/10/2011

28. « XP a pour principe que le code ne doit pas faire plus que ce qui est nécessaire pour que les tests passent » Faux : XP exige que le code soit le plus simple possible pour que les tests passent Faux : XP considère que la programmation est une activité de conception (la réalisation associée est la compilation), et une architecture simple sera donc toujours préférée à un code simple www.agiletour.com 13/10/2011 Mythe !

29. Code élégant… www.agiletour.com 13/10/2011

30. Code élégant… performances catastrophiques www.agiletour.com 13/10/2011

31. Code élégant et performant ? www.agiletour.com 13/10/2011

32. « Un code plus élégant sera plus performant et maintenable » Faux: il ne faut pas confondre élégance et simplicité Faux : d’expérience, le code mort provient souvent d’une sur-architecture jamais utilisée www.agiletour.com 13/10/2011 Mythe !

33. L’heure du choix Performance plus importante qu’élégance Connaître précisément le besoin : « une fonction qui calcule tous les nombres de Fibonacci » « une fonction qui calcule des nombres de Fibonacci nécessaires à une estimation de temps » Cas particulier d’une API publique www.agiletour.com 13/10/2011

34. « Créer des APIs réutilisables fait gagner du temps » Faux: la non-redondance doit être sur la fonctionnalité, et pas sur le code Faux : un code gardé en commun alors que les fonctionnalités divergent fait perdre du temps www.agiletour.com 13/10/2011 Mythe !

35. Critères de choix Pas de pire ennemi que la sur-architecture Coût élevé Rend l’application rigide Induit une compréhension figée du métier www.agiletour.com 13/10/2011

36. « Une architecture monolithique a de grands avantages (maintenance, connaissance partagée, etc.) » Faux: les avantages sont souvent inférieurs à ce qu’on imagine Faux : les inconvénients existent : inertie, manque de motivation des équipes, adaptation toujours moyenne aux besoins www.agiletour.com 13/10/2011 Mythe !

37. YAGNI > DTSTTCPW Do The SimplestThing That CouldPossiblyWork Dangereux car qualitatif Simple pour qui ? You Aren’tGoing to Need It Binaire Doute => ne pas faire www.agiletour.com 13/10/2011

38. OOP isyourfriend Interfaces > héritage Héritage = surarchitecture dans 90% des cas « IFacturable » plutôt que « ITunnelisable » (DDD) Améliore la testabilité (mocks, stubs) SOLID = réduire, simplifier (SRP, encapsulation, etc.) www.agiletour.com 13/10/2011 SOLID : Top investissement !!!

39. Critères supplémentaires Critères sur le code Complexité cyclomatique Couplage afférant / efférent Outillez-vous (NDepend) Sous-architecture aussi un problème: API pas assez contraignante Usages hétérogènes Evolution difficile www.agiletour.com 13/10/2011

40. L’importance capitale du remaniement Remaniement nécessaire pour supprimer le mythe « Coût de la modification augmentant exponentiellement avec l’avancée du projet » Le principe : modifier la structure d’un module sans modifier son fonctionnement Possible grâce au filet de sécurité des tests automatisés (importance du taux de couverture) www.agiletour.com 13/10/2011

41. On commence par les tests www.agiletour.com 13/10/2011

42. Etape 1 www.agiletour.com 13/10/2011

43. Etape 2 www.agiletour.com 13/10/2011

44. Etape 3 www.agiletour.com 13/10/2011

45. Etape 4 www.agiletour.com 13/10/2011

46. Etape 5 www.agiletour.com 13/10/2011

47. Etape 6 www.agiletour.com 13/10/2011

48. Plus simple ou pas ? Plus long au début, puis plus court Plus dur à lire pour un débutant On a fait apparaître des « caractéristiques désirables du code » (SRP, en particulier) www.agiletour.com 13/10/2011

49. Atteindre l’étape « architecture » www.agiletour.com 13/10/2011 DLL API Notion complexe / Architecture simple DLL Métier Nous sommes retombés de nous-mêmes sur la notion de délégué anonyme :

50. Maîtriser la dette technique Le remaniement doit faire partie de l’itération Concept de dette architecturelle Gaspillage au sens Lean (pas de valeur au client) www.agiletour.com 13/10/2011

51. Récursion code simple / remaniement simple www.agiletour.com 13/10/2011

52. Code complexe : bon courage ! www.agiletour.com 13/10/2011

53. Exemple vécu www.agiletour.com 13/10/2011 65 étapes ! 3 heures Baby step 92% couverture ROI : immédiat !

54. Baby steps ? www.agiletour.com 13/10/2011 Tout petits pas itératifs Correction simpliste Tests unitaires Retours sur erreurs Tests unitaires

55. Du bon usage de la couverture de code Pareto ou Murphy ? Retour d’expérience : un cas de bug suite à non-couverture de code sur 8 ans Détection de code mort : attention à la réflexion www.agiletour.com 13/10/2011

56. ≈ Pas incompatibles du tout ! www.agiletour.com 13/10/2011 Architecture = Abstraire S’adapter Agilité = Simplicité (XP, Lean) Prééminence des tests (TDD) Besoins immédiats (YAGNI) Abstraction progressive (remaniement, architecture émergente) =

57. Just Do It Ne vous arrêtez pas à : Pas le temps : remaniement = ROI rapide Qualité de code suffisante : sustainable pace Dette technique trop lourde : retours multiples (motivation, qualité) dès le premier pas www.agiletour.com 13/10/2011

58. Questions… et peut-être même réponses ! www.agiletour.com 13/10/2011