Как провести рефакторинг в дженерики из класса, который наследуется от CollectionBase?

Question

Я работаю над приложением, содержащим около 250 000 строк кода.В настоящее время я единственный разработчик, работающий над этим приложением, которое изначально было создано в .NET 1.1.Pervasive повсюду — это класс, наследуемый от CollectionBase.Все коллекции баз данных наследуются от этого класса.Вместо этого я рассматриваю возможность рефакторинга для наследования от общей коллекции List.Излишне говорить, что в книге Мартина Фаулера «Рефакторинг» нет никаких предложений.Стоит ли мне попробовать этот рефакторинг?Если да, то как лучше всего справиться с этим рефакторингом?

И да, повсюду есть юнит-тесты, но нет команды контроля качества.

Answer 1

250 000 строк — это много для рефакторинга, плюс вам следует принять во внимание некоторые из следующих факторов:

1. Есть ли у вас отдел контроля качества, который сможет проверить рефакторинг кода?
2. Есть ли у вас модульные тесты для старого кода?
3. Существуют ли временные рамки проекта, т.е.вы поддерживаете код, поскольку пользователи находят ошибки?

если бы вы ответили «нет» на 1 и 2, я бы в первую очередь написал модульные тесты для существующего кода.Сделайте их обширными и тщательными.Как только они будут у вас на месте, разветвите версию и начните рефакторинг.Модульные тесты должны помочь вам правильно выполнить рефакторинг дженериков.

Если 2 — да, то просто разветвляйтесь и начинайте рефакторинг, полагаясь на эти модульные тесты.

Отдел контроля качества также очень поможет, поскольку вы можете предоставить им новый код для тестирования.

И наконец, если клиентам/пользователям необходимо исправить ошибки, сначала исправьте их.

Answer 2

Не.Если только у вас нет действительно хорошего бизнес-обоснования для проведения этого упражнения в вашей кодовой базе.Какую экономию средств или доход принесет ваш рефакторинг?Если бы я был вашим менеджером, я бы, наверное, не советовал этого делать.Извини.

Answer 3

Насколько раскрыта CollectionBase из унаследованного класса?
Есть ли вещи, которые Generics мог бы сделать лучше, чем CollectionBase?

Я имею в виду, что этот класс активно используется, но это только один класс.Ключ к рефакторингу — не нарушать статус-кво программы.Класс должен всегда поддерживать свой контракт с внешним миром.Если вы можете это сделать, то вы рефакторите не четверть миллиона строк кода, а, возможно, всего 2500 (случайное предположение, я понятия не имею, насколько велик этот класс).

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

Answer 4

Если вы являются собираюсь пройти через это, не используйте Список< Т >.Вместо этого используйте System.Collections.ObjectModel.Коллекция< Т >, который является скорее духовным наследником CollectionBase.

А Collection<T> Класс предоставляет защищенные методы, которые можно использовать для настройки его поведения при добавлении и удалении элементов, очистке коллекции или установке значения существующего элемента.Если вы используете List<T> нет способа переопределить Add() метод для обработки, когда кто-то размещает рекламу в коллекции.

Answer 5

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

Если вы не потратите время на его очистку и улучшение кода, вы пожалеете об этом в долгосрочной перспективе, потому что вам придется поддерживать этот код в течение многих лет, иначе тот, кто возьмет на себя код, возненавидит вас.Вы сказали, что у вас есть модульные тесты, и вы должны иметь возможность доверять этим тестам, чтобы быть уверенными, что при рефакторинге кода он все равно будет работать.

Поэтому я говорю: сделайте это, наведите порядок, сделайте это красивым.Если вы не уверены, что ваши модульные тесты выдержат рефакторинг, напишите еще.

Answer 6

Я согласен с Томасом.

Я чувствую вопрос, который вы всегда должны задать себе, когда рефакторинг: «Что я получу, делая это, делая что -то еще со своим временем?» Ответ может быть много вещей, от увеличения обслуживания до лучшей производительности, но он всегда будет поступать за счет чего -то другого.

Не видя кода, мне трудно сказать, но это похоже на очень плохую ситуацию для рефакторинга.Тесты — это хорошо, но они не надежны.Достаточно одного из них сделать неверное предположение, и ваш рефакторинг может привести к неприятной ошибке.А без контроля качества, который мог бы это уловить, это было бы нехорошо.

Я также лично немного опасаюсь подобных масштабных рефакторингов.Однажды это стоило мне работы.Это была моя первая работа вне правительства (которая, как правило, немного более снисходительна, поскольку, как только вы получаете «штатную должность», вас чертовски трудно уволить), и я был единственным веб-программистом.Ко мне на колени упало старое приложение ASP, которое было плохо написано.Моей первоочередной задачей было переделать эту чертову штуку во что-то менее… противное.Мой работодатель хотел, чтобы пожары были потушены, и ничего больше.Через полгода я снова искал работу :p Мораль этой истории:Прежде чем приступать к этому, сначала проконсультируйтесь со своим менеджером.