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.
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
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
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
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 !
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
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
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