Architecture Agile durable (v 2.0)

Beaucoup d’équipes ont embrassé Scrum sans considérer l’architecture nécessaire pour soutenir un tel rythme et minimiser la dette technique.

Comment adopter une architecture émergente, malléable et facile à changer? Bref, comment faire du développement logiciel durable?

## Version 2.0

Présente l'architecture durable sous l'angle des 5 pièges architecturaux courants. Pourquoi est-ce que nos architectures ne sont pas évolutives et Agiles? Quels sont les 5 principaux problèmes qui mènent à une architecture éphémère?

Transcript

1. FÉLIX-ANTOINE BOURBONNAIS
   B.ING., M.SC., PSM
   Version 2.0 – Mai 2016
   Architecture Agile
   durable
   

   View Slide

2. View Slide

3. public class
   MonTraitement
   }
   {
   

   View Slide

4. 4
   Félix-Antoine Bourbonnais
   B.ing., PSM, M.Sc.
   

   View Slide

5. 5
   Formations Accompagnement Diagnostics Conférences
   Félix-Antoine Bourbonnais
   fbourbonnais@elapsetech.com
   

   View Slide

6. 6
   Coach
   Mentor
   Formateur
   Félix-Antoine Bourbonnais
   fbourbonnais@elapsetech.com
   TECH
   ÉQUIPE
   AGILE
   

   View Slide

7. 7 7
   Expert en…
   / Tests automatisés
   / Pratiques de développement
   / Architecture évolutive
   / Spécification par l’exemple et BDD
   / Agilité et Scrum
   Félix-Antoine Bourbonnais
   

   View Slide

8. 8
   Image de Eyesplash
   http://commons.wikimedia.org/wiki/File:Welkom_willkommen_Welcome_Bienvenue_Benvenuto.jpg
   

   View Slide

9. 9
   Le défi moderne:
   la maintenabilité !
   

   View Slide

10. 10
    Ce n’est pas une course
    courte piste!
    

    View Slide

11. 11
    C’est un marathon
    … sans fin !
    

    View Slide

12. 12
    Pour gagner, il faut une
    vélocité stable…
    

    View Slide

13. 13
    Pour cela il faut s’outiller
    pour garder le rythme!
    

    View Slide

14. Gestion de projets
    durable
    +
    Architecture
    durable
    +
    Pratiques
    durables
    Image : http://robclearyphoto.blogspot.ca/2012/06/green-roof-cookfox.html
    Développement logiciel durable
    14
    

    View Slide

15. 1. They want to use an agile process, and pick Scrum
    2. They adopt the Scrum practices, and maybe even
    the principles
    3. After a while progress is slow because the code
    base is a mess
    -- Martin Fowler
    Flacid Scrum
    

    View Slide

16. 17
    Nos prochains 90 minutes…
    17
    

    View Slide

17. DÉFIS DU DÉVELOPPEMENT MODERNE
    Les
    18
    

    View Slide

18. 19
    L’informatique est l’ADN de
    nos entreprises
    

    View Slide

19. 20
    Ça bougeait vite…
    Et ça bouge encore plus vite !
    

    View Slide

20. Le futur
    technologique
    est
    incertain et il faut
    livrer de plus en plus
    vite…
    La réalité
    21
    Cloud
    Big-Data
    NoSQL
    Distribué
    Mobile
    

    View Slide

21. 22
    L’architecture doit donc
    évoluer avec l’entreprise…
    et donc être flexible !
    

    View Slide

22. 23
    Est-ce que nos
    architectures sont Agiles ?
    Mais…
    

    View Slide

23. 24
    Mais il ne faut
    surtout pas ralentir…
    

    View Slide

24. 25
    Le développement logiciel est
    désormais un flot perpétuel…
    

    View Slide

25. 26
    … sans compromettre
    la qualité!
    

    View Slide

26. Les principes d’architecture
    durable existent!
    Comment augmenter ma maintenabilité alors ?
    27
    

    View Slide

27. 28
    On veut une architecture durable,
    modulaire et flexible !
    

    View Slide

28. Pour s’adapter aux nouvelles
    réalités, il
    faut revisiter
    l’OO à la lumière de ces
    défis..
    Notre objectif
    29
    

    View Slide

29. LES FONDEMENTS
    D’UNE ARCHITECTURE DURABLE
    Partie 2
    31
    Architecture durable
    

    View Slide

30. Rien n’est noir ou
    blanc…
    Tout est une question de
    connaître pour appliquer
    ou non les concepts selon
    le contexte
    Avertissement
    32
    

    View Slide

31. Tout est à propos de
    casser les vagues de modifications!
    Architecture évolutive
    33
    

    View Slide

32. A good architect maximizes
    the number of decisions not
    made
    -- Robert C. Martin
    34
    

    View Slide

33. LES 5 PIÈGES QUI FONT
    UNE ARCHITECTURE ÉPHÉMÈRE...
    Partie 2
    35
    Architecture durable
    

    View Slide

34. LE MANQUE D’ABSTRACTION…
    36
    Piège
    1
    

    View Slide

35. Qu’est-ce que l’OO a apporté
    de nouveau ?
    37
    

    View Slide

36. 38
    La gestion des dépendances !
    Orientation objet
    

    View Slide

37. La grande contribution de l’OO est la
    capacité à inverser la
    dépendance par rapport
    au flot d’exécution
    Inversion des dépendances
    39
    

    View Slide

38. L’abstraction
    Le
    paradigme
    OO implique l’utilisation
    d’abstractions
    40
    

    View Slide

39. Les dépendances
    Le polymorphisme
    est à la base même de l’OO
    41
    On veut brancher les
    dépendances, pas les souder!
    

    View Slide

40. L’effet d’avalanche !
    Votre pire risque...
    42
    Image Andre Charland / Flickr
    

    View Slide

41. Notre objectif…
    Contenir les vagues causées par les modifications !
    

    View Slide

42. Briser les dépendances
    44
    X
    SQLDb
    MapDb
    if( dbType == SQL )
    ... sqlDb.query("SELECT id ..."
    else
    ... mapDb.get(id)
    X
    MapRepo
    SqlRepo
    repository.findById(id)
    Repository
    

    View Slide

43. L’ANÉMIE ET L’OBSESSION DES “GET”
    45
    Piège
    2
    

    View Slide

44. Le « Tell don’t Ask »
    Image: sheelamohan et jscreationzs / FreeDigitalPhotos.net 46
    

    View Slide

45. Domaine où les objets ont des
    données mais pas de
    comportements.
    Les comportements sont
    uniquement dans des objets
    « Managers » qui gèrent le domaine
    Domaine anémique
    47
    

    View Slide

46. Non pas forcément
    (ex.: Rails)
    Mais est-ce un choix
    conscient ou par défaut?
    Est-ce mauvais ?
    48
    

    View Slide

47. L’UTILISATION D’UNE ARCHITECTURE UNIQUE…
    49
    Piège
    3
    

    View Slide

48. 50
    2 grands contextes
    

    View Slide

49. 51
    Un projet peut avoir
    plusieurs
    architectures !
    De nos jours…
    

    View Slide

50. 52
    Chaque style, pattern, etc.
    a des effets secondaires !
    Rien n’est parfait…
    

    View Slide

51. Le drame….
    Les organisations
    reproduisent toujours le
    même modèle architectural
    sans se poser de
    questions !
    53
    

    View Slide

52. MÉCONNAISSANCE
    DES « PATTERNS » ET « PRINCIPES »
    54
    Piège
    4
    

    View Slide

53. • SRP
    Single Responsibility
    • OCP
    Open Closed
    • LSP
    Liskov Substitution
    • ISP
    Interface Segregation
    • DIP
    Dependency Inversion
    Principes S.O.L.I.D.
    55
    

    View Slide

54. 56
    Les Design Pattern
    56
    Factories
    

    View Slide

55. 57
    Les Patrons pour entreprises
    57
    Domain
    Layer
    

    View Slide

56. Il faut comprendre les effets secondaires
    des patrons de conception…
    Les prendre quand vous n’avez pas la
    maladie peut vous tuer!
    Attention!
    

    View Slide

57. LA MAUVAISE COMPRÉHENSION DES « COUCHES »
    59
    Piège
    5
    

    View Slide

58. 60
    Le modèle en “couches”
    60
    Présentation : GUI, WS …
    Domaine d’affaires
    Persistance
    et services externes
    Problème…
    

    View Slide

59. 61
    Image tiré de:
    http://www.dossier-andreas.net/software_architecture/ports_and_adapters.html
    Et si les couches étaient des « plugins » ?
    61
    

    View Slide

60. Modèles architecturaux
    Hexagonal / Port&Adapter
    http://www.duncannisbet.co.uk/hexagonal-architecture-for-testers-part-1 62
    

    View Slide

61. Modèles architecturaux
    Clean Architecture
    http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html 63
    

    View Slide

62. Il faut savoir les utiliser au bon moment!
    Tackling Complexity in the
    Heart of Software
    Domain
    Driven Design (DDD)
    

    View Slide

63. CONCLUSION
    65
    Architecture durable
    

    View Slide

64. Ceci n’est pas une
    invitation au BDUF !
    (Big Design Up Front)
    Mais…
    66
    

    View Slide

65. 67
    Savez-vous ce que sera votre produit et
    la technologie dans 5 ans ?
    

    View Slide

66. 68
    Il n’est pas nécessaire de
    deviner. Il faut simplement
    s’outiller pour évoluer
    avec eux!
    

    View Slide

67. 69
    Mais l’architecture durable
    n’est pas suffisante…
    Il reste les pratiques durables…
    

    View Slide

68. View Slide

69. 71
    http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/ 71
    Le développement logiciel
    n’est pas un jeu de Jenga !
    

    View Slide

70. Merci.
    

    View Slide

71. 73
    Merci
    Notre site
    elapsetech.com
    Notre blogue
    developpementagile.com
    Twitter
    @fbourbonnais | @elapsetech
    Mon courriel
    fbourbonnais@elapsetech.com
    Mon LinkedIn
    linkedin.com/in/fbourbonnais/fr
    conferences.elapsetech.com
    Diapositives
    Nos présentations, chez vous!
    

    View Slide