С чем бы не хотел работать

Отличный вопрос, который позволяет раскрыть не только технические предпочтения, но и зрелость, понимание процесса разработки. Мой ответ будет основан на 10+ годах опыта в коммерческой разработке под Android.

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

Я выделю несколько ключевых сфер, работа с которыми в их "токсичной" форме вызывает наибольшее сопротивление.

1. С Legacy-кодом без возможности рефакторинга

Сам по себе legacy-код — это нормально и даже интересно, это вызов. Однако я категорически не хотел бы работать с ним при следующих условиях:

• Полный запрет на рефакторинг и улучшение архитектуры. Когда девиз «работает — не трогай» доведен до абсурда, и любая попытка улучшить монолит на AsyncTask, пронизанный God-Object-ами, встречается в штыки.
• Отсутствие тестов. Постоянное внесение изменений в огромную, запутанную codebase без единого unit- или интеграционного теста — это игра в русскую рулетку с каждым коммитом. Невозможно быть уверенным, что твое исправление в Activity не сломает логику в трех других Fragment.

// Пример "антипаттерна", с которым тяжело работать без рефакторинга:
class MainActivity : Activity() {
    // Публичные поля, доступные из любого места
    public static TextView textView;
    public static ArrayList<Data> allData = ArrayList()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        textView = findViewById(R.id.text)
        // Долгая операция в UI-потоке
        allData = loadAllDataFromNetworkSync()
        updateViews()
        saveToDatabase()
        // ...
    }
}

Работать с таким кодом, лишь латая симптомы и добавляя новые if-ы в методы на 500 строк, — путь к профессиональному выгоранию.

2. С неадекватными процессами и менеджментом

Технологии вторичны, если процессы разрушительны.

• Постоянный «авральный режим» и moving deadlines. Когда срыв сроков по причине плохого планирования становится нормой, а не исключением. Это прямой путь к техдолгу и низкому качеству.
• Микроменеджмент. Ежедневный детальный контроль каждой строки кода или каждой задачи лишает мотивации и убивает экспертизу. Я верю в принцип «Соглашение о целях и доверие».
• Отсутствие понятного Product Discovery. Когда задачи спускаются «сверху» без контекста, обсуждения ценности для пользователя и технических возможностей. Просто «делай, как нарисовано».

3. С устаревшими и опасными практиками, возведенными в догму

• Ручное тестирование всего и всегда. Нежелание внедрять автоматизацию UI-тестов (Espresso), CI/CD, считая это «лишними тратами». В современном мире приложений с десятками экранов и тысячью сценариев это неприемлемо.
• Игнорирование безопасности. Хранение ключей API в коде, передача чувствительных данных в Intent или SharedPreferences без шифрования, использование HttpURLConnection вместо HttpsURLConnection без требований.
• «Not Invented Here» (NIH) синдром. Своя реализация ImageLoader-а, когда есть проверенная Glide/Coir, своя навигация вместо Jetpack Navigation. Это пустая трата времени и источник будущих багов.

4. С конкретными технологиями, чей выбор неоправдан

Здесь речь не о страхе перед новым, а о нежелании использовать инструменты не по назначению или уже откровенно устаревшие.

• Кросс-платформенные фреймворки (Flutter, React Native) для высоконагруженных, нативных по ощущениям Android-приложений. Если бизнес-задача — максимальная производительность, глубокая интеграция с платформой и долгосрочная поддержка большого нативного проекта, выбор кроссплатформы может стать главной головной болью.
• Устаревшие архитектурные подходы. Насильственное применение MVC (Model-View-Controller) для Android, где роль «Controller» размывается между Activity и Fragment, или использование MVP (Model-View-Presenter) в чистом виде без внедрения зависимостей, что приводит к гигантским презентерам.
• Неподходящие инструменты для хранения данных. Например, использование SharedPreferences для хранения сложных relational-данных или отказ от Room в пользу прямой работы с SQLiteOpenHelper без веских причин (например, legacy).

Заключение

В конечном счете, я не хотел бы работать в среде, которая не ценит инженерную культуру. Разработка — это не только написание кода, который «работает». Это создание поддерживаемой, тестируемой, безопасной и масштабируемой системы. Если компания или команда видят в разработчиках просто «исполнителей задач», игнорируют технический долг, не дают времени на изучение нового (такого же Compose) и не прислушиваются к экспертизе — это верный признак того, что работа будет приносить больше стресса, чем удовлетворения.

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