Quand est-il temps de remanier le code ?

Question

Sur place :
1. Vous n'avez jamais le temps de le faire.
2. Le "changement de contexte" est mentalement coûteux (il est difficile de quitter ce que l'on est en train de faire au milieu de celui-ci).
3. Ce n'est généralement pas une tâche facile.
4. Il y a toujours la peur de casser quelque chose qui fonctionne maintenant.

De l'autre :
1. L'utilisation de ce code est source d'erreurs.
2. Au fil du temps, vous pourriez vous rendre compte que si vous aviez remanié le code dès la première fois, vous auriez gagné du temps sur le long terme.

Ma question est donc la suivante : en pratique, quand décidez-vous qu'il est temps de remanier votre code ?

Gracias.

Answer 1

Lorsque je mets en œuvre une nouvelle fonctionnalité, je constate souvent que la tâche serait beaucoup plus simple si le code sur lequel je travaille était structuré d'une manière différente. Dans ce cas, je prends généralement du recul, j'essaie d'abord de faire le remaniement, et ce n'est qu'après que je continue à mettre en œuvre la nouvelle fonctionnalité.

J'ai aussi l'habitude de noter toutes les améliorations potentielles qui me viennent à l'esprit, soit dans des notes, soit dans le gestionnaire de bogues. Les idées restent là pendant un certain temps, certaines d'entre elles ne sont plus aussi convaincantes, et les plus raisonnables sont mises en œuvre pendant une journée que je consacre à des tâches plus modestes.

Answer 2

Cela peut sembler être une blague, mais en réalité, je ne remanie que lorsque les choses "deviennent désordonnées". Quand une tâche simple commence à prendre plus de temps et d'habitude, quand je dois me retourner l'esprit pour me rappeler quelle fonction fait quoi et ainsi de suite. De même, si le code commence à tourner lentement et que ce n'est pas parce que je travaille dans un environnement de développement (beaucoup de sorties variables, etc.), si je ne peux pas l'optimiser, je le remanie. Comme vous l'avez dit, cela vaut la peine à long terme.

Néanmoins, je m'assure toujours d'avoir suffisamment de temps pour réfléchir avant de commencer, afin de ne pas me retrouver dans cette situation.

A la vôtre !

Answer 3

J'ai l'habitude de refactoriser lorsque l'une des situations suivantes est vraie :

• Je n'ai rien de mieux à faire et j'attends le prochain projet qui arrivera dans ma boîte aux lettres.
• Les ajouts/changements que j'apporte au code ne peuvent fonctionner que si, ou serait mieux si, je refactorise
• Je suis esthétiquement mécontent de la façon dont le code est présenté.

Answer 4

Martin Fowler dans son livre si le même nom suggère que vous le faites la troisième fois que vous êtes dans un bloc de code pour faire une autre modification. La première fois dans le bloc, vous remarquez par hasard que vous devriez refactorer, mais vous n'avez pas le temps. La deuxième fois... même chose. La troisième fois... vous devez refactorer. De plus, j'ai lu que les développeurs d'une version actuelle de smalltalk (squeak.org, je crois) disent qu'ils passent par deux semaines de codage intense... puis ils prennent du recul et regardent ce qui peut être remanié. Personnellement, je dois résister à l'impulsion de refactoriser pendant que je code, sinon je suis "paralysé".