Un contact Twitter à publié un lien vers un bon article sur le refactoring qui permet aux débutants de bien saisir le concept et pour les connaisseurs, de rapidement se remettre en tête les fondements de base de la technique. L’article So You Think You’re « Refactoring »? est fait avec une simple dose d’humour et 2 excellents exemples.

Le joueur de billard

Refactoring is a very strict, disciplined approach to restructuring code. When you watch someone doing real refactoring, it should look like a professional pool player carefully, thoughtfully, accurately working their way through all the balls on the table. Every shot has a clear goal. They can name exactly which balls should go into which pockets after each shot, and they have a plan for getting the cue ball where it needs to be for the next shot.

Le joueur d’échecs

Another analogy for refactoring is chess, in that both disciplines have well-defined moves. Sure, there are wider stategies you can learn, but these must be executed as a sequence of these primative moves. Larger strategic and wholesale refactorings – the stuff that can fundamentally change an architecture – must still be executed through a sequence of lower-level refactorings, [...]

Donc, faire du refactoring c’est planifier et exécuter ses coups dans un ordre particulier pour atteindre un but précis. Également, l’auteur rappelle un autre point crucial pour faciliter le travail et s’assurer qu’il n’a pas affecter d’autres fonctionnalités en introduisant des bugs! Rouler les tests fréquemment (et ajuster si nécessaire lorsque certains tests sont des échecs).

And your code must still work correctly after each of these « moves », evidenced by running the tests.

Personnellement, en plus des règles ci-dessus, je crois qu’il faut aussi éviter de faire l’introduction de nouvelles fonctionnalité lors d’un refactor de code. Le « comportement du code » ne doit pas être modifié sans quoi ce n’est plus du refactoring que nous faisons mais bien du développement. C’est aussi dans ces cas que l’on a le plus de chance de faire l’introduction de défaillances dans le système, peut être parce que les tests adéquats ne seront pas fait pleinement ou bien parce qu’on se dit que « c’est tellement simple comme changement » qu’il n’y aura aucun impact, ce qui n’est évidemment pas toujours le cas.