С какими проектами не хочешь работать

Мой подход к выбору проектов

С 10+ годами опыта в Android-разработке я выработал четкие критерии для проектов, где я могу принести максимальную пользу. Я стремлюсь к работе, которая позволяет создавать качественный продукт с продуманной архитектурой, а не просто «закрывать таски».

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

1. Проекты с хаотичным процессом разработки

Я избегаю команд, где полностью отсутствует продуктовая стратегия и техническое видение. Речь о ситуациях, когда:

• Требования меняются ежедневно без анализа последствий и приоритизации.
• Полное отсутствие процесса Code Review или игнорирование его правил.
• Постоянный аврал и работа «на вчера» как стандартный режим работы, а не исключение.
• Отсутствие даже базовых инструментов: системы контроля версий (Git), CI/CD, трекера задач.

Такая среда не позволяет создавать стабильные и поддерживаемые приложения, что противоречит принципам качественной инженерии.

2. Проекты с тотальным пренебрежением к качеству кода

Мне сложно работать в условиях, где под лозунгом «быстрее выпустить фичу» на постоянной основе жертвуют фундаментальными вещами:

• Отказ от модульности и чистых архитектурных принципов (Clean Architecture, MVVM, MVI) в пользу одного «God-объекта» (Massive ViewModel или Activity).
• Копирование бизнес-логики в UI-слой, что делает код непроверяемым.

// Пример антипаттерна, которого хочется избегать:
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Вся логика, работа с БД, сетевые вызовы прямо в Activity - путь к большим проблемам
        val user = db.getUser() // Прямой доступ к БД
        if (user.isPremium) {
            makeApiCall(user) // Сетевой вызов в UI-потоке
        }
    }
}

• Полное отсутствие unit- или instrumentation-тестов и сопротивление их внедрению.

3. Проекты с неэтичной или сомнительной бизнес-моделью

Я сознательно отказываюсь участвовать в разработке приложений, которые:

• Вводят пользователя в заблуждение (навязчивые подписки, скрытые платежи).
• Злонамеренно собирают и передают данные без прозрачного согласия (data mining).
• Пропагандируют насилие, дискриминацию или иным образом нарушают базовые этические нормы.

4. Проекты с устаревшим стеком без плана на модернизацию

Работа с легаси-кодом — это нормальная и часто интересная инженерная задача. Однако я избегаю ситуаций, когда:

• Команда использует устаревшие и небезопасные технологии (например, HttpClient вместо Retrofit, AsyncTask вместо корутин/RxJava, отсутствие ViewBinding/Compose при работе с UI) и не рассматривает планов по обновлению.
• Приложение все еще на 100% на Java с активным развитием, без стратегии перехода на Kotlin.
• Минимальная targetSdkVersion безнадежно отстает от актуальной, что создает риски безопасности и проблемы с публикацией.

5. Проекты с токсичной культурой внутри команды

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

• Микроменеджмент довлеет над доверием и автономией разработчика.
• Нет культуры конструктивной обратной связи, а ошибки ищут для наказания, а не для обучения.
• Голос инженера по техническим вопросам не имеет веса перед мнением не-технического менеджера.

Вместо заключения: что для меня важно

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

• Качество и поддерживаемость кода.
• Современные практики (Kotlin, Jetpack Compose, многомодульность, тестирование).
• Честность по отношению к пользователю.
• Здоровую инженерную культуру и уважение внутри команды.

Такой подход позволяет не просто писать код, а создавать продукты, которыми можно гордиться, и которые приносят реальную пользу.