View
2.519
Download
0
Category
Preview:
DESCRIPTION
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.
Citation preview
Architecture & AgilitéRéconcilier les frères ennemis
Jean-Philippe Gouigoux
13 Octobre 2011
search://gouigoux
www.agiletour.com13/10/2011
pôle Architecture / Formation / Innovation
.NET
F#
TFS GPGPU
Tests
Prog //
• Architecture =o Abstraireo Structurero Prévoir
Pourquoi « frères ennemis » ?
www.agiletour.com13/10/2011
• Agilité =o Simplicité (XP, Lean)o Prééminence des tests
(TDD)o Besoins immédiats
(YAGNI)
≠
Buts de la session
• Détruire des mythes• Donner des pistes
o Principes SOLIDo Remaniement (refactoring)
www.agiletour.com13/10/2011
L’architecture est partout !
www.agiletour.com13/10/2011
Pur codage
Conception
Système
Application
Code
Compilation
Tests unitaires
• « Architecture logicielle »
www.agiletour.com13/10/2011
MYTHE !
Architecture de construction
www.agiletour.com13/10/2011
« Architecture » logicielle ?
www.agiletour.com13/10/2011
Pourquoi ?
www.agiletour.com13/10/2011
Abstraction
www.agiletour.com13/10/2011
Pareil en info ?
www.agiletour.com13/10/2011
Oui, mais…
www.agiletour.com13/10/2011
Trois occasions de se planter !
Le vrai métier d’architecte logiciel ?
• Reconnaître ses erreurs :o SOAP utilisé pour SaaSo Flash pour applis LOB
• S’adapter… vite• => Agilité
www.agiletour.com13/10/2011
≠
Pas si incompatibles ?
www.agiletour.com13/10/2011
• Architecture =o Abstraireo Structurero Prévoiro S’adapter
• Agilité =o Simplicité (XP, Lean)o Prééminence des tests
(TDD)o Besoins immédiats
(YAGNI)
≠
Exemple : TP de formation .NET
www.agiletour.com13/10/2011
Approche Agile
www.agiletour.com13/10/2011
Deux retours immédiats
• « On va commencer par une classe Outils avec toutes les fonctions dont on a besoin »o Non ! (YAGNI)
• « C’est lequel le post-it avec la structure du projet? »o Solution et projets Visual Studioo Création de la fenêtre, du service, de la
structure BDwww.agiletour.com13/10/2011
Un post-it pour la structure initiale ?
www.agiletour.com13/10/2011
Architecture ?Structuration ?
4h
p1
YAGNI encore une fois
www.agiletour.com13/10/2011
• Conséquenceso Pas de BDo Pas de serviceo Pas de persistance !o 1 solution avec 1
projet
≈
Vraiment peu incompatibles…
www.agiletour.com13/10/2011
≠• Architecture
=o Abstraireo Structurero S’adapter
• Agilité =o Simplicité (XP, Lean)o Prééminence des tests
(TDD)o 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éo Exécution : tout en RAM (« limite » de 192
Go)o Maintenance : modification sur métier, plus
d’O/RMo Concurrence et CQRS simples
• ADO.NET pour Bamboo, benchmarks, etc. sur http://gouigoux.com
www.agiletour.com13/10/2011
DIGRESSION
• « Si on n’inclut pas cette fonctionnalité tout de suite, on aura du mal à la rajouter »o Faux, car plus tard, la fonctionnalité voulue
sera mieux compriseo Faux, car plus tard, on aura acquis plus de
maîtrise du code existanto Faux, car si l’architecture ne permet pas
cette modification, elle était de toute façon trop rigide
www.agiletour.com13/10/2011
MYTHE !
Concept d’ « architecture émergente »
www.agiletour.com13/10/2011
Architecture
Développement
Architecture
Développement
t
Cyc
le e
n V
Agi
lité
• « Le coût d’une modification augmente exponentiellement avec la progression dans le projet »o Faux en mode agile : l’intégration continue
garantit une livraison rapide (même si coût en amont)
o 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.com13/10/2011
MYTHE ! (*)
Corollaire sur le temps total d’un projet
www.agiletour.com13/10/2011
Temps
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.
Le résultat en code : Fibonacci
www.agiletour.com13/10/2011
Facile ≠ simple
www.agiletour.com13/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 »o Faux : XP exige que le code soit le plus
simple possible pour que les tests passento 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.com13/10/2011
MYTHE !
Code élégant…
www.agiletour.com13/10/2011
Code élégant… performances catastrophiques
www.agiletour.com13/10/2011
Code élégant et performant ?
www.agiletour.com13/10/2011
• « Un code plus élégant sera plus performant et maintenable »o Faux : il ne faut pas confondre élégance et
simplicitéo Faux : d’expérience, le code mort provient
souvent d’une sur-architecture jamais utilisée
www.agiletour.com13/10/2011
MYTHE !
L’heure du choix
• Performance plus importante qu’élégance
• Connaître précisément le besoin :o « une fonction qui calcule tous les nombres
de Fibonacci »o « une fonction qui calcule des nombres de
Fibonacci nécessaires à une estimation de temps »
• Cas particulier d’une API publiquewww.agiletour.com13/10/2011
• « Créer des APIs réutilisables fait gagner du temps »o Faux : la non-redondance doit être sur la
fonctionnalité, et pas sur le codeo Faux : un code gardé en commun alors que
les fonctionnalités divergent fait perdre du temps
www.agiletour.com13/10/2011
MYTHE !
Critères de choix
• Pas de pire ennemi que la sur-architectureo Coût élevéo Rend l’application rigideo Induit une compréhension figée du métier
www.agiletour.com13/10/2011
• « Une architecture monolithique a de grands avantages (maintenance, connaissance partagée, etc.) »o Faux : les avantages sont souvent
inférieurs à ce qu’on imagineo Faux : les inconvénients existent : inertie,
manque de motivation des équipes, adaptation toujours moyenne aux besoins
www.agiletour.com13/10/2011
MYTHE !
YAGNI > DTSTTCPW
• Do The Simplest Thing That Could Possibly Worko Dangereux car qualitatifo Simple pour qui ?
• You Aren’t Going to Need Ito Binaireo Doute => ne pas faire
www.agiletour.com13/10/2011
OOP is your friend
• Interfaces > héritageo Héritage = surarchitecture dans 90% des
caso « IFacturable » plutôt que « ITunnelisable »
(DDD)o Améliore la testabilité (mocks, stubs)
• SOLID = réduire, simplifier (SRP, encapsulation, etc.)
www.agiletour.com13/10/2011
SOLID : Top investissement !!!
Critères supplémentaires
• Critères sur le codeo Complexité cyclomatiqueo Couplage afférant / efférento Outillez-vous (NDepend)
• Sous-architecture aussi un problème:o API pas assez contraignanteo Usages hétérogèneso Evolution difficile
www.agiletour.com13/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.com13/10/2011
On commence par les tests
www.agiletour.com13/10/2011
Etape 1
www.agiletour.com13/10/2011
Etape 2
www.agiletour.com13/10/2011
Etape 3
www.agiletour.com13/10/2011
Etape 4
www.agiletour.com13/10/2011
Etape 5
www.agiletour.com13/10/2011
Etape 6
www.agiletour.com13/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.com13/10/2011
Atteindre l’étape « architecture »
www.agiletour.com13/10/2011
DLL API
DLL Métier
Nous sommes retombés de nous-mêmes sur la notion de délégué anonyme :
Notion complexe / Architecture simple
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.com13/10/2011
Récursion code simple / remaniement simple
www.agiletour.com13/10/2011
Code complexe : bon courage !
www.agiletour.com13/10/2011
Exemple vécu
www.agiletour.com13/10/2011
65 étapes !
3 heuresBaby step92% couverture
ROI : immédiat !
Baby steps ?
www.agiletour.com13/10/2011
• Tout petits pas itératifso Correction simplisteo Tests unitaireso 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.com13/10/2011
≈
Pas incompatibles du tout !
www.agiletour.com13/10/2011
• Architecture =o Abstraireo S’adapter
• Agilité =o Simplicité (XP, Lean)o Prééminence des tests
(TDD)o Besoins immédiats
(YAGNI)o Abstraction progressive
(remaniement, architecture émergente)
=
Just Do It
• Ne vous arrêtez pas à :o Pas le temps : remaniement = ROI rapideo Qualité de code suffisante : sustainable
paceo Dette technique trop lourde : retours
multiples (motivation, qualité) dès le premier pas
www.agiletour.com13/10/2011
Questions… et peut-être même réponses !
www.agiletour.com13/10/2011
Recommended