Comment traitez-vous le code (et les données) hérités?

Question

Je suis actuellement en train de restructurer mon référentiel Subversion local en ajoutant de nouveaux projets et en fusionnant du code et des données hérités de quelques anciens dépôts. Lorsque je l'ai fait par le passé, j'ai généralement placé le code existant dans un dossier "legacy" dédié, afin de ne pas "perturber" le nouvel arbre de code "bien structuré". Cependant, dans l'esprit du refactoring, je pense que c'est un peu faux. En théorie, le code existant sera refaçonné au fil du temps et déplacé vers son nouvel emplacement, mais dans la pratique, cela arrive rarement.

Comment traitez-vous votre ancien code? Autant je suis tenté de ranger les vieux péchés dans le dossier «héritage», de ne plus jamais le regarder, mais j'espère qu'en le forçant à vivre parmi les habitants les plus «sains» du référentiel, peut-être l'héritage code aura une meilleure chance de se rétablir un jour?

(Oui, nous savons tous we shouldn't rewrite stuff, mais ceci est mon dépôt « fun », pas mes projets d'affaires ...)

Mise à jour

Je ne suis pas inquiet sur les aspects techniques du maintien piste de différentes versions. Je sais comment utiliser les tags et les branches pour ça. C'est plus un aspect psychologique, car je préfère avoir une structure «soignée» dans le référentiel, ce qui rend la navigation beaucoup plus facile pour les humains.

Answer 1

Tout le code devient 'legacy' un jour, pourquoi le séparer du tout? Le contrôle de la source est par projet/branche ou projet/plateforme/branche et ce type de hiérarchie. Qui se soucie de la longueur de la dent?

Answer 2

L'étiquetage est une opération très bon marché dans la subversion. Marquez votre code lorsque vous commencez à refactoriser et à des étapes régulières pendant que vous avancez. De cette façon, il est toujours facile d'accéder à l'ancien (mais fonctionnel code) comme référence pour votre nouveau brillant (mais le code cassé). :-)

Answer 3

Utilisez Externals Définitions (svn:externals propriété) pour référencer votre ancien code comme vous le feriez pour un référentiel tiers. Ensuite, vous pouvez séparer votre travail de refactoring de vos projets dépendants et (en utilisant des références de révision fixes, c'est-à-dire -r1234) être très explicite sur la révision du code existant dont dépend le projet dépendant.

Answer 4

Voici votre analyse psychologique gratuite:

Qu'est-ce que vous avez ici est un désir profond de fixer votre code existant pour que ce n'est pas plus l'héritage. Lorsque vous le cachez, vous réprimez simplement ce désir, en essayant de l'éviter parce que c'est un sentiment inconfortable. Si vous le laissez à l'air libre, l'une des deux choses suivantes se produira: elle finira par vous rendre folle et vous devrez vous tuer, ou (plus optimiste), vous rappellera chaque bit et jusqu'à ce que vous tombiez enfin en panne et nettoyiez-le.

Ne cachez pas les dégâts; nettoie. Sinon, il reviendra vous mordre tôt ou tard.

Answer 5

Cela dépend de ce que vous appelez héritage. Si en disant héritage, vous voulez vraiment dire «code d'une application retirée qui est si mauvais que nous ne l'utiliserons plus jamais», il devrait être séparé de votre code actuel. S'il s'agit d'un élément de votre projet actuel, mais qu'il est écrit par d'autres personnes ou qu'il ne correspond pas à vos normes actuelles, traitez-le normalement, mais signalez-le pour qu'il soit réintégré ultérieurement dans votre outil de suivi.