Agile Testing Day | Techniques avancées de refactoring

Notes de l'éditeur

• #18: 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éesP = profondeur d’héritage depuis System.ObjectNb = 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 librairieT = 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.
• #19: 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éesP = profondeur d’héritage depuis System.ObjectNb = 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 librairieT = 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.
• #20: Robert C. Martin en parle aussi dans Clean Code Ils n’empêchent pas le logiciel de fonctionner
• #21: 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)
• #22: 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.
• #24: 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()
• #25: 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.
• #27: 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.
• #31: 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