Refactoring

Compétence

De quoi s'agit-il?

Refactorer consiste à modifier un code source de façon à en améliorer la structure, sans que cela modifie son comportement fonctionnel.

On l'appelle également...

L'anglicisme est le plus souvent employé: l'activité est le refactoring, on utiliser également le verbe refactorer. Par le substantif, un refactoring, on désigne une modification générique qu'il est possible d'appliquer à un code pour le transformer.

On peut également traduire par remanier, remaniement. Le terme de refactorisation est également rencontré, mais nettement moins courant.

Erreurs courantes

Attention, refactorer n'est pas:

  • réécrire du code

  • corriger des bugs

  • améliorer un aspect extérieurement visible du logiciel, comme l'IHM

Origines

  • Connue sous le nom de "factoring" chez les programmeurs Forth depuis 1984

  • Formellement décrite par Bill Opdyke en 1992

  • Intégrée par Kent Beck dans Extreme Programming en 1997

  • Popularisée par Martin Fowler en 1999

Comment s'améliorer?

Niveaux de performance individuels:

  • Débutant

    • je connais la définition

    • j'utilise quelques refactorings de mon environnement de développement

    • j'utilise quelques refactorings que je sais appliquer manuellement

    • je connais les risques de régression associés au refactorings manuels et automatiques

    • je reconnais la duplication et sais l'éliminer par refactoring

  • Intermédiaire

    • je reconnais et j'élimine une gamme plus étendue de "mauvaises odeurs" dans le code

    • je peux enchaîner plusieurs refactorings pour mener à bien une intention de conception, en maîtrisant leurs dépendances (méthode dite "Mikado")

    • j'applique le refactoring en continu, en ayant rarement besoin d'une longue session de refactoring

  • Avancé

    • j'ai un sens aigu de la duplication et des différentes formes de couplage

    • je maîtrise des refactorings concernant d'autres éléments que le code: schémas de bases de données, de documents...

    • je suis en mesure de faire évoluer mon code vers des structures de mon choix issues de différentes origines: paradigme objet, paradigme fonctionnel, "patterns" connus

Comment reconnaitre son utilisation?

  • les historiques de la gestion de versions (logs CVS ou git par exemple) contiennent des entrées libellées "Refactoring"

  • les modifications correspondantes sont réellement isofonctionnelles (pas d'effet sur les tests unitaires, pas de code ajouté)

Quels bénéfices en attendre?

  • les aspects objectifs de la qualité du code (longueur, duplication, couplage, cohésion, complexité cyclomatique) s'améliorent au fil du temps

  • en lien avec la [propriété collective], la connaissance des décisions de conception est mieux partagée dans l'équipe

  • des schémas de conception, ou des modules génériques, émergent et peuvent être réutilisés par la suite

Où se renseigner pour en savoir plus? (livres, articles)

Publications académiques et travaux de recherche

Les travaux empiriques concernant la pratique du remaniement sont équivoques, et peinent à mettre en évidence les bénéfices prétendus par les équipes de développement, qui y voient pourtant une pratique indispensable. C'est un sujet de recherche prioritaire compte tenu de l'importance accordée à cette pratique au sein des mouvements Agile, Extreme Programming et Software Craftsmanship.