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

Question

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

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

Answer 1

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

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

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

Answer 2

Если вы собираетесь пройти через это, не используйте List . Вместо этого используйте System.Collections.ObjectModel. Collection , что является скорее духовным наследником CollectionBase.

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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

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