Расскажи про свой худший проект

Разбор "худшего" проекта в карьере iOS-разработчика

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

Архитектурные проблемы

Изначально проект задумывался с применением MVC, но быстро превратился в Massive View Controller.

// Пример того, во что выродился главный контроллер
class DocumentFlowViewController: UIViewController {
    // 2000+ строк кода
    var networkManager: NetworkManager!
    var databaseManager: DatabaseManager!
    var fileProcessor: FileProcessor!
    var stateManager: StateManager!
    var analyticsTracker: AnalyticsTracker!
    // 10+ других зависимостей
    
    override func viewDidLoad() {
        super.viewDidLoad()
        configureUI()
        loadInitialData()
        setupObservers()
        validateUserSession()
        prefetchRelatedDocuments()
        // ... еще 15 вызовов методов
    }
    
    // 50+ private методов, многие > 100 строк
    private func processDocumentUpdate(_ update: DocumentUpdate) {
        // Смесь логики обновления UI, сохранения в БД, отправки на сервер
        // и обработки ошибок в одном методе
    }
}

Ключевые проблемы архитектуры:

• Полное отсутствие разделения ответственности
• Прямые вызовы Core Data из ViewController'ов
• Жесткие зависимости между модулями
• Отсутствие unit-тестов (невозможно тестировать из-за сильной связности)

Процессуальные ошибки

Управленческие решения усугубили технические проблемы:

1. Отсутствие технического лида — проектом руководил менеджер без технического бэкграунда
2. Постоянные изменения требований в процессе разработки без корректировки сроков
3. Давление на скорость в ущерб качеству: "Сначала выпустим, потом исправим"
4. Отказ от рефакторинга — любое предложение улучшить код воспринималось как саботаж сроков

Технический долг

К концу первого года разработки технический долг достиг критических масштабов:

// Типичный пример "временного решения", ставшего постоянным
func loadDocuments() {
    DispatchQueue.global().async {
        let documents = self.database.fetchAllDocuments()
        
        // Проблема 1: Обновление UI не в главном потоке
        self.tableView.reloadData()
        
        // Проблема 2: Скрытая бизнес-логика
        if documents.count > 100 {
            self.showPerformanceWarning() // Вызывалось каждый раз!
        }
        
        // Проблема 3: Размазанная логика сохранения
        DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) {
            self.syncWithBackend() // Магическая задержка "для надежности"
        }
    }
}

Последствия технического долга:

• Время компиляции выросло до 8-10 минут
• Частые креши из-за race conditions
• Невозможность добавить новые функции без поломки существующих
• Высокий turnover разработчиков в команде

Что пошло не так с человеческой точки зрения

1. Синдром "здесь не изобретаем" — команда боялась предлагать улучшения
2. Культура обвинений — вместо поиска корневых причин багов искали виноватого
3. Изоляция команды — разработчиков не допускали к общению с конечными пользователями
4. Отсутствие code review как процесса — формальное "посмотрел" без конструктивной критики

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

Этот проект стал поворотным моментом в моей карьере. Я понял, что техническое качество не менее важно, чем функциональность:

1. Архитектурные паттерны (VIPER, Clean Architecture) существуют не для "красивости", а для поддержания
2. Процессы важны не меньше кода — внедрили обязательный code review, технические ретроспективы
3. Технический долг нужно измерять и контролировать — ввели метрики (complexity, coverage, compile time)
4. Говорить "нет" — это профессионально — научился аргументированно отказываться от решений, ухудшающих кодобазу

Как мы выправляли ситуацию

Постепенно, через постепенный рефакторинг и изменение процессов:

// Пример инкрементального улучшения
protocol DocumentLoading {
    func loadDocuments() async throws -> [Document]
}

class DocumentLoader: DocumentLoading {
    private let repository: DocumentRepository
    private let performanceMonitor: PerformanceMonitor
    
    func loadDocuments() async throws -> [Document] {
        async let local = repository.loadLocalDocuments()
        async let remote = repository.loadRemoteDocuments()
        
        let documents = try await mergeDocuments(local: local, remote: remote)
        
        if documents.count > configuration.warningThreshold {
            performanceMonitor.logWarning(.largeDataset)
        }
        
        return documents
    }
}

Итог: Через 2.5 года проект был практически переписан, но с сохранением бизнес-логики. Главный вывод — "худший" проект дал мне больше, чем успешные, научив ценить чистую архитектуру, процессы и здоровую культуру в команде. Теперь я рассматриваю подобные ситуации не как провалы, а как инвестиции в профессиональный рост.