Как вы относитесь к устаревшему коду (и данным)?
В настоящее время я нахожусь в процессе реструктуризации моего локального репозитория Subversion, добавляя в него несколько новых проектов и объединяя в него унаследованный код и данные из нескольких старых репозиториев.
Когда я делал это в прошлом, я обычно помещал унаследованный код в специальную «устаревшую» папку, чтобы не «мешать» новому и «хорошо структурированному» дереву кода. Однако в духе рефакторинга я считаю, что это несколько неправильно. Теоретически унаследованный код со временем будет реорганизован и перемещен в новое место, но на практике это случается редко.
Как вы относитесь к своему унаследованному коду? Как бы мне ни хотелось спрятать старые грехи в папку «наследие», чтобы никогда больше не взглянуть на нее, на каком-то уровне я надеюсь, что, заставив ее жить среди более «здоровых» обитателей хранилища, возможно, наследство код будет иметь больше шансов на выздоровление когда-нибудь?
(Да, мы все знаем мы не должны переписывать вещи, но это мой "забавный" репозиторий, а не мои бизнес-проекты ...)
Обновлять
Меня не волнуют технические аспекты отслеживания различных версий. Я знаю, как использовать для этого теги и ветки. Это скорее психологический аспект, поскольку я предпочитаю иметь в репозитории «аккуратную» структуру, которая значительно упрощает навигацию для людей.
Ответы 5
Пометка - очень дешевая операция для подрывной деятельности. Помечайте свой код, когда вы начинаете рефакторинг, и на регулярных этапах по мере продвижения. Таким образом, будет легко получить доступ к старому (но функциональному коду) в качестве справочника для вашего блестящего нового (но неработающего кода). :-)
В один прекрасный день весь код становится «устаревшим», зачем его вообще разделять? Управление исходным кодом осуществляется по проекту / ветке или проекту / платформе / ветке и этому типу иерархии. Какая разница, как долго он находится в зубе?
Используйте Внешние определения (свойство svn: externals), чтобы ссылаться на ваш устаревший код, как на сторонний репозиторий.
Затем вы можете отделить свою работу по рефакторингу от зависимых проектов и (используя фиксированные ссылки на ревизии, т.е. -r1234) очень четко указать, от какой ревизии унаследованного кода зависит зависимый проект.
Вот ваш бесплатный психологический анализ:
У вас есть глубоко укоренившееся желание исправить устаревший код, чтобы он больше не был устаревшим. Когда вы скрываете его, вы просто подавляете это желание, пытаясь избежать его, потому что это неприятное чувство. Если вы оставите это открытым, произойдет одно из двух: в конечном итоге это сведет вас с ума, и вам придется убить себя, или (что более оптимистично) вам будут напоминать о каждом беспорядке и до тех пор, пока вы, наконец, не сломаете и не очистите его.
Не скрывайте беспорядок; убери это. Иначе рано или поздно он вернется, чтобы укусить вас.
Это зависит от того, что вы называете наследие. Если, говоря «унаследованный», вы действительно имеете в виду «код из какого-то устаревшего приложения, который настолько плох, что мы никогда его больше не будем использовать», он должен быть отделен от текущего кода. Если это что-то из вашего текущего проекта, но написано другими людьми или не соответствует вашим текущим стандартам, просто отнеситесь к нему как обычно, но отметьте его для повторного факторинга в будущем в вашем трекере проблем.
... и некоторые из них: «однажды в будущем, когда у меня будет много свободного времени, я хотел бы снова заняться этим проектом, но я не совсем уверен, когда или даже если это когда-нибудь произойдет, но я хочу сохранить код на всякий случай ".
Различается. Некоторые из них: «Я должен реорганизовать это как можно скорее, но это скучно, поэтому я продолжаю откладывать это», а некоторые - «Я написал это десять лет назад и хотел бы сохранить это на случай, если мне когда-нибудь понадобится сделать что-то подобное снова. или я просто испытываю ностальгию и хочу взглянуть на старый код ».