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

Question

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

Мандат истек. Нам нужно провести рефакторинг класса монстров. Самая большая часть плана состоит в том, чтобы определить категории функциональности в их собственных классах с отношениями «имеет-связь» с классом монстров.

Это означает, что многие ссылки, которые в настоящее время читаются так:

var monster = new orMonster();
var timeToOpen = monster.OpeningTime.Subtract(DateTime.Now);

скоро будет читать так:

var monster = new Monster();
var timeToOpen = monster.TimeKeeper.OpeningTime.Subtract(DateTime.Now);

Вопрос в том, как на Земле мы координируем такое изменение? Ссылки на «orMonster» замусоривают каждый бизнес-класс. Некоторые методы вызываются буквально тысячами мест в коде. Гарантируется, что в любой момент, когда у нас будет такая возможность, кто-то еще (возможно, несколько человек) в команде получит проверенный код, который вызывает свойство .OpeningTime

Как вы координируете такое крупномасштабное изменение без остановки производительности?

Answer 1

Не рефакторинг.

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

И вместо этого: "monster.TimeKeeper.OpeningTime.Subtract (DateTime.Now)"

Сделайте это: monster.SubtractOpeningTime (DateTime.Now). Не убивайте себя точечной нотацией (отсюда и деметра)

Answer 2

Такой огромный класс действительно проблема. Поскольку он стал таким большим, и никто не чувствовал себя неловко, должно быть что-то не так с политикой проекта. Я бы сказал, что вы должны разбиться на пары и заняться парным программированием. Создайте ветку для каждой пары программистов. Работаем 1-2 дня на рефакторинге. Сравните свои результаты. Это поможет вам избежать ситуации, когда рефакторинг с самого начала будет идти в неправильном направлении, и, наконец, это приведет к необходимости переписать класс монстров с нуля.