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

Question

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

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

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

(Да, мы все знаем мы не должны переписывать вещи , но это мой "веселый" репозиторий, а не мои бизнес-проекты ...)

Обновление

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

Используйте Определения внешних элементов (свойство svn: externals ), чтобы ссылаться на ваш прежний код так же, как в стороннем хранилище.

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