Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Amine Horseman

0PARTAGES

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 05/03/2015 à 10:23
Sur 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 : Sélectionner tout
1
2
3
4
5
6
7
8
A12.
    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.
alors là, une refactorisation est indispensable. (PS : le vrai code était pire que ça, mais je tiens à votre santé mentale, alors j'ai édulcoré; et non, il n'y a pas de boucle infinie, en cobol, le point sert aussi de end-if, pour les obfuscateurs professionels). La complexité Cyclomatique, en comparaison, je m'en fous.

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 : Sélectionner tout
1
2
3
4
5
6
A-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
    .
Je ne sais pas si j'ai augmenté la complexité cyclomatique ou si je l'ai réduite, et je m'en fous. Je n'ai évidemment pas touché au couplage de classes ou à la profondeur d'héritages(je suis resté dans mon paragraphe, et de toutes façons le cobol est rarement objet). Mais je suis sur que le gars(en fait, c'était une fille) qui est passé(e) après a eu moins de mal que moi à interpréter ce paragraphe. En plus, ça permet de faire sauter aux yeux les fragilités du codage(le cumul est-il bien initialisé au départ? le cumul a-t-il le bon format pour l'affichage? Que se passe-t-il si la dernière occurrence du tableau n'est pas à zéro?).

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.
12  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 05/03/2015 à 10:28
Le 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.
11  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 05/03/2015 à 15:13
Aprè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.
10  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 05/03/2015 à 11:00
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.
9  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 05/03/2015 à 15:37
Citation Envoyé par myNameIsFlo Voir le message
Je me demande quelle est la connaissance d'étudiant sur le framework .NET. . . .
A 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.
9  0 
Avatar de Bono_BX
Membre confirmé https://www.developpez.com
Le 05/03/2015 à 11:27
il n'y a pas assez de preuves empiriques pour justifier son utilisation
La bêtise, par contre a subie assez de tests, empiriques ou non, pour justifier son éradication. Commençons par les idiots qui ont pondu cette étude.

par deux groupes de 10 étudiants chacun
Un refactoring efficace nécessite un minimum d'expérience, donc ne prendre que des étudiants est une erreur (note : je ne dis pas que les étudiants sortant de l'école ne savent pas faire du code correct).

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.
Les métriques indiquées sont purement consultatives, et ne sont pas un gage absolu de qualité / non-qualité du 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.
Voilà tout le problème : on applique bêtement ce qui est écrit dans un livre, sans savoir prendre du recul. Etude finalement inutile et à jeter.
7  0 
Avatar de CodeurPlusPlus
En attente de confirmation mail https://www.developpez.com
Le 04/03/2015 à 22:54
A quand une étude prouvant que le code "orienté objet" n'est pas plus réutilisable / maintenable / élégant que le code procédural ?
11  5 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 05/03/2015 à 15:28
Citation Envoyé par SylvainPV Voir le message
Après une récente étude sur mon velouté de courgettes ce midi, je pose la question: la fourchette est-elle réellement utile ?

Pour moi la réponse serait : non la fourchette n'est pas utile car le velouté va partir dans l'évier, c'est infect !
6  0 
Avatar de Mrsky
Membre éprouvé https://www.developpez.com
Le 05/03/2015 à 11:51
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%".
5  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 05/03/2015 à 11:21
Citation Envoyé par Juda-Priest Voir le message
Tutafé ! Je suis bien d'accords avec ton post, mais je tiens à souligner les 2 remarques que j'ai cité.

Refactoring ne veut pas forcément dire compactage, et surtout le refactoring en binôme (ou moins avoir une personne qui intervient de temps en temps) permet de garder le cap, de confronter des idées, et de discuter sur les implémentations possibles.
Mais bon pour le boss, 2 ressources sur la même tâche on perds du fric et on va être obligé de fermer la boîte le mois suivant...
#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 augmentation
5  1