J'ai un code très encombré, et la révision actuelle est presque terminée, ce qui signifie que toutes les fonctionnalités que je voulais pour cette révision/sprint sont terminées.
Devrais-je terminer cette révision telle qu'elle est et la refactoriser plus tard ou devrais-je la refacturer maintenant?Code encombré (presque complet): refactoriser maintenant ou plus tard?
Il n'y a pas de réponse "correcte" pour cela, c'est vraiment une question de priorités?
Vous devez considérer toutes ces questions ensemble. Je trouve généralement que le refactoring peut, en particulier sur les grands projets, prendre beaucoup plus de temps et d'efforts que vous ne le pensez. Vous pouvez également casser des choses (c'est là que les tests unitaires sont incroyablement utiles).
Je vais généralement essayer de publier sur des projets commerciaux puis refactoriser à moins qu'il y ait des problèmes majeurs avec le code existant.
Si vous êtes sur une date limite et que c'est quelque chose à venir, ce n'est probablement pas une bonne idée de vraiment faire des changements massifs. Si vous pensez que le nettoyage est gérable, allez-y. Ce que je vous recommande de faire est de brancher votre base de code actuelle et faire le refactoring là-bas. Puis fusionnez-le de nouveau. Ou vous pouvez utiliser la branche comme branche de publication et refactoriser dans le coffre. Plus il reste encombré, plus il sera difficile de le maintenir, alors faites le plus tôt possible si vous le jugez nécessaire.
Refactorisez maintenant. Surtout si vous avez un débogage avant.
+1 Sérieusement, je viens de passer mes deux dernières heures dans une base de code très moche! Réfléchissez tout de suite. Une fois que le code devient méchant, le mauvais code commence à s'empiler et le nouveau code que vous ajoutez commence à coder autour des défauts de l'ancien code, le rendant à son tour mauvais code. À un certain point, vous arrêtez simplement de vous soucier car les seules options sont une réécriture complète et sont bloquées dans l'entretien-enfer. – Tigraine
J'ai des fonctions qui font beaucoup de choses en même temps, parce que je pensais que c'était "plus rapide si je l'avais fait ici dans cette fonction". Mais maintenant, il a atteint un point où je ne veux pas que cette fonction spécifique fasse plus d'une chose. Presque toutes les fonctions sont comme ça. Je pense sérieusement à tout couper et définir une bonne structure de code, très modulaire et OO. –
Parfois, c'est le meilleur refactoring. Après avoir terminé un projet/une itération/quoi que vous finissiez toujours plus intelligemment, comment cela aurait dû être fait, et cela ira plus vite parce que vous avez maintenant toute l'image. Cependant, une réécriture complète n'est pas toujours possible pour d'autres raisons. Faites simplement une analyse coûts/bénéfices. – Nick
Si la question concerne faire quelque chose facile à gérer et à utiliser, et la question est «maintenant ou plus tard», la réponse est toujours MAINTENANT.
Les projets «presque terminés» prennent plus de temps à finir que prévu. Rappelez-vous: Les 90 premiers 90% du code prennent les 90 premiers 90% du temps, les 10 derniers% du code prennent les 90 derniers temps. =)
Si vous codez une exigence/api stable, il n'y a aucune raison de ne pas refactoriser maintenant, si vous avez le temps.
Si les exigences/api sont une cible en mouvement, le fait de refactoriser ou non va être une décision situationnelle et subjective.
MAIS .....
Si vous ne l'avez pas encore fait, écrire des tests qui donnent une large couverture avant refactoring.
Je ne peux pas insister assez sur ce point.
Un gros +1 pour ça. Refactoriser sans tests (surtout sans outils automatisés) est risqué. Encore une raison de favoriser TDD (ou du moins d'écrire les tests avec le code). – TrueWill
@true - vrai que, mais les tests après est mieux que rien et donne beaucoup des mêmes avantages que le test d'abord. –
Faites le refactoring dans le cadre de votre implémentation. Avoir des tests unitaires complets pour pouvoir refactoriser sans introduire de défauts.
Refactorisez maintenant. Le refaçonnage procrastiné est un refactoring difficile. Aujourd'hui, le code est frais dans votre esprit et non sali par les changements de demain; il est aussi mûr qu'il le sera pour le refactoring. Mûr mais pas encore pourri.
C'est un petit projet jusqu'à présent. Le code fonctionne, mais je me trouve souvent en train de commenter et de décommenter des choses pour voir une "sortie différente". Je pense qu'avec une meilleure structure je devrais juste employer des méthodes différentes au lieu de la procédure de commentaire/commentaire. Pas de délais, la qualité est la priorité absolue. –
@Jorge Qualité première priorité? Refactoriser maintenant. Vous rendez le code plus lisible, ce qui vous permet de repérer plus facilement les erreurs. – extraneon