С какими проектами не хотел бы работать?

Принципы выбора проектов для iOS-разработчика

Как Senior iOS Developer с 10+ лет опыта, я выработал чёткие критерии оценки проектов. Моё нежелание работать с определёнными типами продуктов основано не на капризах, а на профессиональных принципах, которые напрямую влияют на качество работы, личностный рост и конечную пользу для пользователей.

Категории проектов, которых я избегаю

1. Продукты с неэтичной фундаментальной механикой

Азартные игры и казино-приложения — мой абсолютный red flag. Даже если технически задачи интересны (высокие нагрузки, сложная анимация), я не могу участвовать в создании продуктов, которые:

• Эксплуатируют психологические зависимости
• Маскируют реальные финансовые риски под "развлечение"
• Часто используют тёмные паттерны в UI/UX

Пример проблемного кода, который я отказываюсь писать:

// Манипулятивные механики "почти выигрыша"
func presentNearWinAnimation() {
    // Специальная анимация, создающая ложное ощущение "было так близко"
    // Цель: спровоцировать повторную попытку
    UIView.animate(withDuration: 0.7, animations: {
        self.wheelView.transform = CGAffineTransform(rotationAngle: .pi * 0.98)
    }) { _ in
        self.showPopup("Попробуйте ещё раз! Вы были так близки!")
    }
}

2. Системы тотальной слежки и контроля

Отказываюсь от проектов, где основная функция — скрытый сбор данных или трекерское ПО:

• Приложения для "работодательского контроля" с скрытыми скриншотами экрана
• Шпионские программы под видом "родительского контроля"
• Системы, нарушающие GDPR и базовые права на приватность

3. Технически застойные проекты

Legacy-код без миграционных планов:

// Проекты, застрявшие в 2014 году
@interface LegacyViewController : UIViewController {
    IBOutlet UILabel *titleLabel; // Ручной аутлет - 0 авторесайза
    NSMutableArray *dataArray; // Без типизации
}

// Делегаты вместо блоков, ручная память
@property (nonatomic, retain) id<OldDelegate> delegate;

Проблемные признаки:

• Полное отсутствие Continuous Integration/Continuous Deployment
• UIKit без SwiftUI даже для новых экранов
• Objective-C без миграции на Swift
• Отсутствие unit-тестов и архитектурных принципов

4. "Фабричные" приложения и клонеры

Корпоративные и банковские клиенты с бесконечными формами и таблицами — не самая творческая задача, но имеет право на существование. Однако я принципиально не работаю над:

• Шаблонными конструкторами без уникальной ценности
• Быстрыми клонами популярных приложений
• Проектами, где дизайн и UX — вторичны

Принципиальные архитектурные антипаттерны

Massive View Controller как норма

Проекты, где следующий код считается приемлемым:

class GodViewController: UIViewController {
    // 2000+ строк: сетевые запросы, парсинг JSON,
    // валидация форм, работа с БД, бизнес-логика
    @IBOutlet weak var tableView: UITableView!
    var users: [User] = []
    var posts: [Post] = []
    var comments: [Comment] = [] // И всё в одном VC
    
    func loadData() {
        // 500 строк логики
    }
    
    // Делегаты таблицы, коллекции, текстовых полей...
}

Отсутствие слоистой архитектуры

Когда сетевой слой, логика представления и работу с БД невозможно выделить в отдельные модули:

• Нет четкого разделения на MVVM, VIPER или Clean Architecture
• Dependency Injection отсутствует как концепция
• Модульные тесты невозможны из-за связанности кода

Организационные красные флаги

1. Компании с токсичной культурой

• "Hero culture" — поощрение работы по 80 часов в неделю
• Отсутствие code review и pair programming
• Микроменеджмент в технических решениях

2. Полное отсутствие процессов

// Хаотичный процесс "разработки"
enum DevelopmentChaos {
    case noSpecifications
    case changingRequirementsDaily
    case testingInProduction
    case blameCulture
}

Что я ценю в проектах (для контраста)

Продукты с положительным impact:

• Приложения для образования и доступности (VoiceOver, динамический тип)
• Медицинские и wellness-решения с доказанной эффективностью
• Инструменты для творчества и профессионального роста

Технически зрелые проекты:

• Современный Swift с async/await
• Композиционная архитектура и модульность
• Пользовательский опыт как приоритет
• A/B тестирование и data-driven подход

Здоровые процессы:

• Прозрачное планирование (OKR, спринты)
• Технический долг как часть бэклога
• Непрерывное обучение и конференции

Профессиональная позиция

Мой отказ от определённых проектов — это не просто предпочтение, а осознанный выбор в пользу устойчивого развития. За 10+ лет я убедился: качество кода напрямую зависит от целей продукта и культуры команды.

Технический долг накапливается быстрее в проектах с сомнительной этикой — там часто экономят на архитектуре в погоне за быстрым выводом на рынок. Выгорание разработчика почти неизбежно в условиях постоянных "костылей" и "временных решений".

Я стремлюсь создавать iOS-приложения, которые:

1. Решают реальные проблемы пользователей
2. Соответствуют HIG (Human Interface Guidelines)
3. Используют современный стек технологий
4. Имеют потенциал для роста и улучшений

Мой стек технологий (SwiftUI, Combine, Swift Concurrency) наиболее эффективно раскрывается в продуктах, где инновации — это необходимость, а не опция. Поэтому я сознательно выбираю проекты, где могу применить весь свой опыт для создания действительно ценных digital-продуктов.