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

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

http://www.editions-eni.fr/Livres/Ecrire-du-code--NET-performant-Profilage-et-bonnes-pratiques/.4_3a6222cf-b921-41f5-886c-c989f77ba994_7c2e4187-5e19-44cd-be7c-3fe25c3358e9_1_0_d9bd8b5e-f324-473f-b1fc-b41b421c950f.html

• Architecture =o Abstraireo Structurero Prévoir

Pourquoi « frères ennemis » ?


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


L’architecture est partout !


Pur codage

Conception

Système

Application

Code

Compilation

Tests unitaires

• « Architecture logicielle »


MYTHE !

Architecture de construction


« Architecture » logicielle ?


Pourquoi ?


http://lovichimodem.centerblog.net/5777381-le-RSA-une-usine-a-gaz-de-plus

Abstraction


http://1.bp.blogspot.com/-8onZT22o5dE/TldUFC7f7RI/AAAAAAAAAHk/KPbPskLOKPM/s1600/Unknown-1.jpeg

Pareil en info ?




http://osakabentures.com/wp-content/uploads/2011/01/crm.jpg

Oui, mais…


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é


≠

Pas si incompatibles ?


• Architecture =o Abstraireo Structurero Prévoiro S’adapter



(YAGNI)

≠

Exemple : TP de formation .NET


Approche Agile


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 ?


Architecture ?Structuration ?

4h

p1

YAGNI encore une fois


• Conséquenceso Pas de BDo Pas de serviceo Pas de persistance !o 1 solution avec 1

projet

≈

Vraiment peu incompatibles…


≠• Architecture

=o Abstraireo Structurero S’adapter



(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


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


MYTHE !

Concept d’ « architecture émergente »


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


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


Facile ≠ simple


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


MYTHE !

Code élégant…


Code élégant… performances catastrophiques


Code élégant et performant ?


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


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


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


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


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


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


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


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)


On commence par les tests


Etape 1


Etape 2


Etape 3


Etape 4


Etape 5


Etape 6


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)


Atteindre l’étape « architecture »


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)


Récursion code simple / remaniement simple


Code complexe : bon courage !


Exemple vécu


65 étapes !

3 heuresBaby step92% couverture

ROI : immédiat !

Baby steps ?


• 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


≈

Pas incompatibles du tout !


• Architecture =o Abstraireo S’adapter



(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


Questions… et peut-être même réponses !


Documents

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