Как восстановить из старого материала в большой системе шаг за шагом?

Question

Наша команда получила устаревшую систему для дальнейшего обслуживания и развития. Поскольку это настоящий «унаследованный» материал, действительно существует действительно небольшое количество тестов, и большинство из них - дерьмо. Это приложение с веб-интерфейсом, поэтому есть и управляемые контейнером компоненты, а также простые классы Java (не привязанные к какой-либо структуре и т. Д.), Которые являются «новыми» здесь и там, когда захотите.

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

Мой вопрос заключается в том, как работать с такой системой, нарушать dependecies, делать код более проверяемым и т. Д.? Когда останавливаться и как бороться с этим?

Позвольте мне показать вам пример:

public class BillingSettingsAction { 

    private TelSystemConfigurator configurator; 
    private OperatorIdDao dao; 

    public BillingSettingsAction(String zoneId) { 
     configurator = TelSystemConfiguratorFactory.instance().getConfigurator(zoneId); 
     dao = IdDaoFactory.getDao(); 
     ... 
    } 

    // methods using configurator and dao 
} 

Этот конструктор, безусловно, делает слишком много. Кроме того, чтобы проверить это для дальнейшего рефакторинга это требует делать магию PowerMock и т.д. То, что я хотел бы сделать, чтобы изменить его на:

public BillingSettingsAction(String zone, TelSystemConfigurator configurator, OperatorIdDao dao) { 
    this.configurator = configurator; 
    this.dao = dao; 
    this.zone = zone; 
} 

или обеспечивают зону настройки конструктора только сеттеры для зависимостей.

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

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

Итак, мой вопрос в том, как с этим вы справляетесь? Как сделать зависимости между объектами лучше, более читабельными, проверяемыми, не делая этого за один раз?

Answer 1

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

Для того, чтобы поддержать, что вы можете

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

• Показаны показатели, показывающие улучшение с течением времени. Часто достаточно простых вещей, таких как средний размер файла и покрытие теста.

• Имейте список вещей, которые вы хотите изменить, по крайней мере, для более крупного материала, например, «Избавьтесь от TelSystemConfiguratorFactory», на котором вы уже работаете, и предпочитаете работая над вещами, которые уже начались над новыми вещами.

В любом случае убедитесь, что руководство соглашается с вашим подходом.

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

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

Answer 2

Я только недавно начал читать «Эффективно работаю с устаревшим кодом» Майкла Перса. Книга в основном является ответом на ваш вопрос. Он представляет собой очень эффективные «самородки» и методы для постепенного внедрения тестируемой устаревшей системы и постепенного улучшения базы кода.

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

Я не являюсь аффилированным лицом к автору или что-то в этом роде, просто я столкнулся с подобными ситуациями и нашел это очень интересным ресурсом.

HTH