Какие задачи ты не хочешь выполнять?

Задачи, которые я стараюсь избегать как iOS Developer

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

1. Работа с устаревшими технологиями без плана модернизации

Я не хочу заниматься поддержкой легаси-кода, написанного на Objective-C или ранних версиях Swift без архитектурных принципов, если нет четкой дорожной карты по рефакторингу. Пример проблемного кода:

// Антипаттерн: массивный ViewController без разделения ответственностей
class LegacyViewController: UIViewController {
    var data: [String] = []
    var networkService = NetworkService()
    var database = Database()
    var formatter = Formatter()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        loadData()
        setupUI()
        configureGestures()
        setupNotifications()
        // 1000+ строк кода далее...
    }
    
    func loadData() {
        networkService.fetch { [weak self] result in
            self?.data = result
            self?.database.save(result)
            self?.tableView.reloadData()
            self?.updateHeader()
            self?.sendAnalytics()
        }
    }
}

Поддержка такого кода без возможности рефакторинга ведет к техническому долгу, снижает скорость разработки и увеличивает количество багов.

2. Неконструктивный ручной труд вместо автоматизации

• Ручное тестирование однотипных сценариев вместо написания автотестов
• Ручная сборка и деплой без CI/CD конвейера
• Копипаст кода между проектами вместо создания shared-библиотек

3. Задачи без четких требований и критериев завершения

Я избегаю ситуаций, когда:

• Дизайн предоставлен в виде скриншотов без размеров, отступов и состояний элементов
• Бизнес-логика описана расплывчато ("сделайте как в том приложении")
• Нет Definition of Done (DoD) для задачи
• Постоянно меняются требования в процессе разработки без корректировки сроков

4. Изоляция от процессов планирования и проектирования

Как senior-разработчик, я считаю неэффективным:

• Получать готовые технические решения без возможности внести экспертизу
• Работать над фичами без понимания бизнес-контекста
• Не участвовать в оценке сложности и рисков

5. Неоптимальные процессы code review

Я не хочу участвовать в ревью, где:

• Комментарии носят субъективный характер ("мне не нравится")
• Критика не конструктивна и не предлагает альтернатив
• Отсутствуют четкие code style guidelines
• Происходят бесконечные дискуссии о форматировании вместо сути кода

6. Работа с "костылями" вместо правильных решений

Иногда бизнес требует быстрых, но грязных решений:

// Временный "костыль", который становится постоянным
func temporaryFixForCrash() {
    // Вместо исправления race condition добавляем sleep
    Thread.sleep(forTimeInterval: 0.1)
    performCriticalOperation()
    
    // Игнорирование всех ошибок вместо обработки
    try? database.save()
}

Я готов временно идти на компромиссы, но только если есть план по устранению технического долга.

7. Задачи, не соответствующие уровню expertise

На моем уровне неэффективно тратить время на:

• Верстку простых экранов без сложной логики (это лучше делать junior/middle)
• Исправление опечаток в текстах (это задача PM/тестировщиков)
• Монотонную интеграцию SDK без кастомизации

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

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

1. Она оправдана с точки зрения бизнес-ценности
2. Существует план по улучшению проблемных мест
3. Задача соответствует моему уровню экспертизы и приносит реальную пользу проекту
4. Процессы организованы прозрачно и предсказуемо

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