On va lancer un chantier de refacto qui devrait nous prendre environ 3 semaines. Avez vous des conseils ?

Oui, 1) : essayez d’utiliser un vocabulaire commun s’appuyant sur des références extérieures tirées des pratiques reconnues, longtemps partagées et publiées. (cf commentaire)

Qu’est-ce que le refactoring ? C’est un geste de développement qui consiste à modifier du code afin d’en améliorer les qualités sans en modifier le comportement.

Ce qui motive un refactoring, c’est un défaut de qualité, de modularité, de lisibilité, qui peut être l’indice de problèmes plus profonds, et que les anglo-saxons appellent “code smell”.

Il y a dans le code un truc qui ne sent pas bon. Le but du refactoring est de corriger ce (léger) défaut de conception, et d’aussitôt passer à nouveau les vérifications automatisées sur le code afin de s’assurer que la modification n’a pas entraîné de régression.

Point important, qui mérite d’être souligné : le refactoring s’appuie entièrement sur la présence de vérifications automatisées pour le code concerné. Si vous ne pouvez pas vous convaincre par une exécution des tests que votre modification n’a pas changé le comportement du système, vous ne faites pas du refactoring : vous touchez à du code (et sans trop savoir où vous allez, en plus).

Ou pour le souligner une 2ème fois : pas de vérification auto ⇒ pas de refactoring.

Le refactoring est un geste qui s’exécute en complément avec 2 autres :

  • créer ou modifier le code de production
  • créer ou modifier des vérifications autos pour le code (soulignement no 3)

Autrement dit, et c’est ce qui rend sa mise en place si controversée, le refactoring se pratique en continu.

Ça ne veut pas dire qu’il faut pratiquer le refactoring “un peu chaque jour” : il faut pratiquer le refactoring toutes les 10 minutes en moyenne.

Ah ça y est. Revoilà le fondamentaliste TDD qui pointe le bout de son nez. Il nous emm.. avec sa rigueur de puriste.

C’est vrai. Pourquoi ne pas laisser les gens utiliser le vocabulaire qui leur plaît dans le contexte qui leur va bien ? Ah oui. Par ce qu’ils demandent des conseils.

Si vous avez devant vous un chantier de refactoring qui va vous prendre 3 semaines, 99% de chances que

  • vous ne disposiez pas de vérifs auto (c’est le “chantier” qui m’a mis la puce à l’oreille)
  • votre expérience en refactoring vous emmène bien au delà de 3 semaines, au pays du Temps qui ne se Rattrape Jamais.
  • la qualité de conception de votre code s’en trouve aggravée plutôt qu’améliorée
  • vos clients (PM, PO, Manager…) ne comprennent pas ce que vous faites

(et il s’impatienteront à bon droit : imaginez qu’un collègue vous demande 3 semaines de budget pour un chantier de compilation. Ça n’a pas de sens n’est-ce pas ?)

2) ne vous lancez pas dans un chantier de refactoring

3) si vous avez 3 semaines que vous pouvez sortir de la “Création de la Valeur (tm)”, mettez les à profit pour acquérir puis raffermir votre pratique continue du refactoring

chantier-refacto

Publié sur Linked In le 19/10/2024