Чем не хотел бы заниматься?

Отвечая на вопрос о нежелательной деятельности в iOS-разработке

Как опытный iOS-разработчик, я глубоко осознаю, что в профессии есть области, которые лично мне неинтересны или менее эффективны с точки зрения профессионального роста и вклада в продукт. Это не означает, что я отказываюсь от задач, важных для проекта — просто я стремлюсь фокусироваться на работе, где мои навыки приносят максимальную пользу.

Области, которыми я бы не хотел заниматься на постоянной основе

1. Долгосрочная работа с унаследованным кодом без стратегии модернизации Работа с Legacy-кодом — это неизбежная часть разработки, и я умею с ним работать, анализировать и исправлять баги. Однако я не хотел бы годами поддерживать огромную монолитную кодовую базу, написанную 5-7 лет назад на Objective-C или ранних версиях Swift без архитектурных паттернов, если при этом нет четкого плана по рефакторингу, модуляризации или постепенной замене. Это похоже на «латание дыр», а не на развитие продукта.

// Пример кода, который сложно поддерживать и который требует рефакторинга
class GodViewController: UIViewController {
    // 2000+ строк кода, совмещающих логику, UI, сетевые запросы и работу с БД
    var data: [Any] = []
    @IBOutlet var tableView: UITableView!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        loadDataFromUserDefaults()
        setupTableView()
        fetchDataFromOldAPI()
        // ... множество несвязанных ответственностей
    }
}

2. Исключительно верстать сложные UI без создания дизайн-систем Рисовать интерфейсы в коде или Interface Builder — важный навык, но если задача сводится только к механической верстке по макетам без возможности участвовать в создании переиспользуемых компонентов, UI-Kit или SwiftUI библиотек для команды, это становится рутиной. Я верю, что разработчик должен влиять на дизайн-систему для повышения эффективности всей команды.

3. Писать однотипные CRUD-приложения без глубокой предметной области Создавать приложения, которые просто отображают данные из REST API в UITableView/UICollectionView без сложной бизнес-логики, оптимизации производительности, работы с оффлайн-режимом (Core Data/Realm) или кастомной анимации — быстро приводит к профессиональному выгоранию. Мне интересны задачи, требующие глубокого погружения: машинное обучение на устройстве (Core ML), работа с AR (ARKit), интеграция с hardware через Core Bluetooth, или высоконагруженные приложения с требованиями к минимальному потреблению батареи.

4. Работа в среде без процессов code review и автоматизации Я не хотел бы работать в команде, где нет code review, CI/CD (непрерывная интеграция и доставка) или тестирования. Это критично для качества кода и продукта. Например, отсутствие unit-тестов на бизнес-логику или UI-тестов для ключевых сценариев ведет к хрупкости приложения.

// Пример важности unit-тестов для бизнес-логики
class PaymentValidator {
    func validate(amount: Double, currency: String) -> Bool {
        // Сложная логика валидации
        return amount > 0 && currency.count == 3
    }
}

// Тест, который должен быть в проекте
import XCTest
class PaymentValidatorTests: XCTestCase {
    func testValidation_Success() {
        let validator = PaymentValidator()
        XCTAssertTrue(validator.validate(amount: 100.0, currency: "USD"))
    }
}

5. Постоянные «пожарные» задачи и хаотичный менеджмент Хотя срочные исправления критических багов — это часть работы, я бы не хотел находиться в режиме постоянного тушения пожаров из-за плохого планирования, отсутствия технического долга в бэклоге или нереалистичных сроков. Это ведет к низкому качеству кода и демотивации.

Что для меня важно вместо этого

Я стремлюсь к работе, где я могу:

• Проектировать архитектуру приложения (VIPER, Clean Architecture, MVVM).
• Участвовать в техническом планировании и оценке задач.
• Оптимизировать производительность (инструменты: Instruments, XCTest).
• Внедрять новые технологии (Swift Concurrency, SwiftUI, Combine).
• Наставлять менторов и делиться знаниями в команде.

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