Comment s'empêcher de refactorer du code qui fonctionne mais qui est mauvais ?

Question

J'ai un problème. Je ne peux pas m'empêcher de remanier du code existant qui fonctionne mais qui, à mon avis (et peut-être objectivement), est mal conçu ou contient d'autres "odeurs de code". Cela peut avoir un effet négatif important sur ma productivité immédiate. Mais, en fin de compte, ce sera un grand avantage pour la maintenance.

Si vous souffrez également de cette "affliction", comment vous retenez-vous ? Ou du moins, gérez-vous le remaniement pour éviter de devoir modifier de gros morceaux de code existant afin de le rendre maintenable à long terme.

Answer 1

Ce qui a marché pour moi, c'est de me faire virer pour ça.

Cela dit, mon problème de base était double :

1. Je refaisais du code sur lequel personne ne m'avait demandé de travailler.

2. J'ai trouvé trop difficile de mettre en place des tests, alors je l'ai fait sans eux. Ce qui, naturellement, a cassé certaines choses.

Ce que j'ai appris, c'est que :

1. Ne travaillez pas sur du code sur lequel vous n'avez pas besoin de travailler, et sur lequel personne ne vous a demandé de travailler. Il est facile de s'en souvenir maintenant, étant donné les conséquences dans le passé.

2. Quand vous avez besoin de refactoriser du code, vous sont censé travailler, avoir des tests en place, mais ils n'ont pas besoin d'être automatisés.

Après avoir lu trop de documents sur le TDD, j'ai eu tendance à considérer les tests automatisés comme le seul type de test existant. En réalité, même un groupe de Debug.Print Les déclarations peuvent être un bon test pour déterminer si la fonctionnalité reste cohérente.

Si vous ont pour refactoriser, et vous ne pouvez pas faire de tests automatisés, vous devez faire un peu de type de test, qu'il s'agisse de l'impression d'un texte, ou d'un script d'interface utilisateur, ou autre. Tout test efficace est mieux que pas de test du tout.

Answer 2

La réponse est que vous ne le faites pas. Ce n'est pas parce que le code fonctionne qu'il fonctionnera toujours. Un mauvais code est un mauvais code.

Nous remanions le code pour le rendre plus lisible, plus facile à maintenir et pour en assurer la fiabilité.

Tant que vous conservez la logique de l'ancien code, il devrait continuer à fonctionner, avec en prime un code globalement meilleur.

J'essaie toujours de laisser le code en meilleur état que je ne l'ai trouvé.

Answer 3

Décidez en fonction du "bénéfice net" au lieu d'écouter votre "voix intérieure". Si ce code est appelé à être réutilisé très souvent, il peut être judicieux de le remanier. Cependant, j'essaie généralement d'ignorer ma haine pour le "code smell" et de me concentrer sur le "bénéfice net". avantage/perte de temps rapport de la refactorisation en question..

Answer 4

Je ne dirai pas que je "souffre" de cette affliction mais... Je vous entends mon frère !

Je pense que nous devons laisser le code dans un meilleur état que lorsque nous l'avons laissé. Donc votre quête est noble. Appelons-la "refactoritis".

Je suppose que nous sommes tous d'accord sur les avantages du remaniement et que la nécessité de ce remaniement dépend du code... Au cœur de la question alors...

Une façon de me retenir, c'est d'essayer de me sentir en sécurité en sachant que c'est mûr pour être réparé. Et je sais comment le réparer. Et plutôt que de me retenir complètement, je fais juste une étape, comme la "méthode d'extraction". Et je laisse le prochain "round" de réparation pour plus tard (peut-être devrions-nous appeler cela "deuxième service" ou "dessert" si vous êtes sûr que c'est la dernière étape). Puis collez un gros TODO dessus, pour pouvoir le retrouver. Et clarifiez ce qui doit encore être fait.

Merci pour cette question intéressante. Je me demande si nous n'avons pas besoin d'un groupe de "refacteurs anonymes" où nous pourrions nous asseoir en cercle et partager nos problèmes et nos histoires de guerre.

Answer 5

En général, je ne me retiens pas. Si je trouve un mauvais morceau dans le code sur lequel je travaille, je le corrige directement.

Je travaille sur un logiciel qui est maintenu depuis environ 10 ans maintenant et qui devra fonctionner au moins 10 ans de plus. Dans une telle situation, plus longtemps une odeur de code reste dans le code, plus souvent mes collègues développeurs et moi-même tomberons dessus et perdrons du temps à essayer de la comprendre ou d'inventer des solutions de contournement. Cela coûte plus cher que de faire le travail tout de suite.

Les gros problèmes de conception qui nécessitent des jours de remaniement constituent une exception. Si ces problèmes n'entravent pas mon projet en cours de manière significative, je les ajoute à notre liste de tâches de maintenance pour que le remaniement soit une tâche planifiée dans un avenir proche.