Comment réviser votre code?

Question

Je me retrouve à revisiter des zones de mon projet et à les affiner à nouveau. Cela arrive généralement quand je commence quelque chose à partir de rien et que si je comprends bien, mon code et mes techniques s'améliorent, donc je reviens sur ce que j'ai fait et je le rends plus fort. Est-ce normal ou je suis juste inexpérimenté? À quelle fréquence revoyez-vous votre code? Est-ce que les bons programmeurs écrivent une fois et n'ont pas besoin de changer les choses?

Answer 1

Je suis d'accord avec les réponses des autres, mais ça dépendra aussi de la raison pour laquelle vous écrivez du code. Si c'est un projet spécifique pour une date limite, vous n'aurez peut-être pas beaucoup de chance. S'il est susceptible d'être réutilisé par d'autres, assurez-vous que le refactoring ne casse rien de ce qu'ils utilisent. S'il s'agit d'un projet à long terme, surtout s'il s'agit d'un projet commun, il est presque certain qu'il nécessitera un refactoring complet.

J'ai écrit une bibliothèque communale pendant environ 13 ans et ai subi 5 révisions et demie (celle que je traverse). Dans de nombreux cas, c'est parce que la technologie s'est améliorée et ce que j'ai fait pour moi-même, je peux maintenant faire avec des bibliothèques standard. Et au fil des ans, j'ai appris beaucoup de meilleures stratégies.

En général, un bon refactoring implique souvent de supprimer du code ancien.

MISE À JOUR Les outils modernes facilitent la réalisation automatique d'un grand nombre d'opérations (par exemple, changement de noms, de paquets). Les experts recommandent que les méthodes soient courtes et que lorsque vous trouvez votre méthode s'étendant à deux pages, refactorisez-la en plus courtes. Mais il y a des moments où les outils ne vous aideront pas et vous devez créer du code qui est temporairement cassé. Dans ce cas, assurez-vous (a) que les tests unitaires s'exécutent sur la version de travail (b) validez-la.Il est facile d'entrer dans une opération complexe de refactoring et de réaliser que vous l'avez assez mal fait pour revenir en arrière. Si vous avez des utilisateurs qui dépendent de votre code, assurez-vous de continuer à fournir l'API qu'ils connaissent. Par exemple, supposons que vous avez une routine appelée

Date date = getLastUpdate(); 

et vous décidez (comme moi et beaucoup d'autres ont fait) que java.util.Date est désespérément cassé. Vous décidez de changer à Joda DateTime mais pendant le processus il sera difficile. Vous avez probablement besoin de mettre de côté un temps pour le terminer en un seul passage. Ne changez pas l'API pour

DateTime date = getLastUpdate(); 

Créer une nouvelle interface, comme

DateTime date = getLastDateTimeUpdate(); 

Ensuite, marquez l'original comme @Deprecated

Vous ne devez pas supprimer la version précédente jusqu'à ce que vous décidez de faire un nouvelle version (changer d'API de manière dynamique perd des amis)

Answer 2

Je dirais que vous n'avez pas à vous inquiéter, en passant votre code est normal et aide à améliorer votre compréhension. La seule fois où vous voulez vous inquiéter, c'est de passer en revue le même code et de changer l'implémentation encore et encore.

Même si vous êtes inexpérimenté en vous salissant les mains, en écrivant et en testant le code, vous vous améliorerez.

Answer 3

Le passage du code est correct ... assurez-vous simplement de le tester si vous le modifiez (la mise en place de tests de régression automatisés serait une bonne idée).

De même, si vous utilisez le même code à plusieurs endroits, placez-le dans une bibliothèque de classes afin de ne l'avoir qu'à un seul endroit (et donc aucune amélioration ne doit être effectuée qu'une seule fois).

Est-ce normal? - Oui (pour autant que cela ne prenne pas trop de temps à partir d'autres projets)

À quelle fréquence referez-vous votre code? - Chaque fois que je travaille à nouveau avec ce code et que j'ai le temps de le regarder

Est-ce que les bons programmeurs écrivent une fois et n'ont pas besoin de changer les choses? - Il y a plus d'une façon de peler un chat, donc c'est subjectif.

Answer 4

Je dirais que c'est en bonne santé, et je considère que c'est une bonne pratique. Le refactoring est crucial pour une bonne base de code, tant que vos tests sont bons.

En TDD le cycle est:

• Red
• vert
• Refactor