Как вы относитесь к устаревшему коду (и данным)?

Question

В настоящее время я реорганизую свой локальный репозиторий Subversion, добавив несколько новых проектов и объединив устаревший код и данные из нескольких старых хранилищ.

Когда я это делал раньше, я обычно ставил устаревший код в выделенной папке «устаревший», чтобы не «беспокоить» новое и «хорошо структурированное» дерево кода. Однако, в духе рефакторинга, я чувствую, что это несколько неправильно. Теоретически устаревший код будет реорганизован с течением времени и перенесен в новое место, но на практике это редко случается.

Как вы относитесь к своему устаревшему коду? Насколько я чувствую соблазн убрать старые грехи в «старой» папке, никогда не смотреть на нее снова, на каком-то уровне я надеюсь, что, заставив ее жить среди более «здоровых» жителей в репозитории, возможно, наследие у кода будет больше шансов на выздоровление в какой-то день?

(Да, все мы знаем we shouldn't rewrite stuff, но это мое «весело» хранилище, а не мои бизнес-проекты ...)

Update

Я не беспокоюсь о технических аспектах поддержания отслеживать различные версии. Я знаю, как использовать теги и ветви для этого. Это скорее психологический аспект, так как я предпочитаю иметь «аккуратную» структуру в репозитории, что значительно упрощает навигацию для него. — для людей.

Answer 1

Весь код становится «устаревшим» в один прекрасный день, почему его вообще не разделять? Контроль источника осуществляется по проекту/ветви или проекту/платформе/ветви и этому типу иерархии. Кого волнует, как долго в зубе?

Answer 2

Маркировка - очень дешевая операция в подрывной деятельности. Пометьте свой код, когда вы начинаете рефакторинг и на регулярной стадии, пока вы идете вперед. Таким образом, легко получить доступ к старому (но функциональному коду) в качестве ссылки для вашего блестящего нового (но сломанного кода). :-)

Answer 3

Использование Внешние определения (svn:externals) ссылка на ваш устаревший код, так же как и сторонний репозиторий.

Затем вы можете разделить свою работу по рефакторингу с зависимыми проектами и (с использованием фиксированных ссылок на ревизию, т. Е. -r1234), быть очень явным, о том, какая версия устаревшего кода зависит от зависимого проекта.

Answer 4

Вот ваш бесплатный психологический анализ:

То, что вы здесь глубоко укоренившееся желание исправить унаследованный код, так что это не наследство больше. Когда вы скрываете это, вы просто подавляете это желание, пытаясь избежать этого, потому что это неудобное чувство. Если вы оставите это в открытом доступе, произойдет одна из двух вещей: это в конечном итоге приведет вас к безумию, и вам придется убить себя или (более оптимистично), вам будут напоминать о каждом беспорядочном бит и пока вы, наконец, не сломаетесь и не очистите его.

Не скрывайте беспорядок; убери это. В противном случае он вернется, чтобы укусить вас рано или поздно.

Answer 5

Это зависит от того, что вы называете legacy. Если, говоря устаревшим, вы действительно имеете в виду «код из какого-то отставного приложения, который так плох, мы больше никогда его не будем использовать», он должен быть отделен от вашего текущего кода. Если это что-то из вашего текущего проекта, но написано другими людьми или не соответствует вашим текущим стандартам, просто относитесь к нему нормально, но помечайте его для повторного факторинга в будущем в своем трекер-проблеме.