Maitrisez votre dette_technique

172 views
114 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
172
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Attention!
    Before opening this template be sure that you have the following fonts installed:
    Novecento wide font family (6 free weight)
    http://typography.synthview.com
    Abattis Cantarell
    http://www.fontsquirrel.com/fonts/cantarell
    Icon Sets Fonts:
    raphaelicons-webfont.ttf from this page: http://icons.marekventur.de
    iconic_stroke.ttf from this page: http://somerandomdude.com/work/iconic
    modernpics.otf from this page: http://www.fontsquirrel.com/fonts/modern-pictograms
    general_foundicons.ttf, social_foundicons.ttf, accessibility_foundicons.ttf from this page: http://www.zurb.com/playground/foundation-icons
    Entypo.otf from this page: http://www.fontsquirrel.com/fonts/entypo
    sosa.ttf from this page: http://www.tenbytwenty.com/sosa.php
    All fonts are permitted free use in commercial projects
  • Maitrisez votre dette_technique

    1. 1. Par Nicolas Jozwiak Maîtrisez votre dette technique
    2. 2. Biographie Nicolas Jozwiak 8 ans d’expérience Coach et craftsman 2
    3. 3. 3
    4. 4. Agenda A Définition dette financière / dette technique B Vocabulaire agile C Conséquences sur les projets D E F Mécanismes sous jacents Résorber la dette Stratégies 4
    5. 5. Définitions 1
    6. 6. Définitions Dette financière 6
    7. 7. Définitions Dette technique • Code Smell • Dette naturelle • Dette intentionnelle Ward Cunningham 7
    8. 8. Vocabulaire 2
    9. 9. Un peu de vocabulaire • Vélocité ‣ Représente la capacité d’une équipe à délivrer un certain nombre de fonctionnalités, exprimée en Story Point pour une période définie • Story Point ‣ Unité de mesure relative pour connaître la difficulté des fonctionnalités • Itération / Sprint ‣ Période de travail 9
    10. 10. Conséquences 3
    11. 11. Les conséquences 11
    12. 12. Les conséquences 12
    13. 13. Les conséquences 13
    14. 14. Mécanismes 4
    15. 15. Les mécanismes sous jacents 15
    16. 16. Les mécanismes sous jacents • Prise de conscience en catastrophe ‣ Maintenances longues ‣ Evolutions difficiles à mettre en place ‣ Manque de fiabilité 16
    17. 17. Les mécanismes sous jacents • Pourquoi une maintenance ou évolution peut prendre beaucoup de temps à développer ? ‣ La tolérance aux changements 17
    18. 18. Tolérance aux changements • Comment juger de la tolérance aux changement d’un code ? ‣ La conception ‣ La lisibilité du code ‣ Les tests 18
    19. 19. Tolérance aux changements • Conception ‣ SOLID ‣ Domain Driven Design • Découpage cohérent et clair de l’application 19
    20. 20. Tolérance aux changements • Lisibilité ‣ Interaction humain / machine • Tests ‣ Garants de l’application ‣ Mise en place prend du temps 20
    21. 21. Tolérance aux changements • Le Test Driven Development (TDD) ‣ Ecrire les tests avant les développements 21
    22. 22. Résorber la dette 5
    23. 23. Les bonnes pratiques de développements • Extreme programming (XP) ‣ Refactoring ‣ Pair Programming ‣ Revue de code 23
    24. 24. Refactoring 24
    25. 25. Pair programming 25
    26. 26. Revue de code 26
    27. 27. 27
    28. 28. 28
    29. 29. Stratégies 6
    30. 30. Les stratégies • Démarrage d’un nouveau projet 30
    31. 31. Les stratégies • Intervention sur des projets existants ‣ À quel moment appliquer les bonnes pratiques ? ‣ Quelles stratégies s’offrent à nous ? 31
    32. 32. Les stratégies • Gérer la dette au quotidien ‣ Appliquer les bonnes pratiques dans les cycles de développements ‣ Stratégie à long terme 32
    33. 33. Les stratégies • Refactorings mineurs ‣ Intégration au fil de l’eau » Peu de conséquences sur le comportement de l’application » Renommages, factorisations, etc 33
    34. 34. Les stratégies • Refactorings majeurs ‣ Impacts importants » Ne pas mettre en péril l’application 34
    35. 35. Les stratégies • Refactorings de longues durées ‣ Migration d’une technologie » Outils de gestion de versions (SVN, GIT) 35
    36. 36. Les stratégies • Recoder 36
    37. 37. Conclusion 6
    38. 38. Conclusion • Réduire la dette au quotidien • Dette introduite au quotidien ‣ Dette toxique • Impossible à supprimer totalement ‣ Bonnes pratiques, outils et stratégies nous permettent de grandement l’atténuer 38
    39. 39. Conclusion • Restreindre les livraisons ‣ Garder un niveau de qualité suffisant • Craftsmanship 39
    40. 40. Conclusion 40
    41. 41. THANK YOU FOR watching Merci!
    42. 42. Bibliographie • Kyle Brown - Paying back technical debt, 2010 http://www.ibm.com/developerworks/websphere/techjournal/1001_col_brown/ 1001_col_brown.html • Martin Fowler – Technical Debt, 2009 - http://martinfowler.com/bliki/TechnicalDebt.html • Steve McConnell – Technical Debt, 2007 http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx • Tom Brazier - Managing Technical Debt, 2007 - http://accu.org/index.php/journals/1301 • Kane Mar – Technical Debt and Design Death, 2006 http://www.scrumalliance.org/articles/14-technical-debt-and-design-death • Principle of OOD - http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod • Working Effectively with Legacy Code, Michael Feathers, 2004 42

    ×