1. Élimination du code mort. Si un objet contient des méthodes qui ne sont plus utilisées depuis longtemps, cela veut dire que ces méthodes ne sont plus tenues à jour à cause de leur inutilité. La crainte d'avoir un jour besoin de ces méthodes pousse à les garder en place, mais le manque de maintenance du code fera prendre un risque considérable le jour où on voudra l'utiliser. De plus, les outils de gestion de source (type Subversion) permettent justement de retrouver les anciennes versions d'un fichier. Alors autant effacer immédiatement le code inutile. Cette remarque s'applique aussi aux blocs de code qui sont laissés en commentaire depuis la nuit des temps, et que personne n'ose toucher « au cas où on en aurait besoin ».
  2. Normalisation et documentation du code. Le code restant, celui qui est réellement utilisé, doit ensuite être nettoyé pour le rendre compréhensible de nouveau. Si vous avez mis en place des normes de codage, assurez-vous qu'elles soient appliquées. Reprenez la documentation "externe" (celle qui permet d'utiliser ce code) ; assurez-vous que les paramètres et les valeurs de retours correspondent bien à ceux présents dans le code ; vérifiez que les explications fournies sont toujours exactes au regard du code ; rappelez-vous que la documentation doit dire à quoi sert le code, ce qu'il fait, et non comment il le fait. Enfin, ajoutez des commentaires aux endroits les plus complexes du code, pour expliquer comment il fonctionne. Profitez-en pour ajouter les messages de logs qui pourraient manquer. Ainsi, ils seront disponibles le jour où vous aurez besoin de tracer finement l'exécution du programme.
  3. Renommage et harmonisation. Vous aviez un petit objet nommé SimpleUserManager, mais qui contient maintenant 80 méthodes ? Ou un autre a été rapidement nommé GlobalApplicationProxy ? Prenez le temps de les renommer intelligemment. Faites de même avec les méthodes, qui devraient idéalement se comprendre rien que par leur nom, sans nécessiter de documentation. S'il le faut, reprenez aussi l'ordre des paramètres pour qu'ils restent logiques d'une méthode à l'autre. Le mot d'ordre doit être de créer une harmonie à travers le code, pour simplifier sa maintenance future. L'harmonisation du code consiste aussi à déplacer des bouts de code (d'un fichier à un autre, d'un objet à un autre, ...) pour remettre les choses logiquement à leur place. Demandez-vous « Où aurais-je tendance à chercher cette fonction ? » ; c'est souvent là où elle devrait être, et non pas là où elle a été codée.
  4. Optimisation. Si et seulement si les étapes précédentes ont été réalisées sérieusement, vous pouvez procéder à l'amélioration du code pour des raisons de performance. Cela peut concerner un algorithme un peu délicat, ou des requêtes complexes sur une base de données. Mais souvenez-vous que les optimisations doivent toujours se faire en dernier, à l'unique condition que le périmètre applicatif soit connu et bien défini. Il est déjà assez risqué d'optimiser un système sans le mettre en vrac, ne vous lancez surtout pas dans une optimisation mélangée avec des modifications fonctionnelles, vous iriez droit dans le mur.

Quand faire une refactorisation

C'est la grande question habituelle. Faut-il vraiment ralentir les développements en prenant du temps à s'embêter avec ça ? La plupart des jeunes développeurs ont tendance à vouloir foncer dans leurs développements, ajouter sans cesse de nouvelles fonctions, sans jamais se retourner. Si on leur parle de refactorisation, ils admettent la nécessité de la chose, mais préfèrent toujours remettre à plus tard.

En fait, il faut comprendre que le calcul est simple. Plus tôt le refactoring intervient, moins il est coûteux en temps.

Chaque période de développement (par exemple un sprint si vous utilisez la méthode Scrum) devrait être immédiatement suivie d'un temps de refactorisation, qui servira à consolider le code qui vient juste d'être réalisé, le débarrasser de ses scories et s'assurer que la documentation qui l'accompagne est complète.
Si on schématise un peu, on peut imaginer qu'un mois de développement ne prendra qu'une seule journée à être mis au propre si c'est fait dans la foulée. Ainsi, au bout d'une année de codage, c'est à peine 12 jours qui auront été consacrés à la refactorisation.

Par contre, je peux vous dire d'expérience que si vous attendez la fin de l'année de développement avant de faire le grand ménage, vous y passerez au minimum un mois entier. Non seulement le coût global sera bien plus élevé, mais vous prenez le risque d'interrompre un jour tous vos projets pendant un mois entier !
A contrario, dépenser une simple journée par mois est assez indolore en terme de coût et de planning.

Après, c'est à vous d'être responsable et consciencieux. Vous aurez sûrement à convaincre vos collègues du bien-fondé de cette pratique. Si vous n'avez pas de chance, vous aurez même à l'expliquer à vos supérieurs. Mais tenez bon, c'est à ce prix – minime – que vous préparerez un futur serein.