Architecture & AgilitéRéconcilier les frères ennemis<br />Jean-Philippe Gouigoux<br />13 Octobre 2011<br />
search://gouigoux<br />www.agiletour.com<br />13/10/2011<br />pôle Architecture / Formation / Innovation<br />
Architecture =<br />Abstraire<br />Structurer<br />Prévoir<br />Pourquoi « frères ennemis » ?<br />www.agiletour.com<br />...
Buts de la session<br />Détruire des mythes<br />Donner des pistes<br />Principes SOLID<br />Remaniement (refactoring)<br ...
L’architecture est partout !<br />www.agiletour.com<br />13/10/2011<br />Pur codage<br />Système<br />Application<br />Con...
« Architecture logicielle »<br />www.agiletour.com<br />13/10/2011<br />Mythe !<br />
Architecture de construction<br />www.agiletour.com<br />13/10/2011<br />
« Architecture » logicielle ?<br />www.agiletour.com<br />13/10/2011<br />
Pourquoi ?<br />www.agiletour.com<br />13/10/2011<br />
Abstraction<br />www.agiletour.com<br />13/10/2011<br />
Pareil en info ?<br />www.agiletour.com<br />13/10/2011<br />
Oui, mais…<br />www.agiletour.com<br />13/10/2011<br />Trois occasions de se planter !<br />
Le vrai métier d’architecte logiciel ?<br />Reconnaître ses erreurs :<br />SOAP utilisé pour SaaS<br />Flash pour applis L...
≠<br />Pas si incompatibles ?<br />www.agiletour.com<br />13/10/2011<br />Architecture =<br />Abstraire<br />Structurer<br...
Exemple : TP de formation .NET<br />www.agiletour.com<br />13/10/2011<br />
Approche Agile<br />www.agiletour.com<br />13/10/2011<br />
Deux retours immédiats<br />« On va commencer par une classe Outils avec toutes les fonctions dont on a besoin »<br />Non ...
Un post-it pour la structure initiale ?<br />www.agiletour.com<br />13/10/2011<br />Architecture ?Structuration ?<br />4h<...
YAGNI encore une fois<br />www.agiletour.com<br />13/10/2011<br />Conséquences<br />Pas de BD<br />Pas de service<br />Pas...
≈<br />Vraiment peu incompatibles…<br />www.agiletour.com<br />13/10/2011<br />Architecture =<br />Abstraire<br />Structur...
Prévalence Objet<br />Persistance transparente sur le modèle POO du métier (logs et snapshots, mais pas de BD)<br />Perfor...
« Si on n’inclut pas cette fonctionnalité tout de suite, on aura du mal à la rajouter »<br />Faux, car plus tard, la fonct...
Concept d’ « architecture émergente »<br />www.agiletour.com<br />13/10/2011<br />Cycle en V<br />Architecture<br />Dévelo...
« Le coût d’une modification augmente exponentiellement avec la progression dans le projet »<br />Faux en mode agile : l’i...
Corollaire sur le temps total d’un projet<br />www.agiletour.com<br />13/10/2011<br />Complétion<br />Mode agile : les cha...
Le résultat en code : Fibonacci<br />www.agiletour.com<br />13/10/2011<br />
Facile ≠ simple<br />www.agiletour.com<br />13/10/2011<br />
« XP a pour principe que le code ne doit pas faire plus que ce qui est nécessaire pour que les tests passent »<br />Faux :...
Code élégant…<br />www.agiletour.com<br />13/10/2011<br />
Code élégant… performances catastrophiques<br />www.agiletour.com<br />13/10/2011<br />
Code élégant et performant ?<br />www.agiletour.com<br />13/10/2011<br />
« Un code plus élégant sera plus performant et maintenable »<br />Faux: il ne faut pas confondre élégance et simplicité<br...
L’heure du choix<br />Performance plus importante qu’élégance<br />Connaître précisément le besoin :<br />« une fonction q...
« Créer des APIs réutilisables fait gagner du temps »<br />Faux: la non-redondance doit être sur la fonctionnalité, et pas...
Critères de choix<br />Pas de pire ennemi que la sur-architecture<br />Coût élevé<br />Rend l’application rigide<br />Indu...
« Une architecture monolithique a de grands avantages (maintenance, connaissance partagée, etc.) »<br />Faux: les avantage...
YAGNI > DTSTTCPW<br />Do The SimplestThing That CouldPossiblyWork<br />Dangereux car qualitatif<br />Simple pour qui ?<br ...
OOP isyourfriend<br />Interfaces > héritage<br />Héritage = surarchitecture dans 90% des cas<br />« IFacturable » plutôt q...
Critères supplémentaires<br />Critères sur le code<br />Complexité cyclomatique<br />Couplage afférant / efférent<br />Out...
L’importance capitale du remaniement<br />Remaniement nécessaire pour supprimer le mythe « Coût de la modification augment...
On commence par les tests<br />www.agiletour.com<br />13/10/2011<br />
Etape 1<br />www.agiletour.com<br />13/10/2011<br />
Etape 2<br />www.agiletour.com<br />13/10/2011<br />
Etape 3<br />www.agiletour.com<br />13/10/2011<br />
Etape 4<br />www.agiletour.com<br />13/10/2011<br />
Etape 5<br />www.agiletour.com<br />13/10/2011<br />
Etape 6<br />www.agiletour.com<br />13/10/2011<br />
Plus simple ou pas ?<br />Plus long au début, puis plus court<br />Plus dur à lire pour un débutant<br />On a fait apparaî...
Atteindre l’étape « architecture »<br />www.agiletour.com<br />13/10/2011<br />DLL API<br />Notion complexe / Architecture...
Maîtriser la dette technique<br />Le remaniement doit faire partie de l’itération<br />Concept de dette architecturelle<br...
Récursion code simple / remaniement simple<br />www.agiletour.com<br />13/10/2011<br />
Code complexe : bon courage !<br />www.agiletour.com<br />13/10/2011<br />
Exemple vécu<br />www.agiletour.com<br />13/10/2011<br />65 étapes !<br />3 heures<br />Baby step<br />92% couverture<br /...
Baby steps ?<br />www.agiletour.com<br />13/10/2011<br />Tout petits pas itératifs<br />Correction simpliste<br />Tests un...
Du bon usage de la couverture de code<br />Pareto ou Murphy ?<br />Retour d’expérience : un cas de bug suite à non-couvert...
≈<br />Pas incompatibles du tout !<br />www.agiletour.com<br />13/10/2011<br />Architecture =<br />Abstraire<br />S’adapte...
Just Do It<br />Ne vous arrêtez pas à :<br />Pas le temps : remaniement = ROI rapide<br />Qualité de code suffisante : sus...
Questions… et peut-être même réponses !<br />www.agiletour.com<br />13/10/2011<br />
Prochain SlideShare
Chargement dans…5
×

Agile Tour Nantes 2011 - Jean philippe gouigoux - architecture et agilité, réconcilier les frères ennemis

2 802 vues

Publié le

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.

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 802
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1 494
Actions
Partages
0
Téléchargements
40
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Agile Tour Nantes 2011 - Jean philippe gouigoux - architecture et agilité, réconcilier les frères ennemis

  1. 1. Architecture & AgilitéRéconcilier les frères ennemis<br />Jean-Philippe Gouigoux<br />13 Octobre 2011<br />
  2. 2. search://gouigoux<br />www.agiletour.com<br />13/10/2011<br />pôle Architecture / Formation / Innovation<br />
  3. 3. Architecture =<br />Abstraire<br />Structurer<br />Prévoir<br />Pourquoi « frères ennemis » ?<br />www.agiletour.com<br />13/10/2011<br />Agilité =<br />Simplicité (XP, Lean)<br />Prééminence des tests (TDD)<br />Besoins immédiats (YAGNI)<br />≠<br />
  4. 4. Buts de la session<br />Détruire des mythes<br />Donner des pistes<br />Principes SOLID<br />Remaniement (refactoring)<br />www.agiletour.com<br />13/10/2011<br />
  5. 5. L’architecture est partout !<br />www.agiletour.com<br />13/10/2011<br />Pur codage<br />Système<br />Application<br />Conception<br />Code<br />Tests unitaires<br />Compilation<br />
  6. 6. « Architecture logicielle »<br />www.agiletour.com<br />13/10/2011<br />Mythe !<br />
  7. 7. Architecture de construction<br />www.agiletour.com<br />13/10/2011<br />
  8. 8. « Architecture » logicielle ?<br />www.agiletour.com<br />13/10/2011<br />
  9. 9. Pourquoi ?<br />www.agiletour.com<br />13/10/2011<br />
  10. 10. Abstraction<br />www.agiletour.com<br />13/10/2011<br />
  11. 11. Pareil en info ?<br />www.agiletour.com<br />13/10/2011<br />
  12. 12. Oui, mais…<br />www.agiletour.com<br />13/10/2011<br />Trois occasions de se planter !<br />
  13. 13. Le vrai métier d’architecte logiciel ?<br />Reconnaître ses erreurs :<br />SOAP utilisé pour SaaS<br />Flash pour applis LOB<br />S’adapter… vite<br />=> Agilité<br />www.agiletour.com<br />13/10/2011<br />
  14. 14. ≠<br />Pas si incompatibles ?<br />www.agiletour.com<br />13/10/2011<br />Architecture =<br />Abstraire<br />Structurer<br />Prévoir<br />S’adapter<br />Agilité =<br />Simplicité (XP, Lean)<br />Prééminence des tests (TDD)<br />Besoins immédiats (YAGNI)<br />≠<br />
  15. 15. Exemple : TP de formation .NET<br />www.agiletour.com<br />13/10/2011<br />
  16. 16. Approche Agile<br />www.agiletour.com<br />13/10/2011<br />
  17. 17. Deux retours immédiats<br />« On va commencer par une classe Outils avec toutes les fonctions dont on a besoin »<br />Non ! (YAGNI)<br />« C’est lequel le post-it avec la structure du projet? »<br />Solution et projets Visual Studio<br />Création de la fenêtre, du service, de la structure BD<br />www.agiletour.com<br />13/10/2011<br />
  18. 18. Un post-it pour la structure initiale ?<br />www.agiletour.com<br />13/10/2011<br />Architecture ?Structuration ?<br />4h<br />p1<br />
  19. 19. YAGNI encore une fois<br />www.agiletour.com<br />13/10/2011<br />Conséquences<br />Pas de BD<br />Pas de service<br />Pas de persistance !<br />1 solution avec 1 projet<br />
  20. 20. ≈<br />Vraiment peu incompatibles…<br />www.agiletour.com<br />13/10/2011<br />Architecture =<br />Abstraire<br />Structurer<br />S’adapter<br />Agilité =<br />Simplicité (XP, Lean)<br />Prééminence des tests (TDD)<br />Besoins immédiats (YAGNI)<br />≠<br />
  21. 21. Prévalence Objet<br />Persistance transparente sur le modèle POO du métier (logs et snapshots, mais pas de BD)<br />Performance par la simplicité<br />Exécution : tout en RAM (« limite » de 192 Go)<br />Maintenance : modification sur métier, plus d’O/RM<br />Concurrence et CQRS simples<br />ADO.NET pour Bamboo, benchmarks, etc. sur http://gouigoux.com<br />www.agiletour.com<br />13/10/2011<br />DIGRESSION<br />
  22. 22. « Si on n’inclut pas cette fonctionnalité tout de suite, on aura du mal à la rajouter »<br />Faux, car plus tard, la fonctionnalité voulue sera mieux comprise<br />Faux, car plus tard, on aura acquis plus de maîtrise du code existant<br />Faux, car si l’architecture ne permet pas cette modification, elle était de toute façon trop rigide<br />www.agiletour.com<br />13/10/2011<br />Mythe !<br />
  23. 23. Concept d’ « architecture émergente »<br />www.agiletour.com<br />13/10/2011<br />Cycle en V<br />Architecture<br />Développement<br />t<br />Architecture<br />Agilité<br />Développement<br />
  24. 24. « Le coût d’une modification augmente exponentiellement avec la progression dans le projet »<br />Faux en mode agile : l’intégration continue garantit une livraison rapide (même si coût en amont)<br />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<br />www.agiletour.com<br />13/10/2011<br />Mythe ! (*)<br />
  25. 25. Corollaire sur le temps total d’un projet<br />www.agiletour.com<br />13/10/2011<br />Complétion<br />Mode agile : les changements d’architecture sont plus nombreux mais rapidement absorbés<br />Cycle en V : un oubli sur l’architecture peut nécessiter de repartir quasiment du début du cycle.<br />Temps<br />
  26. 26. Le résultat en code : Fibonacci<br />www.agiletour.com<br />13/10/2011<br />
  27. 27. Facile ≠ simple<br />www.agiletour.com<br />13/10/2011<br />
  28. 28. « XP a pour principe que le code ne doit pas faire plus que ce qui est nécessaire pour que les tests passent »<br />Faux : XP exige que le code soit le plus simple possible pour que les tests passent<br />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<br />www.agiletour.com<br />13/10/2011<br />Mythe !<br />
  29. 29. Code élégant…<br />www.agiletour.com<br />13/10/2011<br />
  30. 30. Code élégant… performances catastrophiques<br />www.agiletour.com<br />13/10/2011<br />
  31. 31. Code élégant et performant ?<br />www.agiletour.com<br />13/10/2011<br />
  32. 32. « Un code plus élégant sera plus performant et maintenable »<br />Faux: il ne faut pas confondre élégance et simplicité<br />Faux : d’expérience, le code mort provient souvent d’une sur-architecture jamais utilisée<br />www.agiletour.com<br />13/10/2011<br />Mythe !<br />
  33. 33. L’heure du choix<br />Performance plus importante qu’élégance<br />Connaître précisément le besoin :<br />« une fonction qui calcule tous les nombres de Fibonacci »<br />« une fonction qui calcule des nombres de Fibonacci nécessaires à une estimation de temps »<br />Cas particulier d’une API publique<br />www.agiletour.com<br />13/10/2011<br />
  34. 34. « Créer des APIs réutilisables fait gagner du temps »<br />Faux: la non-redondance doit être sur la fonctionnalité, et pas sur le code<br />Faux : un code gardé en commun alors que les fonctionnalités divergent fait perdre du temps<br />www.agiletour.com<br />13/10/2011<br />Mythe !<br />
  35. 35. Critères de choix<br />Pas de pire ennemi que la sur-architecture<br />Coût élevé<br />Rend l’application rigide<br />Induit une compréhension figée du métier<br />www.agiletour.com<br />13/10/2011<br />
  36. 36. « Une architecture monolithique a de grands avantages (maintenance, connaissance partagée, etc.) »<br />Faux: les avantages sont souvent inférieurs à ce qu’on imagine<br />Faux : les inconvénients existent : inertie, manque de motivation des équipes, adaptation toujours moyenne aux besoins<br />www.agiletour.com<br />13/10/2011<br />Mythe !<br />
  37. 37. YAGNI > DTSTTCPW<br />Do The SimplestThing That CouldPossiblyWork<br />Dangereux car qualitatif<br />Simple pour qui ?<br />You Aren’tGoing to Need It<br />Binaire<br />Doute => ne pas faire<br />www.agiletour.com<br />13/10/2011<br />
  38. 38. OOP isyourfriend<br />Interfaces > héritage<br />Héritage = surarchitecture dans 90% des cas<br />« IFacturable » plutôt que « ITunnelisable » (DDD)<br />Améliore la testabilité (mocks, stubs)<br />SOLID = réduire, simplifier (SRP, encapsulation, etc.)<br />www.agiletour.com<br />13/10/2011<br />SOLID : Top investissement !!!<br />
  39. 39. Critères supplémentaires<br />Critères sur le code<br />Complexité cyclomatique<br />Couplage afférant / efférent<br />Outillez-vous (NDepend)<br />Sous-architecture aussi un problème:<br />API pas assez contraignante<br />Usages hétérogènes<br />Evolution difficile<br />www.agiletour.com<br />13/10/2011<br />
  40. 40. L’importance capitale du remaniement<br />Remaniement nécessaire pour supprimer le mythe « Coût de la modification augmentant exponentiellement avec l’avancée du projet »<br />Le principe : modifier la structure d’un module sans modifier son fonctionnement<br />Possible grâce au filet de sécurité des tests automatisés (importance du taux de couverture)<br />www.agiletour.com<br />13/10/2011<br />
  41. 41. On commence par les tests<br />www.agiletour.com<br />13/10/2011<br />
  42. 42. Etape 1<br />www.agiletour.com<br />13/10/2011<br />
  43. 43. Etape 2<br />www.agiletour.com<br />13/10/2011<br />
  44. 44. Etape 3<br />www.agiletour.com<br />13/10/2011<br />
  45. 45. Etape 4<br />www.agiletour.com<br />13/10/2011<br />
  46. 46. Etape 5<br />www.agiletour.com<br />13/10/2011<br />
  47. 47. Etape 6<br />www.agiletour.com<br />13/10/2011<br />
  48. 48. Plus simple ou pas ?<br />Plus long au début, puis plus court<br />Plus dur à lire pour un débutant<br />On a fait apparaître des « caractéristiques désirables du code » (SRP, en particulier)<br />www.agiletour.com<br />13/10/2011<br />
  49. 49. Atteindre l’étape « architecture »<br />www.agiletour.com<br />13/10/2011<br />DLL API<br />Notion complexe / Architecture simple<br />DLL Métier<br />Nous sommes retombés de nous-mêmes sur la notion de délégué anonyme :<br />
  50. 50. Maîtriser la dette technique<br />Le remaniement doit faire partie de l’itération<br />Concept de dette architecturelle<br />Gaspillage au sens Lean (pas de valeur au client)<br />www.agiletour.com<br />13/10/2011<br />
  51. 51. Récursion code simple / remaniement simple<br />www.agiletour.com<br />13/10/2011<br />
  52. 52. Code complexe : bon courage !<br />www.agiletour.com<br />13/10/2011<br />
  53. 53. Exemple vécu<br />www.agiletour.com<br />13/10/2011<br />65 étapes !<br />3 heures<br />Baby step<br />92% couverture<br />ROI : immédiat !<br />
  54. 54. Baby steps ?<br />www.agiletour.com<br />13/10/2011<br />Tout petits pas itératifs<br />Correction simpliste<br />Tests unitaires<br />Retours sur erreurs<br />Tests unitaires<br />
  55. 55. Du bon usage de la couverture de code<br />Pareto ou Murphy ?<br />Retour d’expérience : un cas de bug suite à non-couverture de code sur 8 ans<br />Détection de code mort : attention à la réflexion<br />www.agiletour.com<br />13/10/2011<br />
  56. 56. ≈<br />Pas incompatibles du tout !<br />www.agiletour.com<br />13/10/2011<br />Architecture =<br />Abstraire<br />S’adapter<br />Agilité =<br />Simplicité (XP, Lean)<br />Prééminence des tests (TDD)<br />Besoins immédiats (YAGNI)<br />Abstraction progressive (remaniement, architecture émergente)<br />=<br />
  57. 57. Just Do It<br />Ne vous arrêtez pas à :<br />Pas le temps : remaniement = ROI rapide<br />Qualité de code suffisante : sustainable pace<br />Dette technique trop lourde : retours multiples (motivation, qualité) dès le premier pas<br />www.agiletour.com<br />13/10/2011<br />
  58. 58. Questions… et peut-être même réponses !<br />www.agiletour.com<br />13/10/2011<br />

×