> Почему не использовали Clean Swift (iOS, Swift)

Короткий ответ

Clean Swift (VIP) - это архитектура с жёсткой однонаправленной передачей данных через interactor, presenter и view controller. Мы не использовали её, потому что для нашего проекта она избыточна: добавляет много шаблонного кода, требует строгой дисциплины в нейминге и структуре, а также замедляет разработку на небольших фичах. Вместо этого выбрали более гибкий подход - например, MVVM с координаторами или простой VIPER без жёстких ограничений, что позволило быстрее итерировать и проще поддерживать код.

Подробное объяснение

Clean Swift - это конкретная реализация VIP-цикла, предложенная Raymond Wenderlich. Она строго разделяет ответственности, но ценой этого становится:

• большое количество файлов на каждую фичу (view controller, interactor, presenter, models, router, worker);
• необходимость писать протоколы для каждого взаимодействия, что увеличивает объём кода;
• жёсткая последовательность вызовов, которая усложняет внесение изменений в логику, если требования меняются часто.

В нашем проекте основными требованиями были скорость разработки, простота поддержки и возможность быстро подключать новых разработчиков. Clean Swift создаёт высокий порог входа из-за своей церемониальности. Кроме того, для экранов с простой логикой (списки, формы) VIP-цикл добавляет лишние слои без реальной выгоды.

Мы выбрали MVVM с bindings (через Combine или RxSwift) и координаторы для навигации. Это дало:

• меньше файлов на экран;
• декларативную связь view и view model;
• гибкость в обработке состояний (loading, error, data);
• лёгкое тестирование бизнес-логики без необходимости мокать весь VIP-цикл.

Также Clean Swift плохо сочетается с SwiftUI, где уже есть встроенный механизм state-driven UI. Если бы проект был на UIKit и требовал строгой тестируемости каждого шага, мы бы рассмотрели Clean Swift, но в нашем случае trade-off был не в его пользу.

На практике

В реальной работе мы используем MVVM + Coordinator. Например, экран списка товаров:

• view controller отвечает только за отображение и события от UI;
• view model содержит состояние и бизнес-логику (загрузка, фильтрация);
• координатор управляет навигацией и передачей данных между экранами.

Это позволяет:

• переиспользовать view model в разных view (например, для iPad и iPhone);
• легко писать unit-тесты на view model без UI;
• добавлять новые экраны без изменения существующих слоёв.

Если бы мы взяли Clean Swift, то для каждого экрана пришлось бы создавать минимум 5-6 файлов, и даже простая форма логина превратилась бы в простыню кода. Для нашего темпа это было бы критично.

Как отвечать на собеседовании

Начните с того, что Clean Swift - это не плохо, а просто не подходит под конкретные условия. Опишите, какие требования были у проекта (скорость, размер команды, тип UI). Затем объясните, что вы выбрали вместо этого и почему. Важно показать, что вы понимаете trade-off: Clean Swift даёт строгую тестируемость и предсказуемость, но за счёт объёма кода и сложности изменений. Если интервьюер настаивает, приведите конкретный пример, где Clean Swift был бы оправдан (например, сложный модуль с множеством состояний и строгими требованиями к тестированию).

Что проверяет интервьюер

Интервьюер хочет понять:

• знаете ли вы Clean Swift и его отличия от других архитектур;
• умеете ли вы обосновывать выбор архитектуры, а не просто следовать моде;
• понимаете ли вы trade-off между строгостью и гибкостью;
• можете ли вы адаптировать архитектуру под реальные задачи проекта.

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

Типичные ошибки

• Говорить "Clean Swift - это плохо" без аргументов.
• Путать Clean Swift с VIPER или чистым Swift (язык).
• Утверждать, что Clean Swift не тестируется - это не так, он тестируется хорошо, но дорого.
• Не упоминать альтернативы, которые вы реально использовали.
• Сводить ответ к "нам так сказали" - нужно показать своё участие в решении.