Какие признаки указывают на плохую структуру view controller?

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

1) Слишком много ответственности в одном месте

Перед тем как смотреть на размер файла, стоит оценить, что именно делает контроллер.

Типичные «лишние обязанности»:

1. Сеть внутри контроллера

   • URLSession/клиент API вызывается прямо из UIViewController.

   • обработка ошибок и ретраи тоже внутри.

2. Бизнес-логика

   • правила доступа, валидации, расчеты, фильтрация, сортировка.

3. Навигация

   • контроллер сам решает, куда и как переходить, собирает зависимости следующего экрана.

4. Работа с хранилищем

   • чтение/запись в Core Data/Realm прямо в UI-слое.

Почему это плохо:

• контроллер становится точкой, где смешаны разные причины изменений;

• любое изменение требований «цепляет» UI.

2) “Симптомы” в коде, которые видно сразу

Длинные методы и вложенность

Частые маркеры:

1. методы на 50–200 строк;

2. сильная вложенность if/guard/switch;

3. обработка нескольких сценариев в одной функции.

Что это обычно означает:

• отсутствует декомпозиция по сущностям и сценариям;

• логика не оформлена отдельными объектами.

Дублирование логики

Признаки:

1. одинаковые куски кода в viewDidLoad, viewWillAppear, обработчиках кнопок;

2. похожая обработка ошибок в нескольких местах.

Риск:

• исправление в одном месте не исправляет в другом;

• быстро растет количество регрессий.

3) Сложная и хрупкая работа с состоянием

Контроллеры часто «ломаются», когда состояние экрана не описано явно.

Признаки:

1. много флагов: isLoading, isRefreshing, isFirstLoad, shouldShowEmptyState;

2. несогласованные переходы между состояниями;

3. UI обновляется точечно в разных местах (часто без единого центра управления).

Что помогает:

• ввести единый state (например, loading/content/empty/error) и один метод рендера.

Пример идеи (коротко):

enum ScreenState {
    case loading
    case content([Item])
    case empty
    case error(String)
}

4) Проблемы с зависимостями и тестируемостью

Перед тем как думать о тестах, посмотри на то, как создаются зависимости.

Признаки:

1. let api = ApiClient() внутри контроллера;

2. одиночки и глобальные менеджеры повсюду;

3. контроллер нельзя создать в тесте без реального окружения.

Последствия:

• сложно писать unit-тесты;

• сложно изолировать баги;

• невозможна замена реализаций.

5) Ошибки с асинхронностью и жизненным циклом

Плохая структура часто проявляется в неуправляемых асинхронных вызовах.

Признаки:

1. много nested completion handlers;

2. нет отмены при уходе с экрана;

3. UI обновляется после dismiss/pop, из-за чего возможны крэши;

4. отсутствие [weak self] и утечки памяти.

Что обычно делают:

• выносят асинхронность в слой ViewModel/Presenter;

• добавляют отмену и привязку к жизненному циклу.

Практический вывод

Плохая структура view controller — это не «большой файл», а смешение обязанностей, неявное состояние и тяжелые зависимости. Если контроллер сложно тестировать, менять и читать — его нужно декомпозировать: вынести бизнес-логику, навигацию, работу с данными и привести управление состояниями к единой модели.