Le document traite du refactoring dans le développement logiciel, expliquant sa définition et son importance dans l'amélioration de la qualité du code sans changer son comportement observable. Il aborde les concepts de 'code smells', des techniques de refactoring, ainsi que la nécessité d'une bonne couverture de tests. Il propose également des exercices et une auto-évaluation pour optimiser le processus de refactoring.

1. TDD en action : refactoring

2. Repérage
● TDD en action
– Découverte
– Refactoring Nous allons aborder ceci
– Itératif incrémental
– Bases de données
– Développement Web
– Déploiement continu

3. Refactoring
● Définition
● Théorie
● Exemples
● Exercice
● Auto-évaluation

4. Refactoring
● En français vous pourrez trouver le terme
« remaniement »
● Définition dans notre contexte logiciel
Modifier la structure interne d'une partie de code
sans modifier son comportement observable

5. ...donc :
● Le code change
● La couverture fonctionnelle ne change pas
● Les tests passent toujours

6. Gains attendus
● + simple
● + évolutif
● + performant
● …
● La « qualité » du code augmente

7. Qu'est qu'un code de qualité ?
● +simple, +évolutif, +performant ?
● Les programmeurs et les clients ont-ils la même
réponse ?
● Proposition:
Un code de qualité est un code pour lequel le coût
d'ajout d'une nouvelle fonctionnalité reste stable
avec le temps

8. 1.TEST 2.CODE
3.REFACTOR
● Le refactoring a lieu lorsque les tests passent
● Le refactoring n'ajoute pas de fonctionnalité
● Le refactoring concerne le code de production
et le code de test

9. 1.TEST 2.CODE
3.REFACTOR
● Le refactoring consiste à améliorer le code
● Une façon pour améliorer le code consiste à
supprimer le code dangereux
● Vous entendrez parler de « dette technique »
Le refactoring consiste à diminuer la dette
technique

10. 3.REFACTOR
● Qu'est ce que du code « dangereux »?
– Duplication
– Couplage
– Valeurs magiques
– Commentaires (avez-vous envie de réagir à celui-ci ?)
– Conditionnel
– Longues classes ou méthodes
– Code obscur
– ...cherchez « code smells » sur Google

11. 3.REFACTOR
● Connaissez les « code smells » qui vous aident
● Essayez plusieurs smells pour trouver ceux qui
vous aident
● Commencez par étudier les plus faciles
– Bad name
– Switch statement
– Primitive obsession
● Lorsque vous n'avez pas d'intuition
d'amélioration, cherchez les smells qui vous ont
déjà aidé

12. 3.REFACTOR
Un « code smell » est une opportunité, pas une
règle ni une obligation de refactoring.

13. 3.REFACTOR
● Comment supprimer du code « dangereux »?
– Introduire des « Design patterns »
● Création
● Structures
● Comportements
– Respecter les principes SOLID
● Single responsability
● Open/Closed
● Liskov substitution
● Interface segregation
● Dependency inversion

14. 3.REFACTOR
● Comment supprimer du code « dangereux »?

15. 3.REFACTOR
● Une possibilité : piloter vos refactoring par de
nouveaux tests
● Une possibilité : programmer par intention et
laisser les tests existant réagir
● Une possibilité : faire les deux

16. 2 exemples
● Supprimer un smell « God class »
● Supprimer un smell « Comments » dans un test

17. God class

18. Un possible refactoring

19. Notez que
● Ce code est très différent du premier
– Plusieurs collaborateurs ont apparu
– Les collaborateurs sont des interfaces dans cet
exemple en Java
– Les responsabilités des collaborateurs sont
orthogonales
– Des injecteurs sont disponibles
● Les tests utilisent ces injecteurs pour paramétrer cette
classe et faire des vérifications de collaboration

20. Notez aussi que
● Plusieurs chemins sont possibles
● Vous avez probablement besoin d'une vision
– Un modèle cible
– Une architecture cible
– Au moins une intention cible

21. Modèle cible
● Une cible de type
architecture
hexagonale
● ...et des coeurs de la
part de mes enfants
pour me donner du
courage ;)

22. Plusieurs chemins possibles
OrdersView
ErrorView
BlankPage ErrorLog
Center
Repository
Order SqlRepository
DisplayOrdersCommand

23. Plusieurs chemins possibles
OrdersView
ErrorView
BlankPage ErrorLog
Center
Repository
1 Order SqlRepository
DisplayOrdersCommand

24. Plusieurs chemins possibles
OrdersView
ErrorView
BlankPage ErrorLog
2
Center
Repository
1 Order SqlRepository
DisplayOrdersCommand

25. Plusieurs chemins possibles
OrdersView
ErrorView
BlankPage ErrorLog
3
2
Center
Repository
1 Order SqlRepository
DisplayOrdersCommand

26. Souvenez-vous
● Commencez lorsque vos tests passent
● Ecoutez vos tests
● Ne restez pas trop longtemps sans feedback de
la part de votre suite de tests
– En programmant par intention votre suite de
tests passera du rouge au vert plusieurs fois
– En ajoutant de nouveaux tests aussi ;)

27. Un autre exemple
● Supprimer les commentaires
– Les commentaires sont souvent désynchronisés du
code
– Remplacer les commentaires par des tests

28. Supprimer un commentaire

29. Attention
● « supprimer un commentaire » veut dire
– Prendre l'opportunité d'améliorer le code
– Supprimer le bruit
– Augmenter la confiance
● « supprimer un commentaire » ne veut pas dire
– Perdre la documentation
– Perdre quelque chose, quoi que ce soit

30. Un possible refactoring

31. A vous :)

32. Supprimer un « switch »
● Choisissez un code avec du conditionnel
● « Jouez » à le supprimer
● Ce type de code:

33. Approche par de nouveaux tests
● Choisissez une cible
● Décrivez dans un test une étape qui vous
permet d'explorer cette cible
● Exemple: cible === reflection

34. Approche par intention
● Modifiez le code comme vous voudriez qu'il soit
– Faites le compiler
– Laisser votre suite de tests passer au rouge
– Revenez ensuite au vert
● Exemple:

35. Combinez les deux approches
● Modifiez le code comme vous voudriez qu'il soit
– Faites le compiler
– Laisser votre suite de tests passer au rouge
● Identifiez une cible
– Décrivez dans un test une étape vers cette cible
– Faires passer un à un les tests qui vous amène à la
cible
Votre suite de tests contient plusieurs tests rouges
avant de retrouver le vert complet

36. Auto-évaluation
Tests X/V?
J'ai écrit plusieurs tests
Chaque nouveau test commence par ne pas passer
Chaque test a une seule intention
Chaque test a un nom qui illustre l'intention du test
Mes tests illustrent un développement incrémentale
Un autre que moi comprend l'intention de mes tests
Je sais nommer les smells que je supprime en refactoring
Mon backlog de refactoring a réduit
Je sais nommer les Design Patterns que j'ai implémenté
Je sais nommer le principe SOLID que j'ai suivi

37. Merci
● M'aiderez vous à améliorer ce matériel ?
– Qu'avez-vous aimé ?
– Quelles améliorations feriez-vous ?
eric.mignot@gmail.com