Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Personnellement je n'ai jamais réellement pris le temps, sur un projet pro, de faire du refactoring pur.
Etant en environnement start-up sur un projet unique, c'est régulièrement que je repasse dans des classes pour y ajouter/modifier du contenu, j'en profite alors pour faire un peu de refactoring. En tant que débutant, j'ignore si ma manoeuvre est la plus optimale, mais au moins elle permet (d'essayer) d'améliorer notre code sans "perdre" son temps à refactoriser (aux yeux du patron).
Les chercheurs n'affirment rien de tel, c'est les lecteurs/forumeurs qui ont réinterprété leurs propos (en se saisissant de la perche tendue par l'auteur de la new).Envoyé par deltree
Dans l'article cité en source les chercheurs disent ce qu'ils ont fait, et que dans leur étude ils n'ont pas vu d'amélioration de la qualité du code après refactorisation, jamais ils essayent de généraliser au monde entier leurs résultats. D'ailleurs lisez la dernière phrase de leur article :
it would be better that the same experimental setup can be executed in industry environment with the industry experts and with the industry level matured source code.
Je suis d'accord, il est important qu'une fonctionnalité soit validée avant d'être refactoriser.
Les tests automatiques étant facile à rejouer, il est important d'en avoir pour vérifier que la fonctionnalité ne change pas de comportement au cours de ce refactoring.
Là, je suis un peu moins d'accord.
Le temps, il faut le prendre. Si on a trouver le temps de codé une fonctionnalité, d'écrire des tests unitaires et fonctionnels (pas forcement dans cet ordres => TDD) on doit pouvoir prendre un peu de temps pour le refactoring.
Quand cela est nécessaire? Mieux que le livre de Martin Fowler, qui donne un très bonne base de (re)lecture de son code, je prônerais pour l'utilisation d'outils d'analyse statique de code (comme par exemple les outil lint, pylint, lintj4, jslint, FxCop...)
Ces outils donnent une note objective sur des règles modernes et incite une vrai politique de normalisation du code professionnel.
Cela peut mettre en évidence un complexité (cyclomatique) trop haute, comme des nommages de variables/classes/fonctions mal adaptées, des copiers-collers (qui peuvent vite devenir des copiers-merdés) ou des avertissements de problèmes potentiels.
Pour moi, le refactoring n'est pas une option, mais cela fait partie du travail de développement logiciel au même titre que l'analyse des besoins utilisateurs et que les tests unitaires et fonctionnels.
Mais comme d'autres l'ont indiqué, cela nécessite un certain recule dans ses pratiques de developpement: pas sûr qu'un étudiant ou un jeune diplômé l'ait.
Ouf, les vieux briscards ont encore des choses à leur apprendre
Là, je suis un peu moins d'accord.
Le temps, il faut le prendre. Si on a trouver le temps de codé une fonctionnalité, d'écrire des tests unitaires et fonctionnels (pas forcement dans cet ordres => TDD
Quand cela est nécessaire? Mieux que le livre de Martin Fowler, qui donne un très bonne base de (re)lecture de son code, je prônerais pour l'utilisation d'outils d'analyse statique de code (comme par exemple les outil lint, pylint, lintj4, jslint, FxCop...)
Ces outils donnent une note objective sur des règles modernes et incite une vrai politique de normalisation du code professionnel.
Cela peut mettre en évidence un complexité (cyclomatique) trop haute, comme des nommages de variables/classes/fonctions mal adaptées, des copiers-collers (qui peuvent vite devenir des copiers-merdés
Pour moi, le refactoring n'est pas une option, mais cela fait partie du travail de développement logiciel au même titre que l'analyse des besoins utilisateurs et que les tests unitaires et fonctionnels.
Mais comme d'autres l'ont indiqué, cela nécessite un certain recule dans ses pratiques de developpement: pas sûr qu'un étudiant ou un jeune diplômé l'ait.
Ouf, les vieux briscards ont encore des choses à leur apprendre
Je suis entièrement d'accord,
cela dit cela dépends de ton contexte de travail, si ton entreprise te surcharge tu as rarement le temps de reprendre ton code
Personnellement, je m'attache énormément à la qualité de mon code.
Cela dit quand tu tombe sur une entreprise qui t'interdit de reffactorer ton propre code dès que les devs sont livrés*, ben tu ne peut pas faire grand chose...
Pareil quand tu tombe dans une équipe ou personne ne sait ce qu'est un pattern de conception (très fréquent !)
* je parle bien-sur d'une appli non critique et de dev livrés 1 mois avant une recette
Ben, faut pas livrer tant que le refactoring n'est pas fait.
Pour moi, ca fait partie du "Definition of Done".
Je pense qu'il faut intégrer la règle que le refactoring doit être fait, comme la validation ou le manuel utilisateur, avant livraison.
Personnellement, je n'aime pas revenir sur une fonctionnalité 3-6 mois après que je l'ai développé pour du correctif ou du refactoring.
Quand on travail sur une fonctionnalité pour un client, on le fait correctement ... ou on le fait pas.
C'est le même débat de savoir si on doit avoir des tests unitaires, fonctionnels ou si on doit validé le produit que l'on livre au client.
Si on écoutait les financiers qui régissent notre travail, il faudrait juste "coder à l’arrache" une fonctionnalité comme on le sent (pas de spécifications) et la livrée dès que ça compile (tester? une perte de temps)
pffff, la qualité, ça ne sert à rien ... et puis le client payera une maintenance
parfois quand t'y reviens 6 mois plus tard, tu as les idées plus clair, et tu te dis :
"si je n'arrive pas à relire mon code c'est qu'il y'a un gros soucis"
j'ajouterai à ta dernière phrase la doctrine suivante qui m'irrite au plus haut point : "Tant que ça fonctionne on s'en fous du code, des tests et des mises à jour des libss"
"Pour juger de la validité d'une technique demandant de l'expérience, nous allons demander à des étudiants de l'appliquer...". Et on fait une "news" avec ça ? Et je parle même pas des autres points soulevés comme la taille du code utilisé.
En faite, cette news n'est pas inintéressante en soit, c'est la conclusion induite dans le titre qui est discutable.
Ils sont partie du postulat que des étudiants en informatique était compétent à réaliser ce type d'étude
=> conclusion logique "La refactorisation est-elle réellement utile ?" vu que des gens compétent n'ont pas prouvé la pertinence de cette technique.
Mais si on prenait le postulat que le refactoring est une technique très utile.
=> La conclusion serait différent, plus dans le genre "Des étudiants en informatique n'ont pas le recule suffisant pour appliquer correctement le refactoring"
Tous est un histoire de point de vu.
Je conclurais peut être alors de façon plus neutre : "Le refactoring ne semble pas réellement utile pour certains étudiants sri lankais sur un projet d'étude de 4900 lignes"
Par contre, ce titre est un peu moins vendeur
Une telle étude aurait sans doute était plus pertinente d'un point de vue économique.
Avant de cliquer sur le lien, je pensais d'ailleurs que l'article allait traiter des coûts du refactoring à court terme VS les bénéfices sur le long terme.
Mais dans l'absolu, le refactoring est utile. Un bon refactoring augmente la maintenabilité et l'évolutivité d'une base de code, ça ne fait aucun doute. C'est même le but.
Là où l'article est intéressant sans forcément le vouloir, c'est en mettant c'est en s'appuyant sur 10 techniques de refactoring.
L'étude y répond sans s'en rendre compte que tout ou partie de ces 10 techniques ne sont probablement pas pertinente (en supposant de la compétence des étudiants qui n'est évidemment pas prouvée).
Une question qui reste ouverte encore aujourd'hui est de savoir quels sont les différents refactorings à réaliser pour optimiser certains aspects d'une base de code.
Une étude débile
J'ai des bilans SONAR de mes refactoring de code JAVA :
on a plus de :
- classes
- code test , car un petite classe est facile à tester
- detection de bug
on a moins :
- insructions (/ par 3) , je ne compte pas les déclarations de classes, ...
- pas d'erreur de type cyclomatique >7
- de mauvaise surprise
Nota d'apres leur rapport le nombre cyclomatique augemente => il ne maîtrise pas le reusinage de code, personnes incompétentes
Par exemple , j'ai un college qui à bloqué une semaine sur un bug, une operation de refactoring (de 2 heure ce matin ) a corrigé le problème sans même l'indentifier (simplement par la mise en oeuvre des invariants de l'application)
AA++
Etude biaisée par la nature du projet
Que voulait-il faire, le refactoring du contenu des méthodes avec des meilleurs algorithmes ou le refactoring d'architecture des classes avec des design-pattern, ou les deux ou juste le renommage des classes et des méthodes?
La nature du projet va aussi déterminer l'intérêt du refactoring, entre par exemple une librairie réutilisable ou une winform drag&drop et au finale, l'intérêt du projet va aller de pair avec l'intérêt du refactoring.
Ainsi, 5000 lignes de codes, pour une profondeur d'héritage de 5 et pour un total 200 classes couplées peuvent être retrouver sur un projet d'une winform avec plusieurs user-control qui héritent les uns des autres, dont 80% est généré par visual studio, et comme il n'y a eu aucune autre problème métier pouvant avoir plusieurs résolution grâce à la POO pour réfléchir à LA meilleure solution, cette étude est pipée.
Il y a plusieurs points qui posent question dans l'étude :
- Les refactorings faits sur la base de code testée sont essentiellement à base de design patterns. Or, rien n'est dit sur la connaissance de la population testée (étudiants ou diplômés fraichement sortis de la fac) de ces design patterns.
Les DP sont un vocabulaire et des façons de faire communes établies pour que les développeurs se comprennent entre eux. Si les étudiants testés ne les connaissent pas, on ne peut rien conclure sur la partie "Analysabilité" de l'étude car c'est comme si on avait demandé à ces étudiants Sri Lankais de comprendre un texte en Serbo-Croate (l'application legacy) et un en Finlandais (l'application refactorée)... l'analysabilité du texte aurait bien évidemment été également mauvaise dans les deux cas. Comme tout savoir-faire, il faut apprendre le langage des design patterns avant de le comprendre.
Par ailleurs, c'est un peu facile de sortir le label "préconisé par Martin Fowler" alors qu'on a aucune idée si les 10 refactorings choisis parmi 72 possibles sont pertinents par rapport aux défauts de la base de code d'origine.
- Rename ou encore Extract (method/class...) ne font pas partie des refactorings appliqués. Or, ce sont les plus basiques et parmi les plus fréquemment utilisés pour améliorer la compréhension du code. Une application legacy (c'est le cas dans l'étude) qui de base a des nommages sortis de nulle part et un découpage en classes illogique va rester très peu intelligible, même en appliquant tous les refactorings choisis dans l'expérience. Un point en moins pour la pertinence de la partie "Analysability".
- La partie "Changeability" fait intervenir uniquement du debug, on ne parle pas de temps donné aux participants pour faire de l'ajout de fonctionnalité. Qui plus est, les bugs ont été introduits volontairement par les expérimentateurs. Il s'agit donc simplement de retrouver où sont les bugs et de rectifier le code. Je ne pense pas que le degré de refactoring du code ait un effet extraordinaire sur ce genre de changement, ni que personne l'ait affirmé un jour. Les tests automatisés peuvent jouer un peu plus, mais ils ne sont pas mentionnés dans l'étude. Il aurait été plus intéressant de faire la comparaison sur des modifications fonctionnelles dépassant juste 90 minutes de bugfix.
- Aucun des refactorings sélectionnés ne vise à améliorer les performances. Les résultats des deux dernières sections de l'étude, Time et Resource Utilization sont donc des lapalissades. Un refactoring dont ce n'est pas le but ne va évidemment pas magiquement améliorer les perfs.
Les auteurs conviennent eux-mêmes dans la conclusion que plusieurs reproches peuvent être faits à l'étude, dont le choix d'étudiants comme population de test et celui des design patterns. On a envie de dire, pourquoi ne pas y avoir pensé dès le début et choisi autre chose ?
Encore une étude bidon
Encore une "étude" pondue visiblement par des incompétents. Ces braves gens n'ont certainement pas eu à développer, puis maintenir pendant 15 ans, un logiciel de CAD par exemple. Bon, évidemment, il y a des appli qu'on écrit en 15 jours, puis jette 150 jours après. Là, évidemment, pas besoin de refactoring. Pour le reste, il faut être extraordinairement génial pour choisir tout de suite non seulement la bonne structure, mais aussi le bon découpage en modules et autres sous-programmes, et plus encore pour choisir d'emblée les bons noms de variables, routines etc.
Pauvres étudiants à qui on fait faire ça, .... et pauvres employeurs pour qui ils travailleront plus tard.
Je n'ai pas lu l'article d'origine, mais mon avis rejoint tout simplement ce qui s'est déjà dit au dessus : c'est un bon début, mais peut mieux faire.
Pour ma part, je considérerai plutôt une étude sur :
- 5-10 gros projets différents
- sur chacun de ces projets cibler avec les teams correspondantes les points durs pouvant être refactorés
- refactorer le code avec ces teams (au moins pour fournir l'expérience suffisante pour refactorer correctement)
- mettre en place des problèmes à injecter, faire les tests correspondant (si pas encore présents) et les injecter dans les deux versions (avant-après refactoring)
- demander à des étudiants de corriger chaque problème pour avoir les tests au vert, à raison de 10 étudiants par version (peut-être que du crowdsourcing serait mieux, avec une assignation aléatoire des bugs à corriger)
- prendre ces mesures :
* objectif : temps mis à résoudre chaque problème (test rouge -> test vert)
* objectif : ordre de résolution (quelle tâche est considérée avant quelle autre)
* subjectif : impression de l'étudiant sur la difficulté de chaque tâche résolue (e.g. avec une échelle de Likert)
- analyser les résultats sur chaque version en prenant en compte l'effet d'apprentissage (un problème peut être plus facile à régler selon que je m'en occupe en premier, alors que je connais rien au code, ou en dernier, alors que j'ai déjà bien parcouru)
- comparer les résultats des deux versions pour établir les conclusions
Site perso
Recommandations pour débattre sainement
Références récurrentes :
The Cambridge Handbook of Expertise and Expert Performance
L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})
Il est en effet très important de refactoriser son code, c'est même nécessaire sur le long terme.
Exemple tout bête : Imaginons un code ayant été écrit avant l'apparition des Design Patterns, si c'est un grand logiciel, il FAUT le refactoriser pour qu'il se soumette aux règles de ces patrons de conception, ou du moins quelques unes de ses parties, car ça ne fera qu'améliorer la lisibilité et la qualité du code, et peut-être, je dis bien peut-être, sa performance, mais cela peut venir comme "effet se secondaire", améliorer la performance n'est pas le but du refactoring.
Les design patterns sont des outils de conception et non des obligations
Le refactoring n'a rien à voir avec le fait de se soumettre ou non aux design patterns
Je dirai même que pour limiter au maximum les effets secondaires (non maîtrisés le plus souvent), la refactorisation doit être la moins impactante possible
L'idée est d'éviter la duplication du code. Et c'est tout.
Bien plus que des outils, ce sont des patrons de conception
Et oui, ce ne fut qu'un exemple, je n'ai jamais dit que c'était une obligation.
Si tu l'as dit :
Et avec emphase en plus. {^_^}
Site perso
Recommandations pour débattre sainement
Références récurrentes :
The Cambridge Handbook of Expertise and Expert Performance
L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})
"Oh ben non alors, quelle idée !La refactorisation est-elle réellement utile ?
- Mais, mais, mais... Mais enfin, quand même ! Si une partie du code est dégueulasse, on peut quand même refactoriser, non ?
- Non, perte de temps, on ne va pas modifier du code qui marche quand même !
- Et le coût de la maintenance ?
- Oh ça ? Qu'est-ce qu'on en a à foutre de ces conneries !
- Parfait ! Tu as réussi le test ! On t'embauche !"
Il n'y a pas que la duplication, on peut aussi refactorer pour rendre le code plus expressif, plus granulaire (Single Responsibility Principle), pour ajouter une couche d'abstraction, pour améliorer les perfs, etc.
Sinon oui, les design patterns ne sont pas une obligation quand on refactore, juste une convention qui peut faciliter les échanges entre développeurs et apporter de la qualité.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager