1. Par Nicolas Jozwiak
Maîtrisez votre dette
technique

2. Biographie
Nicolas Jozwiak
8 ans d’expérience
Coach et craftsman
2

3. 3

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. Définitions
1

6. Définitions
Dette financière
6

7. Définitions
Dette technique
• Code Smell
• Dette naturelle
• Dette intentionnelle
Ward Cunningham
7

8. Vocabulaire
2

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. Conséquences
3

11. Les conséquences
11

12. Les conséquences
12

13. Les conséquences
13

14. Mécanismes
4

15. Les mécanismes sous jacents
15

16. Les mécanismes sous jacents
• Prise de conscience en catastrophe
‣ Maintenances longues
‣ Evolutions difficiles à mettre en place
‣ Manque de fiabilité
16

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. 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. Tolérance aux changements
• Conception
‣ SOLID
‣ Domain Driven Design
• Découpage cohérent et clair de l’application
19

20. Tolérance aux changements
• Lisibilité
‣ Interaction humain / machine
• Tests
‣ Garants de l’application
‣ Mise en place prend du temps
20

21. Tolérance aux changements
• Le Test Driven
Development (TDD)
‣ Ecrire les tests avant
les développements
21

22. Résorber
la dette
5

23. Les bonnes pratiques de développements
• Extreme programming (XP)
‣ Refactoring
‣ Pair Programming
‣ Revue de code
23

24. Refactoring
24

25. Pair programming
25

26. Revue de code
26

27. 27

28. 28

29. Stratégies
6

30. Les stratégies
• Démarrage d’un nouveau projet
30

31. Les stratégies
• Intervention sur des
projets existants
‣ À quel moment appliquer les
bonnes pratiques ?
‣ Quelles stratégies s’offrent à
nous ?
31

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. 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. Les stratégies
• Refactorings majeurs
‣ Impacts importants
» Ne pas mettre en péril l’application
34

35. Les stratégies
• Refactorings de longues durées
‣ Migration d’une technologie
» Outils de gestion de versions (SVN, GIT)
35

36. Les stratégies
• Recoder
36

37. Conclusion
6

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. Conclusion
• Restreindre les livraisons
‣ Garder un niveau de qualité
suffisant
• Craftsmanship
39

40. Conclusion
40

41. THANK
YOU
FOR watching
Merci!

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