Refactoring: N'est-ce pas juste un mot de fantaisie pour nettoyer votre code? [fermé]


21

Avant la publication du livre de Martin Fowler "Refactoring: Improving the Design of Existing Code", nous appelions les changements majeurs du code "rearchitecture" et les changements mineurs "cleanup". OMI, les techniques de refactoring sont toutes des choses évidentes de bon sens que nous faisons depuis toujours.

Pensez-vous que le refactoring ait jamais été nouveau? Peut-être juste un moyen d'inciter la direction à allouer du temps pour le nettoyage du code?


Lorsque vous dites "avant la sortie du livre", je suppose que vous faites référence au livre de Martin Folwer, est-ce exact?
AlexC

-1: Quelle est l'utilité de cette question?
Jim G.

Oui, le livre de Fowler.
Chuck Stephanski

Réponses:


43

La refactorisation est plus ancienne que les collines, donc non, ce n'est pas nouveau.

Et le refactoring ne nettoie pas. Eh bien, c'est possible, mais cela ne se limite pas au nettoyage.

Il s'agit d'ajuster l'architecture de votre application (à grande ou à petite échelle) tout en préservant le comportement.

Cela signifie que bien qu'une partie de votre application ait pu être parfaitement propre et correcte hier, la nouvelle fonctionnalité d'aujourd'hui nécessite d'ajuster cette partie pour s'adapter à la nouvelle fonctionnalité.

Vous ne voulez pas casser les fonctionnalités existantes, vous ajustez donc la structure de votre application tout en préservant le comportement - qui est le refactoring.

Cela dit, peu importe les modifications apportées au code, il faut toujours exécuter ses tests ... juste au cas où.


1
Newtopian: c'est un point essentiel. Si vous n'avez pas exécuté vos tests, vous ne savez pas si vous avez piraté quelque chose au hasard ou refactorisé . (Et bien sûr, vous avez besoin d'une suite de tests adéquate!)
Frank Shearar

9

C'est juste ranger le code. Essentiellement, les programmeurs (en particulier Martin Fowler) ont remarqué qu'ils avaient tendance à effectuer les mêmes tâches chaque fois qu'ils nettoyaient leur code. Ils ont défini et étiqueté les méthodes de rangement et les problèmes de code associés et hop! Le refactoring est né.

C'est la même chose avec les modèles de conception - les gens ont remarqué qu'ils avaient tendance à utiliser les mêmes approches pour des problèmes particuliers encore et encore. Ils ont étiqueté et défini les approches et maintenant il semble que vous n'êtes pas un vrai programmeur à moins que vous n'utilisiez jamais la même douzaine de modèles dans votre code.

Il n'y a pas de magie à refactoriser; c'est juste un nouvel ensemble de jargon pour décrire une ancienne pratique.


William Opdyke, 1992: Refactoring des cadres orientés objet . Fowler & Beck & friends ont popularisé le refactoring. Jon Brant et Don Roberts ont implémenté le premier outil automatisé quelque temps avant 1999. Le "nouvel ensemble de jargon" n'est donc pas très précis.
Frank Shearar

Si vous acceptez que la programmation informatique existe depuis Ada Lovelace au milieu des années 1800, alors oui - il s'agit d'un ensemble de jargon relativement nouveau.
Ant

1
Je pense que la différence est qu'avec Design Patterns, presque tous les développeurs ont appris de nouveaux modèles et donc de nouveaux outils du métier à partir du livre. Avec Refactoring, je n'ai pas l'impression que quelqu'un ait vraiment appris quoi que ce soit. Il y a une valeur secondaire à simplement attribuer un nom à quelque chose (et la comparaison des modèles de conception tient le coup), mais il aurait pu le faire avec un article de blog.
Chuck Stephanski

En effet, j'ai mentionné qu'il s'agissait d'un nouveau jargon ... par rapport au calcul lambda.
Frank Shearar

@Chuck, avez-vous lu le livre, Refactoring? Si c'est le cas, je serais très surpris si vous n'en tiriez pas de nouvelles.
Marcie

7

Nous faisons trois choses distinctes dans notre entreprise, avec du temps alloué pour les trois:

  • Refactoring: consiste à changer la structure du code, gardant ainsi le comportement.

Exemple: fractionner une méthode de 100 lignes laide et illisible qui fait quatre choses en quatre méthodes réutilisables, 25 lignes chacune.

  • Nettoyage: consiste à effectuer des modifications mineures pour rendre le code plus lisible sans modifier ni son comportement, ni sa structure.

Exemple: suppression du code commenté après s'être assuré que ce code n'est plus nécessaire.

  • Application des règles StyleCop / FxCop: consiste à vérifier si le code correspond à l'ensemble par défaut des règles StyleCop ou FxCop, et sinon, le modifier pour correspondre à ces règles.

Exemple: l' addition Culture.Invariantdans string.Format(ou une autre culture qui est plus approprié).

Donc dans mon cas, le refactoring est quelque chose de très différent du nettoyage . Quand vous faites le nettoyage, je n'ai pas à exécuter des tests unitaires à nouveau: si le code a fonctionné avant, il va travailler après le nettoyage. En d'autres termes, ce n'est pas parce que j'ai supprimé une ligne vide ou ajouté un commentaire que le code cessera de fonctionner. En revanche, lorsque je refactorise des parties compliquées d'un ancien code, je peux faire des erreurs, je dois donc exécuter des tests unitaires après refactoring.


4
Bien que je convienne qu'il existe une différence fondamentale entre le nettoyage et la refacturation, il existe de nombreux cas où cette ligne s'estompe un peu. Supprimer une classe morte et "nettoyer" toutes les références à celle-ci des signatures de méthode ou des associations restantes serait considéré comme un nettoyage ou une refactorisation? Je suis également fortement en désaccord avec le fait que l'exécution de tests unitaires est facultative. Vous ne savez pas comment les choses pourraient se briser. J'ai vu des changements dans la chaîne de message d'un code de rupture d'exception parce que quelqu'un a pensé que c'était une bonne idée de l'analyser pour agir sur certaines erreurs.
Newtopian

Je suis d'accord avec Newtopian, en particulier sur le fait de ne pas avoir à relancer les tests. En fait, il devrait y avoir une suite de tests automatisée qui s'exécute pas moins d'une fois par commit. Qu'il s'agisse de nettoyage ou de refactoring , si vous avez un changement de code à valider pour le contrôle de version, les tests doivent s'exécuter.
kojiro

Vous devez toujours faire une compilation complète après avoir effectué un nettoyage, même si ce n'est que des changements d'espace blanc et de commentaires. Demandez à n'importe quel auteur Python ou Makefile à ce sujet.
JBRWilkinson

3

La refactorisation ajoute des connaissances à votre code. Si vous savez que quelque chose est mal nommé, vous lui donnez un meilleur nom. Si vous savez que quelque chose peut être mieux fait, vous le changez en quelque chose de mieux.

Ce sont de nombreuses étapes - petites et grandes - qui, nous l'espérons, aboutiront à un meilleur programme.


3

Je suis d'accord avec "refactoring est un mot de fantaisie pour nettoyer votre code" mais pas avec "juste". Les gens utilisent des mots fantaisistes pour une raison: parfois parce qu'ils veulent avoir l'air intelligent, et parfois parce qu'ils transmettent un sens plus ou moins précis, et le refactoring à mon humble avis (même s'il est parfois mal utilisé) fait généralement référence à ce dernier.

"Nettoyer" pourrait signifier n'importe quoi de "reformater un peu" à "réécrire de gros morceaux".

"Refactoring" signifie spécifiquement quelque chose comme "de petites modifications incrémentielles du code, conçues pour maintenir la même fonctionnalité, tout en le transformant en une meilleure conception". Et il existe un ensemble de meilleures pratiques sur le genre de choses que vous faites: certaines sont ad hoc, mais il existe des principes généraux, comme l'utilisation de tests unitaires, l'extraction d'une partie des fonctions dans de nouvelles fonctions ou classes, etc., que les gens peuvent et doivent apprendre .

Vous dites "il suffit de tromper la gestion pour allouer du temps au nettoyage du code". Mais si dire «refactoring» transmet correctement le concept qu'un investissement constant dans la clarté maintenant rapportera des dividendes en efficacité à l'avenir, alors ce n'est pas un «truc», c'est une communication claire et efficace.


2

Le refactoring consiste à coder comme la normalisation aux données relationnelles. C'est un processus d'abstraction des concepts en représentations plus propres, plus claires et plus efficaces de leur rôle dans l'application.


1
C'est une façon intéressante de voir les choses. Peut-être que cela vient de mon arrière-plan de base de données, mais il y a quelque chose qui me contrarie par le stress de la refactorisation, et vous m'avez aidé à mettre le doigt dessus. C'est que dans une base de données, ce que vous ne corrigez pas dans la conception prend 10 fois plus de temps à corriger dans les tests et probablement 1000 fois plus dans la production. Donc, un bon DBA est anal pour réussir les choses le plus tôt possible. Mon intuition est que trop de temps pour refactoriser les étapes ultérieures indique trop peu de temps passé à concevoir.
user21007

@ user21007: Le code est beaucoup plus compliqué qu'un schéma de base de données, mais beaucoup plus facile à modifier et à déployer.
Kevin Cline

1

Cela dépend de la façon dont vous comprenez la refactorisation des termes. Pour la plupart des gens, il s'agit d'un processus d'amélioration de la structure sans changement de comportement. Si vous êtes d'accord, alors oui, cela a été fait bien avant la sortie de ce livre. Je sais, parce que je (entre autres choses) renommais des classes, en extrayant des classes et en extrayant des méthodes avant que le livre ne soit écrit. Je n'appelais pas ça refactoring, mais en gros je faisais exactement la même chose.

Pour moi, le refactoring personnel est ce que les gens appellent maintenant "refactoring de code automatisé", c'est-à-dire: le support de diverses techniques de refactoring dans un IDE. C'est une réelle amélioration par rapport à ce que je faisais auparavant (ce qui était vraiment très douloureux). Je peux effectuer un changement dans une classe et ne pas m'inquiéter de la façon dont cela va affecter le reste du logiciel. Je pense que Martin a officialisé la technique de refactoring au point où il pourrait être représenté comme un algorithme et donc implémenté dans divers IDE.

Donc, si vous comprenez le refactoring comme un processus, ce n'est pas nouveau. Si vous le voyez comme une automatisation, alors oui, c'est une énorme amélioration. Essayez de renommer quelques classes de base (littéralement, pas en refactorisant les options de votre IDE) dans un projet assez important pour voir pourquoi :)


0

Le refactoring est en effet du "nettoyage" de code, mais aussi une restructuration du code. Dans mon équipe, le refactoring est généralement le dernier. Lorsque nous avons un cas «refactor», nous allouons du temps pour restructurer notre code, par exemple pour l'aligner sur une nouvelle architecture ou un nouveau modèle d'information, ou pour le rendre plus efficace.

Le "nettoyage" du code est quelque chose que nous faisons continuellement sans temps spécialement alloué pour cela. Pour moi, le "nettoyage" consiste généralement à renommer, nettoyer les commentaires, etc.


1
renommer est une technique de refactoring standard!
Chuck Stephanski

0

Je dirais non.

Il peut y avoir un nettoyage dans le processus de refactorisation, mais ce n'est pas l'essentiel.

Le nettoyage vient avec l'hypothèse que le code précédent n'est pas propre. En réalité, les développeurs refactorisent leur code même si le code d'origine est déjà propre.

DRY est un moteur clé du refactoring.

Lors de l'ajout de nouveaux codes à une base de code existante, le refactoring se fait naturellement en raison du principe DRY.

Juste mon 0,02


0

Nettoyer votre code, c'est comme ranger votre maison, refactoriser, c'est comme abattre un mur et éventuellement le placer ailleurs


0

Quand quelqu'un d'autre nettoie votre maison, vous ne trouvez rien parce que le but est de nettoyer et d'éliminer les choses. Le refactoring permettrait de construire et d'étiqueter des pièces, des placards, des armoires, des étagères, des bacs, etc. Il contient toujours la plupart des mêmes choses (vous pouvez toujours faire un sandwich au fromage grillé dans la cuisine et le manger dans le salon), mais devrait le faire plus faciles à trouver et possiblement des endroits efficaces pour mettre de nouvelles choses.


Je ne suis pas un fanatique des mots à la mode, mais parfois les tâches courantes doivent être étiquetées et formalisées pour que tout le monde sache de quoi vous parlez. Un client signale un bug et le gestionnaire crie: "Allez nettoyer votre code!" vous savez qu'ils ne parlent pas de refactoring.
JeffO

0

Le terme «refactoring» est élégamment emprunté à l'algèbre. Cela signifie simplifier les termes pour produire le même résultat. Non seulement élégant, il était révolutionnaire - il nécessitait une approche finie et dure de votre code, à un niveau qui en a surpris beaucoup. Et donc le terme lui-même était significatif et utile.


-1

Non. Le refactoring améliore la structure sans changer les comportements. La refactorisation au sens strict implique une bonne discipline de test. Ce n'est pas nécessairement nécessaire lorsque vous "nettoyez les choses".


2
attitude dangereuse. Supprimer une bande entière de code mort et de configuration morte, c'est nettoyer et changer la signature d'une méthode unique, un refactor. Pourtant, dans les deux cas, je voudrais obtenir une bonne discipline de test pour m'assurer que je n'ai rien cassé.
Newtopian

Je ne dis pas qu'il est bon / sûr / souhaitable d'apporter des changements majeurs sans discipline de test. Je dis que le refactoring en tant que méthodologie implique une discipline de test, alors que "nettoyer les choses" n'est pas du tout une méthodologie.
Willie Wheeler

Donc, si je comprends bien, s'il n'a pas un nom de fantaisie approprié, nous sommes prêts à partir !! : -O je plaisante, je vois ce que vous essayez de dire, vrai que le nettoyage des choses pourrait difficilement être qualifié de méthodologie mais là encore, ni le refactoring. C'est juste un mot de fantaisie qui indique que vous modifiez le code sans altérer son comportement. Il n'a, en soi, aucune implication sur les tests. Suivre les bonnes pratiques de codage indiquera que si le code a changé, il doit être testé quelle que soit la façon dont vous appelez l'action qui a généré le changement.
Newtopian

1
Bien sûr, je peux l'acheter. La discipline de test concerne davantage la façon dont on procède à la refactorisation, mais elle n'est pas inhérente à la définition. (C'est-à-dire que je peux refactoriser du code sans aucun test.) Je ne sais pas si je peux convenir que la refactorisation n'est pas une méthodologie - il existe des livres entiers écrits avec des modèles pas à pas, etc.
Willie Wheeler

-1

Les deux se chevauchent un peu sur les bords, mais pour moi, c'est la différence entre nettoyer la maison et rénover la maison. Le nettoyage, pour moi, n'implique pas de changements structurels, contrairement au refactoring.


-2

"Refactoring" est vraiment la même chose que "rearchitecture", mais avec une connotation plus forte de "aucun changement de fonctionnalité". C'est aussi plus clair en termes d'objectif de ré-architecture, qui est souvent de «factoriser» le code commun en morceaux réutilisables.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.