Discussion :

[Amine Horseman]

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

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 ?

[CodeurPlusPlus]

A quand une étude prouvant que le code "orienté objet" n'est pas plus réutilisable / maintenable / élégant que le code procédural ?

[el_slapper]

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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.

[gangsoleil]

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.

[dfiad77pro]

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.

[Juda-Priest]

- ne pas vouloir compacter le code à tout prix
- il peut être intéressant de travailler un refactoring en binôme

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...

[dfiad77pro]

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

[Bono_BX]

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.

[Invité]

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%".

[Colmea]

Sérieusement, une étude sur 20 étudiants, 4900 lignes et un seul programme testé...

se basant sur des mesures internes telles [...] le nombre de lignes de codes, [...], le temps d’exécution moyen et l’utilisation des ressources.

Je ne pense pas que c'est avec ce genre de mesures qu'on peut déduire de la bonne qualité/maintenabilité d'un code. Dans mon cas, ça peut même être l'inverse en ce qui concerne le nombre de lignes de codes.

Bref, je suis désolé d'être aussi direct, mais "bullshit" sur ce coup là...

(mais j'vous aime bien developpez.com, hein )

[myNameIsFlo]

Je me demande quelle est la connaissance d'étudiant sur le framework .NET. . . .

[yahiko]

Déjà, comme cela a déjà été dit, l'échelle de l'expérience n'est pas significative.

• Un code source de 4500 lignes n'est clairement pas suffisant pour juger d'un refactoring.
• Deux groupe de 10 étudiants chacun venant d'un pays qui n'est pas renommé pour son industrie IT.

De plus, au niveau de la méthodologie, l'étude a sélectionné 10 des techniques de refactoring de Martin Fowler qui datent des années 2000 (c'est-à-dire l'âge d'or de l'intégrisme POO).
Et c'est surtout là que le bât blesse à mon avis.
Certaines des 10 techniques considérées sont manifestement critiquables du point de vue des métriques analysées notamment le couplage.

R1- Introduce Local Extension
R2- Duplicate Observed Data
R3- Replace Type Code with Subclasses
R4- Replace Type Code with State/Strategy
R5- Replace Conditional with Polymorphism
R6- Introduce Null Object
R7- Extract Subclass
R8- Extract Interface
R9- Form Template Method
R10- Push Down Method

R1, R3, R5 et R7 sont des techniques qui augmentent de fait le couplage.
Par exemple, R1 préconise de créer des sous-classes clientes pour étendre le comportement de classes serveurs. Cela peut être le cas lorsqu'on utilise un framework externe. Or la tendance actuelle montre qu'il est souvent préférable de limiter l'héritage et de plutôt privilégier la composition pour justement éviter le couplage parent serveur / enfant client causé par l'héritage.
R3 et R7 sont du même acabit. Quant à R5, en plus d'introduire des classes, de l'héritage et donc du couplage là où on pourrait s'en passer, l'emploi immodéré du polymorphisme (R5) peut conduire à du code incompréhensible.

C'est donc une étude qui a selon moi une bonne décennie de retard.

[Zefling]

Et puis 4 900 lignes à refactorer... Je pense que ça serait plus parlant sur un code plus gros.

Pas forcement, une fois j'avais fait une refacto d'un code de 2500, qui est passé à environ 1000 lignes. Ça pris du temps, mais nécessaire car le code était devenu illisible. Généralement quand il y a refacto dans les boîtes où j'étais, c'est qu'on arrive à un point où ça devient une nécessité. Pour moi, je le fais quand je vois qu'il y a des choses qui ont tendance à se répéter (enfin, reproduire un schéma qui se ressemble). Il est sur que plus le code est gros, plus il peut y avoir de redondances ou de choses qui pourraient être plus claires.

[SylvainPV]

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.

[Kropernic]

Après une récente étude sur mon velouté de courgettes ce midi, je pose la question: la fourchette est-elle réellement utile ?

La réponse est évidente ! Uniquement si on n'a pas de paille assez grosse à disposition.

[dfiad77pro]

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 !

[el_slapper]

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.

[Zefling]

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.

Tu peux ajouter à ça la programmation fonctionnelle. Maintenant ça ne se limite plus à procédural/objet. Surtout que les langages ont de plus en plus tendance à perdre toutes les approches ce qui permet de mieux s'adapter en fonction de la situation.

[deltree]

Se poser la question est intéressant, mais affirmer tout de go que ça ne sert jamais à rien, je trouve ça un peu trollesque.

J'ai vécu des cas ou ça ne servait à rien, d'autre ou c'était indispensable, encore faut-il savoir ou on situe la limite entre nettoyage, refactor et refonte?

[yann2]

Si hier c'était vendredi, aujourd'hui on est samedi ?


Plus sérieusement, je pense que vous devriez arrêter de lire le web monsieur le chroniqueur d'actualités... au moins vous avez trouver la formule miracle pour attirer le clic mais, personnellement, je vais finir par arrêter de venir sur developpez.com si ce genre de vulgarités continuent de sortir !

Ah quand les articles sous formes de tops ? (le 8ème point a sauvé mon projet)