14 лет в Android-разработке, но кажется, что мобильная разработка умирает. Реально ли перейти в серверную разработку на Kotlin?

Новое обcуждение в Reddit:

У меня 14 лет опыта в Android-разработке, в том числе в компаниях из списка Fortune 500. Я прошёл весь путь от Eclipse и ранних версий Java до Jetpack Compose, корутин и современной архитектуры на Kotlin.

Однако в последние два года меня не покидает ощущение, что мир мобильной разработки находится в застое или постепенно угасает. Рынок кажется перенасыщенным, команды сокращаются, а большая часть действительно интересной работы куда-то исчезла. Сейчас всё в основном сводится к шаблонным интерфейсам, интеграции с API и поддержке существующих проектов. Да и вакансий стало заметно меньше.

Я рассматриваю переход в серверную разработку на Kotlin. Мне кажется, что значительная часть моих навыков должна переноситься достаточно естественно: сам язык, конкурентное выполнение и корутины, шаблоны проектирования, чистая архитектура и даже некоторые общие библиотеки.

Хотелось бы услышать мнение тех, кто уже совершил подобный переход, а также серверных разработчиков, участвующих в найме специалистов на Kotlin и JVM.

• Насколько реалистичен такой переход для человека с большим опытом мобильной разработки, но без производственного опыта в серверной части?
• Какие основные пробелы и слепые зоны потребуется быстро закрыть: проектирование баз данных, инфраструктура, Spring Boot или Ktor?
• Рассматривают ли руководители по найму старших мобильных разработчиков как специалистов с переносимыми навыками или снова оценивают их как начинающих?

Буду благодарен за любые мнения, личный опыт и честную оценку ситуации.

Обсуждение

Общий настрой треда: переход из Android в бэкенд реалистичен, но Kotlin сам по себе не делает его простым. Большинство участников считают, что опыт старшего мобильного разработчика переносится частично: архитектурное мышление, Kotlin, корутины, проектирование интерфейсов программирования и опыт промышленной разработки остаются ценными. Однако серверная разработка требует отдельного набора знаний, и на собеседованиях придётся конкурировать с людьми, которые много лет работали с базами данных, распределёнными системами и инфраструктурой.

Android не умер, но рынок изменился

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

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

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

Насколько реалистичен переход

В треде есть несколько примеров успешного перехода.

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

Другой участник после восьми лет Android-разработки перешёл на серверный Kotlin внутри своей компании и сохранил Senior должность благодаря репутации и тому, что Kotlin уже использовался на сервере. Однако он подчеркнул, что язык оказался самой простой частью перехода: основные сложности были связаны с Kubernetes, Docker, Kafka, PostgreSQL, Spring Boot, Grafana и общей серверной инфраструктурой.

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

Какие знания придётся освоить

Участники чаще всего называли следующие пробелы:

• проектирование реляционных баз данных и SQL;
• транзакции, уровни изоляции и блокировки;
• кеширование и инвалидация кеша;
• очереди сообщений и Kafka;
• распределённые системы;
• устойчивость к сбоям и повторные запросы;
• наблюдаемость: журналы, показатели, трассировка и оповещения;
• Docker, Kubernetes и облачная инфраструктура;
• диагностика производственных сбоев;
• производительность и масштабирование;
• безопасность и авторизация.

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

Spring Boot или Ktor

В комментариях не сформировалось подробного спора между Spring Boot и Ktor, но общий совет можно вывести из обсуждения: для трудоустройства важнее изучить широко используемый промышленный стек, а не ограничиваться конкретной технологией, которая кажется ближе к Android.

Несколько участников предупредили, что вакансий именно для серверного Kotlin значительно меньше, чем для Java. В ряде компаний Kotlin используется точечно, а основная серверная кодовая база остаётся на Java. Поэтому некоторые советуют позиционировать себя как инженера JVM-бэкенда, владеющего и Java, и Kotlin, а не как узкого Kotlin-разработчика.

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

Как подготовиться к переходу

Наиболее конкретный совет — сделать один или два настоящих серверных проекта, а не ограничиваться учебным API.

Проект должен демонстрировать:

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

Также советуют научиться разбирать производственные инциденты и объяснять компромиссы: почему выбрана конкретная модель данных, как система поведёт себя при сбое, что произойдёт при повторной доставке сообщения и как избежать несогласованного состояния.

Холодная рассылка резюме сейчас считается малоэффективной. Участники рекомендуют искать внутренний переход, знакомиться с серверными разработчиками, участвовать в общих проектах и получать рекомендации.

Альтернативные направления

Часть участников предложила не переходить в обычный бэкенд, а использовать Android-опыт в более близких областях:

Сервер для мобильных клиентов. Самый естественный переход: опыт клиентской разработки помогает проектировать серверные интерфейсы под реальные ограничения приложений.

Встраиваемые системы и Android Automotive. Здесь востребованы AOSP, системные службы, драйверы, ядро, C/C++ и работа с устройствами. Некоторые считают это более интересным и менее насыщенным направлением.

Kotlin Multiplatform и iOS. Это позволяет расширить область компетенций, не отказываясь полностью от мобильной разработки. Однако участники отмечают необходимость изучить экосистему Apple.

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

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

Итоговый вывод

Самый здравый вывод обсуждения выглядит так:

Переход реалистичен, но лучше переходить не в “Kotlin-бэкенд”, а в серверную разработку на JVM в целом. Kotlin даст быстрый старт, однако нанимать будут за понимание баз данных, распределённых систем, инфраструктуры, надёжности и эксплуатации.

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

Наиболее безопасная стратегия:

1. Изучить Java, Spring Boot, PostgreSQL, Docker, очереди и наблюдаемость.
2. Сделать полноценный производственно-подобный проект.
3. Искать внутренний переход или роль сервера для клиентского приложения.
4. Быть готовым временно работать на уровне сильного среднего разработчика.
5. Не ограничивать себя Kotlin и Ktor.

В целом тред подтверждает ощущение автора, что рынок Android стал сложнее, но не подтверждает, что единственным выходом является бэкенд. Главная рекомендация участников — расширять инженерный профиль, а не просто менять одну технологическую метку на другую.