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