Опишите проект с наибольшим количеством архитектурных или процессуальных проблем. Какие уроки были извлечены?

«Опишите проект с наибольшим количеством архитектурных или процессуальных проблем. Какие уроки были извлечены?» — вопрос из категории Софт-скиллы, который задают на 10% собеседований IOS Разработчик. Ниже — развёрнутый пример ответа, который можно адаптировать под свой опыт.

Ответ

Проектом с критическими проблемами было приложение для агрегации заказов еды, где преобладали антипаттерны и внешние риски.

Ключевые проблемы:

  1. Архитектурный коллапс:

    • Массивные ViewController'ы (Massive View Controller) в MVC, которые сочетали логику отображения, сетевые запросы и бизнес-правила.
    • Нарушение принципа единственной ответственности (SRP).
  2. Ненадежный бэкенд:

    • Частые 500-е ошибки без вменяемых сообщений.
    • Нестабильные и неподдерживаемые API-контракты.
  3. Процессные ошибки:

    • Нереалистичные дедлайны, приведшие к хардкоду бизнес-логики (например, расчет скидок).
    • Отсутствие модульного тестирования.

Пример проблемного кода (ViewController):

func fetchAndDisplayData() {
    // 1. Сетевая логика
    NetworkManager.shared.fetchOrders { [weak self] orders, error in
        DispatchQueue.main.async {
            if let orders = orders {
                self?.orders = orders
                // 2. Бизнес-логика (хардкод скидок!)
                self?.applyManualDiscounts(orders)
                // 3. Обновление UI
                self?.tableView.reloadData()
                // 4. Аналитика
                self?.trackEvent("orders_loaded")
                // 5. Обновление бейджа
                self?.updateTabBarBadge()
            } else {
                // Слабая обработка ошибок
                self?.showGenericAlert()
            }
        }
    }
}
// Функция `applyManualDiscounts` содержала захардкоженные правила,
// которые было невозможно изменить или протестировать отдельно.

Извлеченные уроки:

  • Архитектура: Переход на модульные паттерны (VIPER, Clean Architecture) для разделения ответственности и тестируемости.
  • Сетевое взаимодействие: Внедрение строгой модели ошибок, использование мок-серверов для разработки при нестабильном бэкенде.
  • Процесс: Настаивание на включении времени на рефакторинг и написание тестов в оценку задач. Умение аргументированно говорить "нет" решениям, которые создают технический долг.