Comme promis lors de mon précédent billet je vais vous détailler la partie de la présentation du legacy au cloud en moins d’une heure de David Gageot, consacrée au refactoring.
Il est parti d’un kata disponible sur son github et plus particulièrement de la classe LegacyInn pour nous faire une démonstration en live-coding de ses méthodes de refactoring.
Comme vous pouvez le constater la classe de départ est particulièrement affreuse.
Voici d’ailleurs un extrait de la classe principale.
Si vous êtes chargé de refactoriser cette classe, il y a des chances que vous partiez des spécifications existantes d’autant plus qu’elles sont assez courtes. David est parti d’une autre approche : commencer par écrire des tests pour comprendre ce que faisait vraiment ce bout de code. Après tout sur du code legacy, les spécifications ne sont plus forcément à jour, on nous demande surtout de ne pas modifier le fonctionnement existant, d’être isobug comme diraient certains.
David à donc commencé à écrire des tests basiques pour les méthodes getItems () et updateQuality () avec l’aide du plugin infinitest. Il permet de visualiser le résultat des tests en temps réel. Toujours sans chercher à comprendre le code legacy, il a utilisé le résultat des tests en échec pour avoir les bonnes valeurs. Il a ensuite vérifié sa couverture de test avec Emma et complété ceux-ci. Pour les curieux le résultat final des tests est aussi disponible sur son github.
Nous voilà donc avec une classe de test assurant une bonne couverture du code. Les bases sont posées, on peut commencer l’amélioration du code legacy. Pour ce faire chacun à sa méthode, David lui, a commencé par introduire de la symétrie: on reformate le code et on en déplace des parties pour les faire ressortir. A chaque modification, les tests sont automatiquement relancés et on voit tout de suite si on a introduit une anomalie, merci infinitest! On remarque au passage l’importance d’avoir une suite de tests s’exécutant rapidement. Une fois la symétrie introduite David ajoute de la répétition dans le code. Ce qui lui a ensuite permis de faire des extractions de méthodes. On dispose désormais d’IDE assez puissant, on peut leur faire confiance pour ces tâches. On notera une autre chose (une évidence pour les développeurs confirmés), plus on connait les raccourcis, plus c’est rapide (Cf. article du blog sur les raccourcis Eclipse). Tellement rapide qu’après 30 minutes, ( David a pris son temps pour que nous comprenions) le refactoring était terminé.
Pour les curieux, le résultat correspondant à la méthode updateQuality () se trouve dans la classe ItemUpdater.On remarquera que David à utilisé Lombok pour effectuer un peu de délégation. En voici un extrait :
En ce qui me concerne je suis passionné par l’écriture d’un code toujours plus propre et je ne me lasse jamais d’apprendre des autres.
Il y a une multitude de sources pour cela : soit avec des collègues, lors de conférence comme celle-ci ou encore à travers la littérature comme avec le très bon livre de Martin Fowler sur le refactoring (un peu vieux certes, mais toujours d’actualité).
Et j’ai été agréablement surpris par la présentation de David. J’y ai appris une autre approche du refactoring, constaté l’utilité d’un plugin comme infinitest. Si vous avez l’occasion de le voir en conférence, n’hésitez pas!
Sinon, pour ceux que ça intéresse, j’ai aussi quelques recettes de cuisine :
- Keep it simple, Stupid
- Don’t Repeat Yourself
- You Arent Gonna Need It
- Single Responsibility Principle
- l’utilisation des designs pattern
- le catalogue de pattern de refactoring issu du livre de Martin Fowler.
Ceci dit, ce n’est pas parce que l’on a une liste de patterns ou de bonnes pratiques qu’il faut chercher à les appliquer à tout prix, mais plutôt sentir lorsque cela devient nécessaire. Et là c’est une affaire de sensibilité personnelle et d’expérience.
