Agile Testing Day | Techniques avancées de refactoring
•Télécharger en tant que PPTX, PDF•
0 j'aime•307 vues
Tester du code neuf est (relativement) facile. Tester et refactorer une application existante peut se révéler extrêmement complexe. Découvrez comment analyser le champ de bataille, planifier l'intervention et sécuriser le refactoring et enfin quels outils vous y aideront.
Recommandé
Contenu connexe
En vedette
En vedette (20)
Agile Testing Day | Techniques avancées de refactoring
- 1. Techniques avancées de refactoring Parce qu’on a tous un jour rêvé de devenir un Ninja
- 2. Pourquoi parler de refactoring aujourd’hui ? Tester une nouvelle application conçue pour être testable, c’est facile. Oui, mais… et l’existant ?
- 3. 1. Description du champ de bataille 2. Détecter et identifier l’ennemi 3. Techniques de combat et armement
- 4. Legacy • “Le code des autres” (mon voisin de bureau) • Du code non-supporté • Tout code déjà écrit • “Code without automated tests” (Michael Feathers in Working Effectively with Legacy Code)
- 7. Refactoring
- 8. Refactoring Le refactoring consiste à améliorer du code existant sans modifier son comportement.
- 9. SOLID Single responsibility Open for extension, closed for modification Liskov substitution Interface segregation Dependency inversion
- 10. Clean Code Le code propre est : Simple Expressif Lisible Organisé Testé
- 11. Clean Code
- 12. Bonnes pratiques KISS YAGNI DRY Keep it simple and stupid You aren’t going to need it Don’t repeat yourself
- 13. 1. Description du champ de bataille 2. Détecter et identifier l’ennemi 3. Techniques de combat et armement
- 14. Cartographier
- 15. Cartographier
- 16. Mesurer la qualité du code Parfois, l’estimation au doigt mouillé n’est pas suffisante.
- 17. Mesurer la qualité du code Nombre de lignes de code Complexité cyclomatique Taux de couverture Indice de spécialisation Indice d’instabilité Coefficient d’abstraction Distance de bonne conception Taux de duplication Volume de commentaires Ration de méthodes trop longues Nombre de classes par librairie Nombre de méthodes par classe
- 18. Mesurer la qualité du code
- 19. Code smells Les code smells sont un indicateur de problèmes de design applicatif. « Les code smells sont des symptômes de problèmes plus profonds. » Martin Fowler
- 20. Code smells Les Gros Les méthodes trop longues Les classes trop grosses La liste de paramètres interminable L’abus de primitives La dissémination de données
- 21. Code smells Les Empêcheurs de Modifier en Rond La chirurgie au fusil à pompe Le feu de paille Les structures d’héritage parallèles
- 22. Code smells Les Dispensables Les commentaires Le code mort Le code dupliqué Les lazy classes Les DAO sans méthodes métier La généricité spéculative
- 23. Code smells Les Abus de la Programmation Orientée Objet Les switchs et if/else if/else if/else Les champs temporaires L’héritage abusif Le manque d’homogénéité
- 24. Code smells Les Problèmes de Couplage Feature Envy Intimité inappropriée Enchaînements excessifs Man in the middle
- 25. 1. Description du champ de bataille 2. Détecter et identifier l’ennemi 3. Techniques de combat et armement
- 26. L’Arme Fatale
- 27. Cleaning the deck • Renommage • Déplacements de blocs de code
- 28. Code smells Amélioration de la lisibilité et de la localisation du code Rename Move to… • Move up • Move down Extract variable Inline variable
- 29. Code smells Découpage et organisation du code Découpage de grosses interfaces en petites interfaces ciblées Extraction de classe Extraction de méthode
- 30. Code smells Abstraction Encapsuler un champ Remplacer les conditionnelles par du polymorphisme Remplacer un code de type par un pattern State ou Strategy Extraction d’interface Ajout de paramètre
- 31. Fakes, mocks et stubs
- 32. Golden Master
- 33. Bien armer ses soldats
Notes de l'éditeur
- Complexité cyclomatique = nombre de noeuds if, case, while… L’indice de spécialisation d’une classe : SPE = (S*P) / Nb S = nombre de méthodes surchargées P = profondeur d’héritage depuis System.Object Nb = nombre de méthodes de la classe Une classe contenant un indice SPE trop élevé nécessite un refactoring. Pourquoi hériter d’une classe si c’est pour en surcharger beaucoup de ses méthodes ? L’indice d’instabilité d’une librairie : INS = Out / (In + Out) Out = nombre de classes externes dépendant de la librairie (responsabilité) In = nombre de classes de la librairie dépendant de classes externes 0 <= INS <= 1 Pour la classe System.String, qui ne dépend pas de grand monde, mais dont au contraire, énormément d’autres classes dépendent, INS tend vers 1, et un refactoring de cette classe sera donc risqué. Au contraire, votre classe MaLibrairie.MesUtilitairesMetier, INS tend vers 0. Le coefficient d’abstraction d’une librairie : ABS = I / T I = nombre d’interfaces de la librairie T = nombre total de types de la librairie (classes et interfaces) 0 <= ABS <= 1 Il n’y a pas de bonne ou mauvaise valeur pour ABS. Une librairie d’interfaces aura ABS = 100%, alors qu’une librairie d’implémentation aura ABS = 0%. La distance de la bonne conception d’une librairie : D = | INS + ABS – 1 | Idéalement, D tend vers 0. Les 2 cas idéaux sont INS = 0 et ABS = 1 : la librairie est totalement abstraite et parfaitement stable. INS = 1 et ABS = 0 : la librairie est parfaitement concrète et très instable, car elle dépend d’une multitude d’autres librairies.
- Complexité cyclomatique = nombre de noeuds if, case, while… L’indice de spécialisation d’une classe : SPE = (S*P) / Nb S = nombre de méthodes surchargées P = profondeur d’héritage depuis System.Object Nb = nombre de méthodes de la classe Une classe contenant un indice SPE trop élevé nécessite un refactoring. Pourquoi hériter d’une classe si c’est pour en surcharger beaucoup de ses méthodes ? L’indice d’instabilité d’une librairie : INS = Out / (In + Out) Out = nombre de classes externes dépendant de la librairie (responsabilité) In = nombre de classes de la librairie dépendant de classes externes 0 <= INS <= 1 Pour la classe System.String, qui ne dépend pas de grand monde, mais dont au contraire, énormément d’autres classes dépendent, INS tend vers 1, et un refactoring de cette classe sera donc risqué. Au contraire, votre classe MaLibrairie.MesUtilitairesMetier, INS tend vers 0. Le coefficient d’abstraction d’une librairie : ABS = I / T I = nombre d’interfaces de la librairie T = nombre total de types de la librairie (classes et interfaces) 0 <= ABS <= 1 Il n’y a pas de bonne ou mauvaise valeur pour ABS. Une librairie d’interfaces aura ABS = 100%, alors qu’une librairie d’implémentation aura ABS = 0%. La distance de la bonne conception d’une librairie : D = | INS + ABS – 1 | Idéalement, D tend vers 0. Les 2 cas idéaux sont INS = 0 et ABS = 1 : la librairie est totalement abstraite et parfaitement stable. INS = 1 et ABS = 0 : la librairie est parfaitement concrète et très instable, car elle dépend d’une multitude d’autres librairies.
- Robert C. Martin en parle aussi dans Clean Code Ils n’empêchent pas le logiciel de fonctionner
- La dissémination de données : quand on retrouve un même groupe de variables à plusieurs endroits (comme des credentials d’appels de webservice ou d’accès à une base de données)
- Chirurgie au fusil à pompe : quand pour une modif d’une classe, il faut modifier beaucoup d’autres classes Feu de paille : ressemble au precedent, mais c’est en fait l’inverse. C’est quand il faut modifier d’autres membres dans une même classe. Ex : j’ajoute un type de produit, et je suis modifier le Get, Create, Delete, Update… Les structures d’héritage parallèles : quand pour créer une sous-classe de A, je dois aussi créer une sous-classe de B.
- Les champs temporaires : ceux qui ne sont remplis dans certains cas Héritage abusif : quand la sous-classe n’utilise qu’une partie des membres de la classe-mère Manque d’homogénéité : deux classes exposent des méthodes quasi-identiques, mais avec des noms différents. Ex : Modify() et Update()
- Intimité : quand deux classes passent trop de temps ensemble. Les classes devraient en savoir le moins possible sur les autres. Enchaînements excessifs : les intermédiaires sont des dépendances cachées Man in the middle : si une classe délègue son travail, quelle est son utilité ? Limitez l’utilisation de wrappers.
- On ne nait pas Craftsman, c’est le résultat d’une demarche faite dans ce but : conferences, veille, auto-formation, conferences, communautés. ENTRAÎNEZ-VOUS ! Katas, hackathons.
- Code de type - ex : Employee.isManager qui détermine un comportement dans certaines méthodes Ajout de paramètre : injection plutôt qu’instanciation pour répartir les responsabilités