Quelles sont les bonnes approches pour nettoyer les anciens projets?

11

J'ai un logiciel que j'ai écrit il y a environ 2 ans et j'ai besoin de quelques fonctionnalités supplémentaires. J'ai réalisé que c'était dans un horrible gâchis, et j'ai envie de tout déplacer, de ranger, etc. J'ai lu l'article de Joel on Software sur le fait de ne pas recommencer , alors quelle est la meilleure voie à suivre?

refactoring maintenance

— billy.bob
source

Avec quelles décisions de l'époque êtes-vous en désaccord aujourd'hui?

21

Vous disposez de trois options de base:

Si l'application est très petite et un vrai gâchis , recommencer pourrait être votre meilleur choix.
Refactor .
Vivez avec le désordre et piratez les fonctionnalités supplémentaires.

En règle générale, l'option (2) est votre meilleur choix.

La quantité de refactoring que vous effectuez dépendra de la ressource que vous investissez par rapport à la valeur que vous retirez. Les questions à poser comprendront:

Quel temps / budget est disponible?
Combien de modifications prévoyez-vous à l'avenir?
Qui d'autre verra le code? (c.-à-d. est-ce qu'un code désordonné endommagera votre réputation?)
Est-ce que quelqu'un d'autre devrait maintenir le code?
Quels outils de refactoring sont disponibles pour vous aider?
Quelle est votre expérience de refactoring?
Quelle expérience allez-vous acquérir de la refactorisation?
Quels types de refactoring vous apporteront le plus d'avantages?
Quels tests automatisés existent déjà? Besoin d'être écrit?
Combien de tests manuels seront nécessaires?
Comment vous sentirez-vous si vous laissez le code tel quel?

D'après mon expérience, il est très facile de s'embrouiller correctement lors d'une séance de refactoring. Les leçons les plus importantes que j'ai apprises sont les suivantes:

Faites une chose à la fois.
Faites de petits pas.
Faites bon usage de votre contrôle de code source (vérifiez fréquemment + ajoutez des commentaires).
Utilisez des outils de refactorisation automatisés.
Connaissez l'IDE.

— Kramii
source

6

Je voudrais également ajouter pour éviter d'avoir un état cassé trop longtemps. J'ai vu de nombreux projets open source mourir rapidement lors d'une ambitieuse réécriture / refonte. Un projet non fonctionnel tue rapidement la motivation.

— LennyProgrammers

2

Absolument. En ce qui concerne les réécritures / designs ambitieux, je suis tombé sous le coup plusieurs fois. Maintenant, j'essaie de prendre les choses en petites étapes. J'ai ajouté cette suggestion à ma réponse.

— Kramii

J'ajouterais également que vous ne devriez pas refactoriser tout ce qui n'a pas de test écrit pour cela. Résistez à l'envie de tout réparer et concentrez-vous uniquement sur les zones à modifier pour ajouter les nouvelles fonctionnalités. Une fois que vous avez fait cela, décidez ensuite combien d'efforts supplémentaires vous souhaitez consacrer à la refonte du reste.

— TMN

1

@TMN: Idéalement, oui. Cependant, vous n'avez pas toujours besoin d' un test automatisé. (1) Si le code a été développé sans tests automatisés, il peut ne pas être facile / possible d'ajuster les tests unitaires jusqu'à ce que vous ayez déjà effectué une refactorisation (2) Il peut être coûteux d'écrire des tests avant d'apporter des modifications localisées triviales. (3) Des outils de refactorisation automatisés + des fonctionnalités IDE peuvent aider à empêcher la rupture de code à la suite de la refactorisation.

— Kramii

2

J'ajouterais - dans votre contrôle de source, mettez tous les refactoring sur une BRANCH distincte. Cela permet d'effectuer des comparaisons sensées par étapes ainsi que par gros blocs. Cela peut être inestimable si les choses se transforment en crème pâtissière (QU'ILS VONT).

— quick_now

5

Eh bien, au moins refactoriser suffisamment pour que la nouvelle fonctionnalité puisse être ajoutée en toute sécurité. Ce n'est pas pire. Le reste dépend de la motivation, du budget et des contraintes de temps - mais sachez que le nettoyage complet d'un gâchis peut prendre plus de temps que sa création d'origine.

— user281377
source

1

C'est bien sûr la fameuse règle Boyscout: laissez toujours le code dans un meilleur état que vous ne l'avez trouvé.

— Jörg W Mittag

2

Cette fois, en réparant les choses, assurez-vous de le documenter. La prochaine fois que vous verrez le code, il sera beaucoup plus facile de rappeler les choses.

— Manoj R
source

1

Cela dépend, cela va-t-il coûter plus de temps pour le maintenir parce que c'est un gâchis, ou pour le réécrire afin que ce ne soit pas un gâchis et facile à entretenir. Je suis personnellement en train de passer par là en ce moment, je convertis un site intranet en ASP.Net MVC3 parce que l'ancien code était un tas de merde (que j'ai écrit) parce qu'il était censé être jetable (oui, je devrais savoir mieux ). Le vieux tas de merde est toujours là, et c'est un casse-tête d'ajouter des fonctionnalités et de corriger des bugs. MVC est magnifique et rend le travail vraiment agréable, donc il faut une réécriture.

— Glace noir
source