А вы устали от того, что приходится постоянно заново учиться разработке под Android?

Обсуждение в Reddit:

Я занимаюсь разработкой Android-приложений с 2012 года и иногда задумываюсь, сколько раз за это время мне фактически приходилось начинать всё заново в этой экосистеме. Каждые 3–4 года кажется, что происходит какое-то серьёзное изменение. Переход с Eclipse на Android Studio, с Java на Kotlin, с XML на Compose, разные архитектурные подходы, устаревающие библиотеки и Google, который постоянно меняет свои рекомендации.

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

Меня раздражает не необходимость изучать новое. На самом деле мне это даже нравится. Проблема в постоянном ощущении, что нужно успевать следить вообще за всем просто для того, чтобы оставаться востребованным.

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

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

Интересно, чувствует ли кто-нибудь ещё из тех, кто занимается Android-разработкой более десяти лет, то же самое.

Кто-нибудь здесь переходил из Android-разработки в архитектуру, backend, инженерное руководство или вообще в какую-то другую область? Скучаете по работе Android-разработчиком на полный день или рады, что сменили направление?

Что отвечают разработчики:

• Самый популярный развёрнутый ответ — противоположный по настроению. Разработчик, который начинал ещё с Android 1.6, считает, что почти все крупные переходы были улучшениями: Java → Kotlin, хаотичная архитектура → MVVM/MVI, Activities/Fragments → Compose, ListView → RecyclerView → LazyColumn, AsyncTask → Coroutines, ручная навигация → Navigation и ручной DI → Dagger/Hilt/Koin. Его вывод: путь был болезненным, но Android-разработка сейчас значительно приятнее, чем раньше.
• При этом с идеей, что MVI — следующий очевидный этап после MVVM, многие спорят. Несколько участников называют MVI излишне сложным, особенно из-за reducers и слияния состояния, и считают, что для большинства экранов MVVM проще и надёжнее. Один разработчик использует элементы MVI только там, где много состояний и аналитических событий, а остальную часть приложения оставляет на MVVM.
• Другая большая группа полностью согласна с автором поста. Один разработчик с Android-опытом с 2012 года и почти 25-летним стажем в программировании считает, что скорость изменений именно в Android действительно выше средней. По его словам, создаётся ощущение, что «каждый API либо experimental, либо deprecated», а рекомендации Google слишком часто меняются вместо того, чтобы оставаться стабильными много лет.
• Очень часто всплывает тема поддержки старых приложений. Один участник пишет, что у него были прибыльные приложения, которые теперь практически невозможно нормально поддерживать на современных версиях Android из-за изменений API и удаления старых фич. Другой отмечает, что мобильные приложения слишком быстро «протухают»: сертификаты, новые требования ОС, SDK и библиотеки вынуждают возвращаться к старому проекту через год-два и тратить отдельное время просто на то, чтобы он снова собирался и работал.
• Отдельная боль — собеседования. Разработчик пишет, что ему нравится изучать новые технологии, но работодатели иногда требуют несколько лет опыта с технологией, которая сама существует всего несколько лет. То есть десять лет способности быстро осваивать новые Android-стеки могут цениться меньше, чем формальное наличие нужного количества лет именно с текущим фреймворком.
• Есть и прагматичная позиция: вообще не стоит гоняться за «рекомендованным способом». Android-разработчик с 15-летним опытом пишет, что для него правильный подход — тот, который работает для конкретного продукта, компании и пользователей. MVVM, RxJava, ViewModel, ConstraintLayout или Navigation Library можно было спокойно игнорировать, если проекту они не давали реальной пользы.
• Ещё один заметный объект раздражения — Android Gradle Plugin. Его критикуют за слабую обратную совместимость, слишком большое количество частей и одновременное использование Groovy, Kotlin DSL и TOML. Документация при этом не всегда синхронизирована с реальным состоянием инструментов, а AGP 9 один из участников прямо называет шоком.
• Но есть и сильный контраргумент: Android не уникален. Разработчик, пришедший после 14 лет на iOS, пишет, что там происходили похожие вещи, а в web всё, вероятно, ещё хуже. Другие напоминают про переходы Objective-C → Swift, бесконечные JavaScript-фреймворки, Python 2 → Python 3 и будущие изменения вокруг free-threading.
• Некоторые считают, что автор поста вообще преувеличивает. Android Studio существует больше десяти лет, Kotlin является основным языком уже около семи лет, а Compose — больше пяти. По этой версии, настоящий большой переход последних лет был фактически только один — Views → Compose, а backend или AWS потребуют не меньшего количества постоянного обучения.
• Интересный практический нюанс — наследие всех этих эпох внутри одного проекта. Люди жалуются, что приходят на новую работу и получают кодовую базу, где одновременно живут Java, Kotlin, XML, Compose, RxJava, Coroutines и разные поколения архитектуры. Один разработчик пришёл в проект с 70% Java + XML и постепенно переводил наиболее активно изменяемые Activities на Kotlin + Compose.
• Есть и мнение, что сейчас ситуация, наоборот, стабилизировалась. Kotlin + Coroutines уже зрелые, Compose работает нормально и развивается в сторону Multiplatform, а заметная часть нововведений Android Studio теперь связана не с очередными UI-библиотеками, а с ИИ. Один из участников даже пишет, что ему в последнее время стало немного скучно именно потому, что фундаментальных изменений почти нет.
• И наконец, ИИ сам появляется в обсуждении как следующий, возможно, самый радикальный переход. Один из опытных участников считает, что Claude, Gemini, агентные инструменты и Android Skills меняют профессию сильнее, чем все прежние переходы AndroidX или даже Compose: теперь вместо того, чтобы помнить очередной API, разработчику всё чаще придётся правильно сформулировать задачу агенту и проверить результат. Другие формулируют это ещё короче: «теперь всё сходится к английскому языку».

Общий вывод обсуждения: большинство не спорит с тем, что Android пережил огромное количество технологических циклов. Спор идёт о другом — считать ли это бессмысленным переизобретением одних и тех же вещей или нормальной ценой за то, что современный Android стал заметно удобнее раннего. Самая убедительная претензия звучит не как «не хочу учиться», а как «я устал учить новый способ делать то, что старым способом и так работало». При этом ИИ может неожиданно сделать эту проблему менее важной: знать каждую новую библиотеку наизусть становится не так критично, если агент способен разобраться с ней по месту.