Agile Tour Nantes 2011 - Jean philippe gouigoux - architecture et agilité, réconcilier les frères ennemis
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 2,437 views

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

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.

Statistics

Views

Total Views
2,437
Views on SlideShare
986
Embed Views
1,451

Actions

Likes
1
Downloads
37
Comments
0

5 Embeds 1,451

http://www.agilenantes.org 1417
http://www.scoop.it 31
http://www.mefeedia.com 1
http://shakertechnologies.tumblr.com 1
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • Architecture & AgilitéRéconcilier les frères ennemis
    Jean-Philippe Gouigoux
    13 Octobre 2011
  • search://gouigoux
    www.agiletour.com
    13/10/2011
    pôle Architecture / Formation / Innovation
  • 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)

    View slide
  • Buts de la session
    Détruire des mythes
    Donner des pistes
    Principes SOLID
    Remaniement (refactoring)
    www.agiletour.com
    13/10/2011
    View slide
  • L’architecture est partout !
    www.agiletour.com
    13/10/2011
    Pur codage
    Système
    Application
    Conception
    Code
    Tests unitaires
    Compilation
  • « Architecture logicielle »
    www.agiletour.com
    13/10/2011
    Mythe !
  • Architecture de construction
    www.agiletour.com
    13/10/2011
  • « Architecture » logicielle ?
    www.agiletour.com
    13/10/2011
  • Pourquoi ?
    www.agiletour.com
    13/10/2011
  • Abstraction
    www.agiletour.com
    13/10/2011
  • Pareil en info ?
    www.agiletour.com
    13/10/2011
  • Oui, mais…
    www.agiletour.com
    13/10/2011
    Trois occasions de se planter !
  • 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

  • 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)

  • Exemple : TP de formation .NET
    www.agiletour.com
    13/10/2011
  • Approche Agile
    www.agiletour.com
    13/10/2011
  • 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
  • Un post-it pour la structure initiale ?
    www.agiletour.com
    13/10/2011
    Architecture ?Structuration ?
    4h
    p1
  • 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

  • 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)

  • 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
  • « 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 !
  • Concept d’ « architecture émergente »
    www.agiletour.com
    13/10/2011
    Cycle en V
    Architecture
    Développement
    t
    Architecture
    Agilité
    Développement
  • « 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 ! (*)
  • 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
  • Le résultat en code : Fibonacci
    www.agiletour.com
    13/10/2011
  • Facile ≠ simple
    www.agiletour.com
    13/10/2011
  • « 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 !
  • Code élégant…
    www.agiletour.com
    13/10/2011
  • Code élégant… performances catastrophiques
    www.agiletour.com
    13/10/2011
  • Code élégant et performant ?
    www.agiletour.com
    13/10/2011
  • « 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 !
  • 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
  • « 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 !
  • 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
  • « 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 !
  • 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
  • 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 !!!
  • 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
  • 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
  • On commence par les tests
    www.agiletour.com
    13/10/2011
  • Etape 1
    www.agiletour.com
    13/10/2011
  • Etape 2
    www.agiletour.com
    13/10/2011
  • Etape 3
    www.agiletour.com
    13/10/2011
  • Etape 4
    www.agiletour.com
    13/10/2011
  • Etape 5
    www.agiletour.com
    13/10/2011
  • Etape 6
    www.agiletour.com
    13/10/2011
  • 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
  • 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 :
  • 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
  • Récursion code simple / remaniement simple
    www.agiletour.com
    13/10/2011
  • Code complexe : bon courage !
    www.agiletour.com
    13/10/2011
  • Exemple vécu
    www.agiletour.com
    13/10/2011
    65 étapes !
    3 heures
    Baby step
    92% couverture
    ROI : immédiat !
  • Baby steps ?
    www.agiletour.com
    13/10/2011
    Tout petits pas itératifs
    Correction simpliste
    Tests unitaires
    Retours sur erreurs
    Tests unitaires
  • 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

  • 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)
    =
  • 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
  • Questions… et peut-être même réponses !
    www.agiletour.com
    13/10/2011