La refactorisation est-elle réellement utile ?
Selon une récente étude, il n'y a pas assez de preuves empiriques pour justifier son utilisation
Le 2015-03-04 21:40:38, par Amine Horseman, Expert éminent sénior
Dans une récente étude publiée dans l’ « International Journal of Software Engineering & Applications », deux chercheurs sri lankais ont tenté de mesurer l’impact de la refactorisation sur le code.
Selon la définition de Wikipédia, la refactorisation « consiste à retravailler le code source d'un code informatique sans ajouter de fonctionnalités au logiciel ni corriger de bogues, mais en améliorant sa lisibilité pour simplifier sa maintenance, ou le rendre plus générique ». Toutefois, ceci n’est pas forcément garanti selon les deux chercheurs sri lankais. Dans le rapport qu’ils ont publié en janvier dernier, ils déclarent que les preuves empiriques sont limitées pour soutenir l’hypothèse qui dit que le remaniement du code améliore sa qualité, son intelligibilité, sa flexibilité ou sa réutilisabilité.
Dans cette étude, plusieurs techniques de refactoring ont été analysées par deux groupes de 10 étudiants chacun, en se basant sur des mesures internes telles que la cohésion, le couplage des classes, le nombre de lignes de codes, la complexité cyclomatique et l’indice de maintenabilité, ainsi que des mesures externes comme l’intelligibilité, l’analysabilité, le temps d’exécution moyen et l’utilisation des ressources. L’application utilisée dans l’expérience (développée au département de Management Industriel de l’Université de Kelaniya au Sri Lanka) représentait un mini système permettant au staff académique de planifier leurs évènements personnels et professionnels et gérer leurs documents en ligne. Le code du projet, écrit en C#.net, contenait environ 4 900 lignes de codes au départ.
Figure : résultat des mesures internes avant et après le remaniement du code
« Le résultat des mesures externes n'a pas montré d’améliorations dans la qualité de code après la refactorisation », déclarent les chercheurs après l’analyse des résultats. Cependant, dans les mesures internes, seul l'indice de maintenabilité a indiqué une amélioration dans la qualité du code remanié, « les autres mesures internes n'ont indiqué aucun effet positif sur le code ». Au contraire, les résultats des analyses ont montré que ces autres mesures ont présenté un effet négatif, ce qui ramène les chercheurs à conclure que « la maintenabilité du code remaniée est relativement faible par rapport au code non remanié si l'on considère la complexité cyclomatique, le couplage des classes et le nombre de lignes de code ».
Toutefois, il faut noter que l’étude n’a tenu compte que de 10 techniques de refactorisation parmi les 72 cités dans le livre de référence intitulé « Refactoring: Improving the Design of Existing Code » publié en 1999.
Source : Rapport de l’étude publiée
Et vous ?
Êtes-vous d’accord avec la conclusion donnée par les deux chercheurs ?
D’habitude, la refactorisation vous permet-elle de mieux maintenir votre code après ?
Selon la définition de Wikipédia, la refactorisation « consiste à retravailler le code source d'un code informatique sans ajouter de fonctionnalités au logiciel ni corriger de bogues, mais en améliorant sa lisibilité pour simplifier sa maintenance, ou le rendre plus générique ». Toutefois, ceci n’est pas forcément garanti selon les deux chercheurs sri lankais. Dans le rapport qu’ils ont publié en janvier dernier, ils déclarent que les preuves empiriques sont limitées pour soutenir l’hypothèse qui dit que le remaniement du code améliore sa qualité, son intelligibilité, sa flexibilité ou sa réutilisabilité.
Dans cette étude, plusieurs techniques de refactoring ont été analysées par deux groupes de 10 étudiants chacun, en se basant sur des mesures internes telles que la cohésion, le couplage des classes, le nombre de lignes de codes, la complexité cyclomatique et l’indice de maintenabilité, ainsi que des mesures externes comme l’intelligibilité, l’analysabilité, le temps d’exécution moyen et l’utilisation des ressources. L’application utilisée dans l’expérience (développée au département de Management Industriel de l’Université de Kelaniya au Sri Lanka) représentait un mini système permettant au staff académique de planifier leurs évènements personnels et professionnels et gérer leurs documents en ligne. Le code du projet, écrit en C#.net, contenait environ 4 900 lignes de codes au départ.
Figure : résultat des mesures internes avant et après le remaniement du code
« Le résultat des mesures externes n'a pas montré d’améliorations dans la qualité de code après la refactorisation », déclarent les chercheurs après l’analyse des résultats. Cependant, dans les mesures internes, seul l'indice de maintenabilité a indiqué une amélioration dans la qualité du code remanié, « les autres mesures internes n'ont indiqué aucun effet positif sur le code ». Au contraire, les résultats des analyses ont montré que ces autres mesures ont présenté un effet négatif, ce qui ramène les chercheurs à conclure que « la maintenabilité du code remaniée est relativement faible par rapport au code non remanié si l'on considère la complexité cyclomatique, le couplage des classes et le nombre de lignes de code ».
Toutefois, il faut noter que l’étude n’a tenu compte que de 10 techniques de refactorisation parmi les 72 cités dans le livre de référence intitulé « Refactoring: Improving the Design of Existing Code » publié en 1999.
Source : Rapport de l’étude publiée
Et vous ?
-
el_slapperExpert éminent séniorSur un code de 5000 lignes environ, c'est peu significatif. Et, en plus, ça dépend du talent du refactoreur. Si il est moins bon que les programmeurs initiaux, le résultat final va être pourri.
De toutes manières, ce qui coute cher, c'est la maintenance. Donc l'amélioration de la maintenabilité est quand même l'objectif, et il semble atteint. Mais la vrais question des de savoir si le code initial méritait réellement un refactoring. Si il a 2-3 erreurs de conception pas trop graves, franchement, refactoriser, c'est de la masturbation intellectuelle. Si, par contre, c'est une suite sans fin de :
Code : 1
2
3
4
5
6
7
8A12. MOVE 1 TO II. A113. IF ZZ(II) > 0 ADD ZZ(II) TO GG ADD 1 TO A113 GO TO A113. A11. MOVE GG TO YY.
Dans le même langage, un exemple de refactorisation à peu près propre (même si il y a toujours moyen d'améliorer la sauce)
Code : 1
2
3
4
5
6A-CUMUL-TAXES. PERFORM VARYING COMPTEUR FROM 1 BY 1 UNTIL TAXE(COMPTEUR) <= 0 ADD TAXE(COMPTEUR) TO CUMUL-TOTAL END-PERFORM MOVE CUMUL-TOTAL TO VARIABLE-AFFICHAGE .
Sur la structure, c'est toujours plus difficile à estimer. Ajouter de la maintenabilité, ça veut parfois dire encapsuler des choses(objets, fonctions, peu importe), ce qui augmente la complexité, et parfois réduit les performances. Mais si c'est ça le message de l'étude, ben, merci de l'enfonçage de portes ouvertes.le 05/03/2015 à 10:23 -
gangsoleilModérateurLe refactoring du code par des étudiants, c'est un peu étrange, parce qu'ils n'ont justement pas le recul nécessaire pour savoir s'il est intéressant de refactorer ou non, ni quelle partie du code, ni pourquoi...
Oui, un jeune est souvent plus volontaire pour refactorer, et est moteur pour le faire. MAIS la plupart du temps ça ne se passe pas aussi bien que prévu par manque d'expérience, par l'utilisation de nouveaux outils ou de nouvelles versions pas encore stables, et qui amènent donc des régressions.
Et puis 4 900 lignes à refactorer... Je pense que ça serait plus parlant sur un code plus gros.le 05/03/2015 à 10:28 -
SylvainPVRédacteur/ModérateurAprès une récente étude sur mon velouté de courgettes ce midi, je pose la question: la fourchette est-elle réellement utile ?
Stop aux pseudo-études qui voudraient apporter des réponses absolues à des questions qui sont à régler au cas par cas.le 05/03/2015 à 15:13 -
dfiad77proMembre expérimentéJe suis d'avis qu'il faut impérativement réfactorer lorsqu'on a le temps et lorsque cela semble nécessaire.
En effet souvent les entreprises ne veulent prendre aucun risque et perdent de l'agent dans la maintenance d'un code qui à mal évolué.
Il y'a pas longtemps sur un audit de code, on est passé de 110 000 lignes de code sur un projet à 85 000 tout en baissant drastiquement la complexité.
Cela dit, pour refactorer il est intéressant de :
- connaitre le projet utilisé et surtout le contexte métier pour le rendre parlant
- connaitre le langage utilisé
- documenter
- ne pas vouloir compacter le code à tout prix
- on peut optimiser celons le type de projet
- il peut être intéressant de travailler un refactoring en binôme
Les tests unitaires automatiques de non régression sont très importants afin d'éviter au maximum les effets de bords d'un reffactoring
bref pour moi le reffactoring est nécessaire pour garder une qualité de code tout au long du cycle de vie d'un projet ( ce qui manque cruellement dans nombre de projets).
On limite ainsi l'errosion applicative au fils des années et des devs.le 05/03/2015 à 11:00 -
el_slapperExpert éminent séniorA mon sens, c'est secondaire. J'ai pris +7 sur mon exemple en COBOL, et je suis sur qu'il n'y avait aucun coboliste parmi les votants. Ce n'est pas la connaissance technique spécifique qui fait un code propre (à 2 ou trois exceptions près, quand une astuce technique permet d'éviter un code emmerdant, genre split, ucase.....).
Un personnel qui code proprement en Java, franchement, la probabilité qu'il fasse du code illisible en .NET(dont la philosophie est proche, sans être identique) est quasi-nulle. Non, l'expérience importante, c'est celle de la maintenance de gros projets. Quiconque a eu à maintenir un blob de millions de lignes de codes est beaucoup plus à même de faire du refactoring qu'un étudiant qui applique des méthodes certes louables, mais pas forcément adaptées. 20 étudiants à l'expertise non identifiée, ça ne fait pas une population test représentative.
Pour le nombre de lignes, oui, ça dépend. Le code crade que j'ai pris en exemple, j'en avait 1100 lignes au début d'un programme de 4000(la suite était presque civilisée...), plus 2000 lignes dans un autre programme. Le refactoring a fortement réduit les couts de maintenance(ça a été mesuré sur 5 ans après mon départ). Mais ça valait le coup parce que c'était absolument crade. Si ça avait été acceptable(genre les 2900 lignes du premier programme qui étaient bof-bof mais lisibles quand même), eh bien ça aurait été un risque inutile, et un investissement peu avisé.
Ne connaissant pas leur appli, il est difficile de savoir si c'était justifié. L'exercice est toujours intéressant à faire, mais il faut rester très prudent sur ses conclusions. Ce qui est vrai sur leur appli et avec leurs refactoriseurs peut être totalement différent sur d'autres applis ou avec d'autres refactoriseurs. et avec d'autres principes d'application. Quand on survole leur papier, on voit qu'ils sont obsédés par l'idée de faire des choses contrôlées. En particulier, ils parlent de "process" de refactoring, en bref, ils partent du principe que les gens suivent le petit manuel. Toujours. Et que ça en fait des professionnels compétents. Il se trouve que le talent permet souvent de faire mieux que la méthode standard, et ça, ils l'ont quasiment interdit à leurs étudiants-test. Donc on a plus une étude sur l'efficacité des principes de Martin Fowler quand ils sont appliqués bestialement, et la conclusion est mitigée. Pas très surprenant.
Je note aussi la guerre des +- sur la remarque concernant l'orienté objet. C'est rigolo de voir à quel point les gens ont des opinions à la limite du religieux sur un sujet de ce genre. "Est-ce que l'objet est mieux que le procédural". Alors que, comme presque toujours, la seule réponse valide est "ça dépend". Et que l'ingénieur digne de ce nom analysera chaque cas sans a priori.le 05/03/2015 à 15:37 -
Bono_BXMembre confirméil n'y a pas assez de preuves empiriques pour justifier son utilisationpar deux groupes de 10 étudiants chacunse basant sur des mesures internes telles que la cohésion, le couplage des classes, le nombre de lignes de codes, la complexité cyclomatique et l’indice de maintenabilité, ainsi que des mesures externes comme l’intelligibilité, l’analysabilité, le temps d’exécution moyen et l’utilisation des ressources.Toutefois, il faut noter que l’étude n’a tenu compte que de 10 techniques de refactorisation parmi les 72 cités dans le livre de référence intitulé « Refactoring: Improving the Design of Existing Code » publié en 1999.le 05/03/2015 à 11:27
-
CodeurPlusPlusEn attente de confirmation mailA quand une étude prouvant que le code "orienté objet" n'est pas plus réutilisable / maintenable / élégant que le code procédural ?le 04/03/2015 à 22:54
-
dfiad77proMembre expérimenté
Pour moi la réponse serait : non la fourchette n'est pas utile car le velouté va partir dans l'évier, c'est infect !le 05/03/2015 à 15:28 -
Je dis peut être une bêtise, mais si le refactoring est censé améliorer la maintenabilité du code, est-ce que justement un des objectifs n'est pas de découpler les classes quand c'est possible? Je trouve étrange que cette stat augmente.
Après on ne sait pas si des classes ont été créées durant le refactoring, si oui c'est complètement idiot de compter en valeur absolue pour au final annoncer "-7%".le 05/03/2015 à 11:51 -
dfiad77proMembre expérimenté#MODE SARCASME
Oui pas grave, le fric on va le perdre en maintenance
En plus le travail en binôme permet souvent de faire monter en compétence, mais ça ça les intéresses pas, le dev risque de demander une augmentationle 05/03/2015 à 11:21