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

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

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

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

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

MVC (Apple-стандарт) - это то, с чего начинают все. Плюсы: минимум абстракций, всё лежит в контроллере, легко найти код. Минусы: контроллеры разрастаются до тысяч строк, логика смешивается с представлением, юнит-тесты писать сложно, потому что всё завязано на UIKit.

MVVM - следующий шаг. ViewModel не зависит от UIKit, что позволяет её тестировать. Плюсы: разделение ответственности, переиспользование логики, удобный binding через Combine или RxSwift. Минусы: нужно следить за утечками через замыкания, появляется дополнительный слой, который иногда дублирует логику, и при неаккуратном подходе ViewModel тоже может "распухнуть".

Координаторы - часто добавляю к MVVM для навигации. Плюсы: экраны не знают друг о друге, навигация централизована, легко менять flow. Минусы: дополнительная сущность, которую нужно поддерживать, и при простых приложениях это оверинжиниринг.

SwiftUI + TCA - современный подход. Плюсы: состояние - единственный источник правды, все изменения через actions, легко тестировать и дебажить, отличная поддержка SwiftUI. Минусы: кривая обучения, много boilerplate-кода, сложно мигрировать с UIKit, и для маленьких фич это избыточно.

Clean Architecture / VIPER - пробовал, но считаю избыточным для большинства iOS-проектов. Плюсы: полная изоляция слоёв. Минусы: огромное количество файлов на один экран, сложность поддержки и низкая скорость разработки.

На практике

В реальных проектах я обычно выбираю так:

• Для MVP или прототипа - MVC, чтобы быстро получить результат.
• Для продуктового приложения с командой 3-5 человек - MVVM + Coordinator + Combine.
• Для большого проекта с долгосрочной поддержкой и строгими требованиями к тестированию - TCA, но только если вся команда готова к этому.

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

Пример кода

Покажу разницу на простом примере загрузки данных.

MVC:

SWIFT
final class UserViewController: UIViewController {
    private let api = APIClient()
    private var users: [User] = []

    override func viewDidLoad() {
        super.viewDidLoad()
        api.fetchUsers { [weak self] result in
            switch result {
            case .success(let users):
                self?.users = users
                self?.tableView.reloadData()
            case .failure(let error):
                self?.showError(error)
            }
        }
    }
}

MVVM:

SWIFT
final class UserViewModel {
    @Published var users: [User] = []
    @Published var errorMessage: String?

    private let api: APIClient

    init(api: APIClient) {
        self.api = api
    }

    func loadUsers() {
        api.fetchUsers { [weak self] result in
            switch result {
            case .success(let users):
                self?.users = users
            case .failure(let error):
                self?.errorMessage = error.localizedDescription
            }
        }
    }
}

final class UserViewController: UIViewController {
    private let viewModel: UserViewModel
    private var cancellables = Set<AnyCancellable>()

    init(viewModel: UserViewModel) {
        self.viewModel = viewModel
        super.init(nibName: nil, bundle: nil)
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        viewModel.$users
            .receive(on: DispatchQueue.main)
            .sink { [weak self] _ in self?.tableView.reloadData() }
            .store(in: &cancellables)
        viewModel.loadUsers()
    }
}

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

Начните с краткого перечисления того, что вы использовали, затем выберите одну-две архитектуры и разберите их подробно. Обязательно приведите конкретный пример из практики: какую проблему решали и почему выбрали именно этот подход. Покажите, что вы понимаете trade-off, а не просто знаете определения. Если спросят про "идеальную" архитектуру - отвечайте, что идеальной нет, и выбор зависит от контекста.

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

Интервьюер оценивает:

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

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

• Хвалить одну архитектуру и полностью отрицать другие - это показывает отсутствие гибкости.
• Говорить "везде использую MVVM" без объяснения, почему и какие минусы вы видите.
• Путать архитектуру с паттернами проектирования (например, называть Coordinator архитектурой).
• Не упоминать проблемы с памятью и тестируемостью - это ключевые критерии для senior.
• Приводить только теорию без примеров из реальных проектов.