> На каких архитектурах писали и какие плюсы и минусы вы видите (iOS, Swift)

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

За свою карьеру я писал под чисто MVC, затем MVP, MVVM и последние несколько лет - на SwiftUI с архитектурой, близкой к TCA (The Composable Architecture) или собственной модульной на основе координаторов. Плюсы: чёткое разделение ответственности, тестируемость, предсказуемость. Минусы: рост сложности при увеличении команды, переусложнение для простых экранов, необходимость строгой дисциплины в команде.

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

Начну с того, что выбор архитектуры - это всегда trade-off между простотой, скоростью разработки и долгосрочной поддерживаемостью. Я прошёл путь от классического MVC в UIKit до современных подходов.

MVC (UIKit): плюсы - минимальный порог входа, все знакомы, быстро прототипировать. Минусы - Massive View Controller, сложно тестировать логику, которая зашита во вью-контроллере, проблемы с переиспользованием.

MVP: плюсы - презентер легко юнит-тестируется, вью становится пассивной. Минусы - много бойлерплейта, ручная связка вью и презентера, рост числа файлов.

MVVM с координаторами: плюсы - реактивное связывание (Combine/RxSwift), вью-модель не зависит от UIKit, координаторы решают навигацию. Минусы - сложность отладки реактивных цепочек, риск "реактивного ада" при неаккуратном использовании, сложнее онбординг новичков.

TCA и модульная архитектура: плюсы - однонаправленный поток данных, предсказуемость, отличная тестируемость (редьюсеры чистые), явная работа с side effects. Минусы - много церемоний для простых фич, steep learning curve, иногда избыточность для маленьких приложений.

Ключевой плюс любой архитектуры - это не сам паттерн, а то, насколько он помогает команде двигаться быстро и не ломать существующий код. Минус - когда архитектуру выбирают "по моде", а не под задачи продукта.

На практике

В последнем проекте мы использовали MVVM + Coordinator + Combine. На практике это выглядело так: каждый экран - это модуль с вью-моделью, которая получает данные из сервисов, и координатор, который отвечает за переходы. Мы ввели правило: вью-модель не знает о навигации, а координатор не знает о бизнес-логике.

Из практических плюсов: мы могли параллельно разрабатывать экраны, тестировать вью-модели без UI, быстро менять flow навигации. Из минусов: когда фича была "на один экран", мы всё равно создавали три-четыре файла, и это замедляло разработку. Мы решили это правилом: для простых экранов разрешён упрощённый вариант без координатора, но с обязательной вью-моделью.

Ещё важный момент - работа с legacy. Когда мы переходили с MVC, мы не переписывали всё сразу, а выделяли "архитектурные острова" - новые фичи писали на MVVM, старые постепенно мигрировали. Это снижало риски и позволяло команде адаптироваться.

Пример кода

Покажу, как выглядит типичный модуль на MVVM + Combine:

SWIFT
final class ProfileViewModel: ObservableObject {
    @Published var user: User?
    @Published var isLoading = false
    
    private let userService: UserServiceProtocol
    private var cancellables = Set<AnyCancellable>()
    
    init(userService: UserServiceProtocol) {
        self.userService = userService
    }
    
    func loadUser() {
        isLoading = true
        userService.fetchUser()
            .sink { [weak self] completion in
                self?.isLoading = false
            } receiveValue: { [weak self] user in
                self?.user = user
            }
            .store(in: &cancellables)
    }
}

final class ProfileCoordinator: Coordinator {
    private let navigationController: UINavigationController
    
    init(navigationController: UINavigationController) {
        self.navigationController = navigationController
    }
    
    func start() {
        let viewModel = ProfileViewModel(userService: UserService())
        let viewController = ProfileViewController(viewModel: viewModel)
        navigationController.pushViewController(viewController, animated: true)
    }
}

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

Начните с краткого перечисления архитектур, с которыми работали, и сразу переходите к конкретике: что именно вы делали, какие проблемы решали. Не перечисляйте плюсы и минусы абстрактно - привязывайте к реальным проектам. Например: "В проекте X мы выбрали MVVM, потому что была большая команда и нужно было параллелить разработку, но столкнулись с тем, что...".

Покажите, что вы понимаете trade-off: не говорите "MVVM лучше всех", а объясните, в каких случаях он оправдан, а в каких - нет. Упомяните, как вы адаптируете архитектуру под масштаб задачи. Если спрашивают про TCA - будьте готовы объяснить, почему она удобна для тестирования и какие у неё ограничения.

Завершите выводом: архитектура - это инструмент, а не самоцель, и главное - чтобы команда могла быстро и безопасно развивать продукт.

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

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

Также проверяется способность к критическому мышлению: если вы говорите "TCA - это круто", но не можете назвать её недостатки, это красный флаг. Хороший ответ - когда вы показываете, что пробовали, ошибались и делали выводы.

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

Первая ошибка - отвечать абстрактно, без привязки к проектам: "MVVM хорош тем, что разделяет ответственность". Это звучит как заученный текст. Вторая - хвалить одну архитектуру и поливать грязью другие, не признавая контекст. Третья - не упоминать минусы: если вы говорите только о плюсах, интервьюер решит, что вы не сталкивались с реальными проблемами. Четвёртая - путать архитектуру с паттернами проектирования: например, называть Coordinator архитектурой, хотя это паттерн навигации. Пятая - игнорировать вопрос про масштабирование: если вы не говорите, как архитектура ведёт себя при росте команды и кодовой базы, это заметный пробел.